Re: libjpeg for F14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Adam,

> it also contains bunch of
> pure algorithmic enhancements so even if target platform doesn't
> support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.

Can you please give some details on this point?

-Ilyes Gouta

On Mon, May 31, 2010 at 4:33 PM, Adam Tkac <atkac@xxxxxxxxxx> wrote:
> On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote:
>> On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
>> > How about this: since libjpeg is picking momentum and there are
>> > actually people updating the code base, why not push for a
>> > libjpeg-turbo merge into the original ijg's code and get Fedora to
>> > rebase on that unique source instead?
>>
>> The problem, as I said before, is that the libjpeg upstream is not
>> being developed in an open manner.
>
> This is pretty big issue.
>
>> I've emailed Adam Tkac to bring his attention to this thread (he's
>> involved with libjpeg-turbo) and hopefully he'll bring some more up to
>> date information about this matter.
>
> Sorry for late response, this mail got lost in my queue.
>
> libjpeg-turbo is a fork of the original libjpeg-6b release created
> and maintained by VirtualGL and TigerVNC developers. Main focus is on
> performance and API+ABI compatibility with libjpeg. Although
> libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of
> pure algorithmic enhancements so even if target platform doesn't
> support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.
> When SSE is used then libjpeg and libjpeg-turbo performance is simply
> incomparable. And there are still number of areas for optimizations,
> for example on we are currently using only half of SSE registers on
> 64bit platforms.
>
> About the merge of this code with the original ijg's code. Yes, I must
> admit it is possible but personally I don't like it much. In my
> opinion libjpeg-turbo is far more ahead than libjpeg so it's easier
> for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not
> able to find CVS/SVN/git repository of the libjpeg code.
>
> In my opinion if will be great benefit for Fedora to simply replace
> libjpeg by libjpeg-turbo. It works fine on secondary architectures
> and if processor doesn't support MMX/SSE then it falls back to
> non-ASM code (which is still faster than libjpeg code, as I wrote
> above).
>
> Btw this library is used since Fedora 11 in tigervnc package for JPEG
> compression/decompression and it works without any problem on all
> supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x).
>
> So, if I summarize pros and cons for libjpeg-turbo:
>
> +: _really_ faster than libjpeg
>   more portable
>   more open than IJG code
>   API/ABI compatible with libjpeg (AFAIK)
>   works on all platforms (not only on SSE capable platforms)
>
> -: not developed by IJG :)
>
> I'm going to create a Fedora feature for this task.
>
> Regards, Adam
>
> --
> Adam Tkac, Red Hat, Inc.
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux