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 <at...@redhat.com> 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
