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.