On Tue, Jun 01, 2010 at 01:35:20PM +0100, Ilyes Gouta wrote: > Hi, Hello, > I'm still interested in seeing a linjpeg-turbo merger with ijg's own > code base. I'd say that the most performance boost brought in by > libjpeg-turbo is due to the specialized SIMD routines, which > theoretically can be easily merged. libjpeg-turbo has also some > weaknesses such as (as provided from the project's homepage): You are right, it will be better to join forces together with IJG. But as I wrote earlier, libjpeg-turbo is at my opinion far more ahead than IJG's source and is developed in more open-source manner. Additionally, as Tom Lane wrote, current maintainer of the IJG libjpeg doesn't care about API/ABI compatibility much. > 1. Worse chroma upsampling quality, where libjpeg-turbo is favoring > speed over accuracy when upsamling the chroma components This is not enabled by default, you have to explicitly specify this behavior (TJ_FASTUPSAMPLE parameter). > 2. JPEG's standard restart marker aren't properly handled, in favor of > a faster huffman decoding It is handled properly. When libjpeg-turbo hits restart marker then it must use slower huffman decoder which means 15% - 20% performance drop but is still much faster than IJG's libjpeg. > 3. Asymetric performance gain between 32bit and 64bit arch., which > means specific, per arch. code paths and not algorithmic and > architecture wise tweaks that could benefit all the architectures. Yes, usage of SSE is the main reason why libjpeg-turbo is much more faster than libjpeg. But as written on http://libjpeg-turbo.virtualgl.org/About/Performance, 32bit is slower due small number of registers; those registers are allocated by compiler, it's not assembler code, libjpeg-turbo is currently using same ASM code for both x86 and x64. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
