Deprecate the C++ vision::models namespace

[datumbox]

We should consider dropping the C++ vision::models namespace for the following reasons:

1. They are not currently being maintained.
2. They represent an old attempt to support Vision models in C++. This was superseded by JIT. All of the models we propose to remove are fully jit-traceable and jit-scriptable.
3. Several of the new classification models are missing (MobileNetV3, EfficientNets etc). Segmentation and Detection models are not implemented.

This PR deprecates the entire namespace by adding warnings. It also updates the code examples to show how to integrate models using JIT.

[NicolasHug]

Thanks for the PR @datumbox , I have a few remarks / questions

They are not currently being maintained.

Somewhat related is #3992. It shouldn't take too much effort to put it back on track but it might not be needed after all

They represent an old attempt to support Vision models in C++. This was superseded by JIT. All of the models we propose to remove are fully jit-traceable and jit-scriptable.

It seems however that relying on jit for this involves a slightly more cumbersome workflow: namely, one has to first export a model from Python so that it can then be used in C++. This means that you can the exported models also needs to be shipped as part of the binaries I guess. What do we think about this?

Also, is there a similar effort on the pytorch side? Quoting @fmassa 's #3992 (comment)

it would be good to know who is the current maintainer of the C++ API of PyTorch

Finally, with torchscript being currently unbundled to different other packages, will there be a different alternative for this in the future? (say torch::deploy or something else)

[datumbox]

@NicolasHug Thanks for the comments.

Unfortunately, maintaining the namespace requires significant more effort than one would think. The reason, most of the newer models are missing is because they rely on operators that are only available in Python. Moreover offering a C++ API for only the old classification models makes very little sense (segmentation and detection models are all missing). Please note that this initiative is coordinated with Francisco and discussed with Greg and Brian. If you have more concerns about this, let's chat offline.

[NicolasHug]

Thanks @datumbox ,

I would still be interested in having my questions above answered. Perhaps there is a document that I could read?
If I were a user relying on the current C++ API, I think these questions would be relevant to me, so maybe there's value in having them publicly as well?

[datumbox]

@NicolasHug Sounds good. We can gather references related. to the above and you are welcome to lead the efforts to make them presentable publicly so that the community can benefit.

[NicolasHug]

Thanks for the proposal @datumbox but since I'm not involved in this work, I don't think it should be up to me

[fmassa]

Hi,

To address some points brought up by @NicolasHug comments:

They represent an old attempt to support Vision models in C++. This was superseded by JIT. All of the models we propose to remove are fully jit-traceable and jit-scriptable.

The torchscript and C++ APIs are two different ways of getting your model into C++, and they target different users.
There are use-cases where having your full training / evaluation script in C++ is preferable (i.e., in very low-latency cases for RL), so the C++ API might be a better fit in there (and this is why we added the C++ models to begin with).

This means that you can the exported models also needs to be shipped as part of the binaries I guess. What do we think about this?

I believe this is fine and what is done by the rest of the community. If you imagine that you have your binary that runs your application, and that this binary takes a serialized model as an argument, then shipping this extra file is very reasonable (and we don't need to recompile the app if we switch models).

Finally, with torchscript being currently unbundled to different other packages, will there be a different alternative for this in the future? (say torch::deploy or something else)

Yes, I would expect that we will have a 3rd option to enable models to run in C++, which is similar to the torchscript solution but running entirely with Python.

[fmassa]

Thanks for the PR @datumbox !

After discussing with Vasilis, we decided to change the message to indicate that we are not actively maintaining the C++ models, but we will keep them around.

[NicolasHug]

Thank you for addressing my questions @fmassa