2021.05.03 20:40 "Re: [Tiff] SIMD optimizations", by Bob Friesenhahn
- > How many people use well compressed LZW images and would care about a 2-20x speedup?
My main interest in TIFF is CCITT Group 4 fax encoding. This is already very fast, but it is hard to say no to additional speed. The popularity of libjpeg-turbo is a testament to that. Also, respectfully, speeding up libpng would have vastly more impact than speeding up libtiff.
A list member posted repeatedly that he had private/proprietary CCITT Group 4 fax support which was much faster than what is in libtiff. Given this, one must assume that libtiff's implementation can be faster.
Regarding libpng, the major slow point of libpng is zlib, and particularly when compressing. Application of PNG filters can be sped-up.
Previously SIMD optimizations were developed for libpng (I think from more than one party) but there was not continued support (from the contributor) for them and they were later considered to be unsupportable by the libpng maintainer and removed.
There is a cost associated with any target-specific optimizations and that cost pertains to the continual maintenance and testing required to support them. The optimizations should have proven value with real-world test cases (e.g. the whole time and not just the time for the part sped-up in isolation) before a project agrees to assimilate them because there is also a cost.
If Larry Bank (the expert) loses interest after the code has been submitted then there might not be another expert to take his place if a problem comes up.
If access to Apple's M1 processor is needed in order to verify that SIMD code is working, but access to it is not available, then that would be a problem for the libtiff maintainers.
SIMD optimizations can be great, but we also need to be aware of implications and risks.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt