According to the website (https://vectordash.com/hosting/) they use a highly isolated Ubuntu image, so the person hosting the service shouldn't have access to the VM with your model or data on it. It would be nice if there was some third party audit of the software though, the models, the code, and even the training data can be pretty sensitive for researchers.
If your training data is sensitive, then Vectordash may not be the best GPU provider. But if you're a broke CS student like me who wants to participate in a few Kaggle competitions (after having burned up their AWS student credits in 3 days) without shelling out a bunch for a K80, then Vectordash might be pretty helpful!
Visual Studio Code with the LaTeX Workshop addon is definitely my favorite LaTeX editor. The integration with the Chktex linter, latexmk, git, and all that jazz just makes it so much easier to focus on writing.
For research management I had been using Mendeley for a while and got a bit frustrated with the way it handled bibtex. Like it got really annoying when I had papers which fell into multiple categories and/or were used in multiple papers. My new setup is to use JabRef to manage individual bibtex files for specific projects and to use Mendeley just for document management and notes.
Hot damn this has got me all giddy. How will this work on single node multi-GPU systems? For example, with PyTorch you have to either use threading, multiprocessing, or even MPI. Can you think of a not-too-scary way to use eager execution with multiple GPUs?
We're still fairly early in the project, so for now threading is the only supported way.
We can do better, however, and we're working on ways to leverage the hardware better (for example, if you have no data-dependent choices in your model we can enqueue kernels in parallel on all GPUs in your machine at once from a single python thread, which will perform much better than explicit python multithreading).
Stay on the lookout as we release new experimental APIs to leverage multiple GPUs and multiple machines.
Hell, being able to effortlessly switch between PyTorch and Numpy/SciPy/sklearn/skimage has been so helpful for the project I'm working on. That and I have tensors in later layers whose shapes depend on the training of the previous layers.
Not yet! I'm not using convnets or backprop or anything so I don't think it would be beneficial that way, but you could get something similar to what I'm doing by looking at Fritzke's Growing Neural Gas[1]
That's a serious point of frustration for me. Having an option to use anaconda, fine. Forcing it on your users, meh. I already have a working system using virtualenv and pip, why force another on me?
For installing it, yeah pip is great too, but for building conda includes third party tools and libraries and stuff. e.g. in order to use the MPI backend for PyTorch's distributed processing you need to build it yourself and conda just makes it a bit easier. That and I had a real bad experience with trying to build Tensorflow (and Bazel) to run on an HPC cluster.
