vision icon indicating copy to clipboard operation
vision copied to clipboard

Build against `libjpeg-turbo` instead of `libjpeg`

Open pmeier opened this issue 3 years ago • 0 comments

torchvision is currently building

https://github.com/pytorch/vision/blob/cac4e228c9ca9e7564cb34406e7ebccfdd736976/setup.py#L321

https://github.com/pytorch/vision/blob/cac4e228c9ca9e7564cb34406e7ebccfdd736976/packaging/torchvision/meta.yaml#L13

and testing against libjpeg

https://github.com/pytorch/vision/blob/cac4e228c9ca9e7564cb34406e7ebccfdd736976/.circleci/unittest/linux/scripts/environment.yml#L10

https://github.com/pytorch/vision/blob/cac4e228c9ca9e7564cb34406e7ebccfdd736976/.circleci/unittest/windows/scripts/environment.yml#L10

Pillow is building against libjpeg-turbo on Windows for some time now 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
    • #5184
    • #5162
    • #3913
    • #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 https://github.com/pytorch/vision/pull/5941#discussion_r871546056 @malfet only talks about testing against it, but maybe we can also build against it.

cc @seemethere

pmeier avatar Sep 12 '22 11:09 pmeier