- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm comparing the standard Independent JPEG Group's code to the speedups provided by IPP. All I'm doing is loading JPEGs into arrays, along the lines of the decompress sample in ipp-samples\image-codecs\ijg\samples\ijgtiming. On the images I'm looking at, I find a 25% speedup if I load one image 100 times from my network. But if I loop through a directory of 450 images on the network and load each one at a time, I find no speedup.
Does anyone have any tips? Is it known that IPP won't speed up some workloads? Or is it likely that I'm doing anything wrong? I've already read a few knowledgebase articles I found without any obviously helpful suggestions. My memory is aligned, I don't want to split into multiple threads, nothing else looked applicable.
If no one has any suggestions, I guess I'll stick with the Independent JPEG Group's code.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's some great advice. The maximum size is 32768 as referenced in the documentation you linked to, though that may be out of date as it's back on VC++6.0. It looks like it's gone up since then, see: http://msdn.microsoft.com/en-us/library/86cebhfs.aspx
Using a buffer size of 32768 sped up code for both by 25%, but still no advantage for IPP. Moving the images to the local drive didn't make much difference either. Removing filling of the array and just leaving the calls to jpeg_read_scanlines sped everything up of course, but still no performance difference between the two.
It's definitely possible that I'm somehow doing linking wrong or something, but I think the time I have to spend on this is up now. I may come back to it later.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if you link with IPP static libraries please make sure you call ippStaticInit function somewhere in the beginning of your application. Otherwise generic code will be dispatched by IPP to run instead of optimized for your processor
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if you link with IPP static libraries please make sure you call ippStaticInit function somewhere in the beginning of your application. Otherwise generic code will be dispatched by IPP to run instead of optimized for your processor
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To achieve the best performance on application level it is not enough just to turn on SIMD instructions support in your favourite compiler or link with optimized libraries, like Intel IPP. It is also important that application itself designed in the way to address system wide factors affecting performance. And thisrequired some known level of expertise of course.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To achieve the best performance on application level it is not enough just to turn on SIMD instructions support in your favourite compiler or link with optimized libraries, like Intel IPP. It is also important that application itself designed in the way to address system wide factors affecting performance. And thisrequired some known level of expertise of course.
Regards,
Vladimir
You're right, it's entirely possible that hard drive and memory issues are swamping image decoding time. I guess the peculiarities of how IJG and IPP read the files could affect total load time quite a bit. I may try to look into that further later on. Thanks for the advice.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You're right, it's entirely possible that hard drive and memory issues are swamping image decoding time. I guess the peculiarities of how IJG and IPP read the files could affect total load time quite a bit. I may try to look into that further later on. Thanks for the advice.
If JPEG files encoded in progressive mode, than there will be no speedup at all. Because IPP IJG onlymodify baseline sequence mode codes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But generally, progressive mode requires several passes through data before it get to final image, so benefit might be not that big.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But generally, progressive mode requires several passes through data before it get to final image, so benefit might be not that big.
Regards,
Vladimir
The inverse DCT speedup only occurredwhile choosing accurate JDCT_ISLOW method. In generally,weuse JDCT_IFAST for decoding. And there is no significant improvement on sub-sampling and color conversion. So in my experience, we don't get speedup on progressive mode JPEG decoding.
Sincerely,
Bell
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if you will choose JSLOW IDCT method (which is powered by IPP) your final performance might be better then in case of JFAST method. Did you try that?
Regards,
Vladimir
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page