Re: [Libjpeg-turbo-devel] Optimizing JPEG compression speed

[Siddharth B. <sid...@ci...>]

Thank you for your responses, they are much appreciated!

I meant that Libjpeg-turbo was faster than Pegasus by 40% for decoding jpegs, but slower by 30% when used for encoding rgb images to jpegs.

By multi-threading, do you mean encoding multiple images in parallel, or splitting up 1 image into multiple parts and encoding them in parallel and rejoining them? If it’s the second case, could you point me to a an example implementation or resource that describes such a process. I tried looking for it myself, but found nothing so far.

Thanks,


From: Hao Hu [mailto:ih...@gm...]
Sent: Tuesday, December 20, 2016 12:04 AM
To: libjpeg-turbo Developers <lib...@li...>
Subject: Re: [Libjpeg-turbo-devel] Optimizing JPEG compression speed

If you search Pegasus on this link https://sourceforge.net/p/freeimage/discussion/36111/thread/fb51778d/
You'll see your result is aligned with others observation.

If you control the compression/decompression, then there are ways to make libjpeg-turbo many times faster by design a multi-threading based wrapper code.
Then if you have 4 cores, you usually get at least 3x faster. But you'll need to come up with the design based on your specific case.

2016-12-19 15:21 GMT-08:00 DRC <dco...@us...<mailto:dco...@us...>>:
Nothing obvious stands out in your code.  I don't quite understand your
claims below that "libjpeg-turbo came out behind by 30%" but
"libjpeg-turbo seemed to be 40% faster while decoding images at the same
quality level".  Those seem to be contradictory claims.  Please clarify.

You can get probably 10-15% better performance from the dev (1.6
evolving) builds, if you're using an AVX2-equipped CPU (I expect that to
be more like 25% when libjpeg-turbo 1.6 ships, but I'm seeking funding
to finish out the AVX2 acceleration project.)

I'm not really surprised that Pegasus is faster.  They do use SIMD
instructions, and they also use multi-threading.  The latter is
something we cannot do within our library because of the libjpeg
architecture, although applications are of course free to implement
multi-threaded compression or decompression on their own.  Our initial
performance goal was to match the performance of the Intel Performance
Primitives, which we pretty much have done, but Pegasus has always been
a notch faster than IPP in my experience.

Back in the day, I had a TurboJPEG API implementation for Pegasus, which
can be found here:
https://github.com/VirtualGL/virtualgl/tree/029f870488d251b48c3be0b17804e3002f7602cd/jpeg

You should be able to build turbojpegp.c and jpgtest.cpp against Pegasus
and obtain benchmark data that closely resembles that of tjbench in
libjpeg-turbo.  That would be a good sanity check.

On 12/19/16 2:56 PM, Siddharth Bidasaria wrote:
> Hi all,
>
>
>
> I am currently using a proprietary jpeg encoding library called Pegasus,
> and was looking to switch to libjpeg-turbo.
>
>
>
> I have been conducting some benchmarks between the two libraries and
> libjpeg-turbo came out behind by 30%. I was quite surprised by this
> because Pegasus was last updated 4 years ago, and I believe it doesn’t
> make use of SIMD instructions either. Moreover, libjpeg-turbo seemed to
> be 40% faster while decoding images at the same quality level.
>
>
>
> Hence, I wanted to rule out that I am incorrectly/inefficiently using
> the libjpeg-turbo api. If you could have a look at my compression code
> below, and let me know if there are any glaring things I
> should/shouldn’t be doing please let me know!

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Libjpeg-turbo-devel mailing list
Lib...@li...<mailto:Lib...@li...>
https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel