libjpeg for F14
ilyes.gouta at gmail.com
Tue Jun 1 12:35:20 UTC 2010
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):
1. Worse chroma upsampling quality, where libjpeg-turbo is favoring
speed over accuracy when upsamling the chroma components
2. JPEG's standard restart marker aren't properly handled, in favor of
a faster huffman decoding
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.
To me, 1. and 2. are a bit worrying, I don't want to scarify standard
correctness over a 15% perf. boost. The only items that stands out are
the SIMD routines which can be merged with the ijg's official libjpeg,
and I think we should push in that direction instead.
On Tue, Jun 1, 2010 at 12:00 PM, Adam Tkac <atkac at redhat.com> wrote:
> On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote:
>> On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote:
>> > On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
>> >> I'm going to create a Fedora feature for this task.
>> > Done. You can check
>> > http://fedoraproject.org/wiki/Features/libjpeg-turbo.
>> Thanks. Is there an SRPM we can give it a test?
> Yes, I just created it, check
> http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the
> feature page because no package linked against current libjpeg needs
> to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply
> build & install libjpeg-turbo and you should immediately see
> performance benefits.
> If you prefer to test libjpeg-turbo in more conservative way you can
> build SRPM and then extract libjpeg.so from it
> (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it.
> Regards, Adam
> Adam Tkac, Red Hat, Inc.
> devel mailing list
> devel at lists.fedoraproject.org
More information about the devel