In addition if you don't want to fiddle with the containers, there's also a conda channel[2] that lines stuff up. I work on a peer team in machine vision, and use these for personal and professional projects.
[1] https://hub.docker.com/r/ibmcom/powerai/
[2] https://www.ibm.com/support/knowledgecenter/en/SS5SF7_1.6.1/...
It also works well for machine learning projects.
I think part of your problem is the last word there. Windows is a bad match for such an environment. On Ubuntu it is pretty much painless.
I vastly prefer creating hermetic environments with either venv or Docker. They're much cleaner and easier to work with. I wish data scientists would adopt these tools instead.
Sadly, many of the ML models I investigate on Github don't even have their package requirements frozen. It's an uphill battle...
I suspect you have a lot of time on your hands. But for me the 'batteries included' approach really nails it, why repeat the headache over and over again when a single entity can take care of that in such a way that incompatibilities are almost impossible to create? The hardest time I've had was to re-create an environment that ran some python code from a while ago, with Anaconda it was super easy.
I'm sure it has its limitations and just like every other tool there are situations where it is best to avoid it but for now it suits me very well.
conda install -c anaconda tensorflow-gpu
pip install with almost exactly the same set of packages: 3-5 minutes total.
Ah I guess it's on the way but not fully there yet
Or consider https://github.com/google/jax !
The thing is, TF has more than tensor ops. It has pre-defined NN layers, data loading/serialization, distributed training, metrics, and model serving.
It seems like a bit of a step backwards, that's all.
Edit: "matrix ops" -> "tensor ops"
Yes, with a compiler to make this fast.
> The thing is, TF has more than tensor ops. It has pre-defined NN layers, data loading/serialization, distributed training, metrics, and model serving.
Yes, it is a simpler and smaller API.
For things like data loading, you can use the tool of your choice -- TF, pytorch, whatever. For pre-defined NN layers, there are libraries that build this as a very thin wrapper around JAX's low-level API, see e.g. lax, which is include in JAX.
I think jleber means stax here, for pre-defined NN layers.
- that’s exactly what we did and we don’t regret that decision
If you are trying to apply one of these libraries to a production system that doesn’t get a lot of throughput you probably shouldn’t be using them (try a linear model first). If you have a high throughput application you probably want tensorflow and just deal with the shittyness.
layer = F.relu(Linear()(input))
layer = Dense(activation_fn='relu')(input)
If you switch to PyTorch, what are you going to use for prod deployment? Is there any way to use TPUs?
PyTorch has an optional XLA device, that let's you use TPUs: https://github.com/pytorch/xla
And that's before Sonnet, the Estimator API (?) and TFLearn (I'm probably forgetting a bunch).
But since the supported third-party platforms (CNTK and Theano) have stopped development due to TensorFlow, well...
I mean, when relying on third party code, things like `tf.enable_control_flow_v2() and tf.disable_control_flow_v2()` can and will go horribly wrong. It looks like some operations are changing behaviour depending on a global flag being set. And not just some operations, but control flow operations! That will lead to some very hard to figure out bugs.
In my opinion there are some architectural problems with TF, which have not been adressed in this update. There is still global state in TF2. There is still a difference in behaviour between eager and non-eager mode. There is still the control flow as a second class citizen.
If you need to transition from TF1 to TF2, consider doing the TF1 to pytorch transition instead.