New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The supervised_visualization notebook is running very slowly on Google Colab (with GPU) #210
Comments
Update: I tried
I found this very very slow. So i actually suspect the data preprocessing could be a bottleneck. I tried this both on colab and my own laptop. |
Hi, The memory samplers provide an easy way to construct the balanced batches, but they don't currently use data.Dataset and consequently don't have access to the input pipeline optimizations. So I think you are correct that using a preprocess_fn like resize_with_pad() will be slower without the parallel calls that you get in something like Dataset.Map(). However, I have been working on a solution that uses data.Dataset, but I haven't generalized it to a new sampler yet. The trick is to sample the right number of classes per batch using Dataset.interleave and a Mapping[int, List[int]] where we map class ids to index locations. The following is a basic example.
|
@owenvallis Thanks for getting back. I am actually a bit confused. I was referring to this notebook in particular: https://github.com/tensorflow/similarity/blob/master/examples/supervised_visualization.ipynb (1) The sampler seemed to use TFDS to get oxford_iiit_pet, so i thought this was downloaded as tfrecords. Isn't it true you have to use tf.data.Dataset to load them in? I also have evidence that the resizing method may not be the bottleneck. If you resize to 128 instead of 300, the "for x, y in train_ds: print(x.shape)" will run a lot faster. (2) That checked in notebook has its example run output saved, and the training indicated about 70ms/step, compared with 10sec/step on colab GPU. This made me think this is a regression bug, or you are using something extremely powerful to run this example. Simply put, I just love to reproduce your notebook, with comparable speed as well, instead of several order of magnitude slower. |
Thanks for clarifying, looks like you're right that the per step time is much slower now. I ran a cProfile and it looks like the call to I'll push a patch to master.
|
So Converting to np.array first provides the following cProfile.
|
Pushed a patch in 0ee015c. Time per step is now closer to 180 ms using a single NVIDIA Tesla P100. Let me know how this works out on your end. |
One more update. I tested my current patch against using tf.gather and they both take about 80 ms per batch. I'm avoiding tf.gather as I've run into some OOM issues when using it compared to the numpy to tensor approach.
However, it looks like the dataset approach I shared above takes about 20 ms per batch. I'll see if we can move towards using the dataset approach in a future update.
|
@owenvallis I just tried and it is now 170ms/step on colab, so your fix works. thanks for the fast turnaround, really appreciate this. |
I just started exploring this library with my own dataset, and I found training is very slow. I haven't profiled why this is slow compared with my vanilla classification workflow. But I tried to test with supervised_visualization.ipynb.
One thing i noticed is the copy on GitHub seems to say it should take about 70ms/step. I ran the same notebook without a single change on Google Colab with GPU (P100), and it was excruciating slow at 10s/step. What should I check?
So i suspect the slowness I saw with my own dataset (also trained on google colab gpu) is related to what I saw in supervised_visualization.ipynb.
Please help.
The text was updated successfully, but these errors were encountered: