Build against libjpeg-turbo instead of libjpeg

[pmeier]

torchvision is currently building

vision/setup.py

Line 321 in cac4e22

(jpeg_found, jpeg_conda, jpeg_include, jpeg_lib) = find_library("jpeglib", vision_include)

vision/packaging/torchvision/meta.yaml

Line 13 in cac4e22

- jpeg

and testing against libjpeg

vision/.circleci/unittest/linux/scripts/environment.yml

Line 10 in cac4e22

- jpeg

vision/.circleci/unittest/windows/scripts/environment.yml

Line 10 in cac4e22

- jpeg

Pillow is building against libjpeg-turbo on Windows for some time now and since Pillow=9 on all platforms (Jan 2022).

This has two downsides for us:

1. We can't use Pillow as reference for our own decoding and encoding ops. See
   • move JPEG reference test into separate CI job #5184
   • fix JPEG reference tests #5162
   • Fix jpeg encoding tests on windows #3913
   • Disable test_encode|write_jpeg_reference tests #5910
2. As the name implies, libjpeg-turbo is a faster implementation of the JPEG standard. Thus, our I/O ops are simply slower than using Pillow, which hinders adoption.

Recently, @NicolasHug led a push to also use libjpeg-turbo, but hit a few blockers:

1. Our workflows use the defaults channel from conda. Unfortunately, on defaults libjpeg-turbo is only available for Windows and macOS.
2. Adding conda-forge to the channels for Linux, leads to crazy environment solve times (10+ minutes), which ultimately time out the CI. In general this change should be possible if conda-forge has a lower priority than defaults.
3. Depending on the experimental libmamba solver indeed speeds ups the solve for the CI to not time out (it is still a little slower than before). Unfortunately, our CI setup does not properly work with it, since a CUDA 11.6 workflow is still pulling a PyTorch version build against CUDA 11.3.

From here on I currently see four options:

1. Only build and test Windows and macOS binaries against libjpeg-turbo. This would mean that arguably most of our users won't see that speed-up.
2. Find a way to stop the CI from timing out when using conda-forge as extra channel. This can probably be done through the configuration or by emitting more output during the solve.
3. Fix our CI setup to work with the libmamba solver.
4. Package libjpeg-turbo for Linux ourselves. We already use the pytorch or pytorch-nightly channels. If it was available there, we wouldn't need to pull it from conda-forge. In Use libjpeg-turbo in CI instead of libjpeg #5941 (comment) @malfet only talks about testing against it, but maybe we can also build against it.

cc @seemethere

[pmeier]

#6746 increased the inactivity timeout for the CI from 10 to 30 minutes. If that is acceptable in general now, we might get away with 2. above.

[sh-shahrokhi]

#6746 increased the inactivity timeout for the CI from 10 to 30 minutes. If that is acceptable in general now, we might get away with 2. above.

Hello, just wanted to thank for this. Maybe you can add libjpeg-turbo to pytorch channel, and remove conda-forge?

[sh-shahrokhi]

Also, please check this https://www.anaconda.com/blog/conda-is-fast-now

conda install -n base conda-libmamba-solver
conda config --set solver libmamba

it increases conda's speed without adding conda-forge.