libjpeg for F14

[Adam Tkac]

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.