- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Can anyone help me to understand how threading works in the 7.0.1 IPP libraries?
We want to use the ijg sample code (libjpeg) in our application as we believe that it performs much better than the version shipped with 5.3.1 IPP libraries particularly because it provides better multi-threading/multi-core support.
However, it is not clear to me whether I need to link this library (for Windows) using the _t or _l static libraries to benefit from this performance improvement.
If the performance improvement is independent of which libraries I choose, then when would I use the _t over the _l variants?
Thanks.
Can anyone help me to understand how threading works in the 7.0.1 IPP libraries?
We want to use the ijg sample code (libjpeg) in our application as we believe that it performs much better than the version shipped with 5.3.1 IPP libraries particularly because it provides better multi-threading/multi-core support.
However, it is not clear to me whether I need to link this library (for Windows) using the _t or _l static libraries to benefit from this performance improvement.
If the performance improvement is independent of which libraries I choose, then when would I use the _t over the _l variants?
Thanks.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
libjpeg is not quite good sample to demonstrate multi-threading benefits. The reason is that the libjpeg library itself was not architected in the way to support threading (it was developed by IJG many years ago) and IPP functions used in libjpeg will not use threading because they work on small data blocks (like DCT operation on 8x8 block of coefficients).
If you are looking for threaded JPEG implementation I'd recommend you to take a look at UIC sample (Unified Image Codecs), which is C++ high-level image codec libs. In IPP 7.0 we do provide threaded JPEG, JPEG2000 and JPEGXR UIC codecs. They are threaded on top of IPP which is more efficient then threading on primitives level.
Regards,
Vladimir
libjpeg is not quite good sample to demonstrate multi-threading benefits. The reason is that the libjpeg library itself was not architected in the way to support threading (it was developed by IJG many years ago) and IPP functions used in libjpeg will not use threading because they work on small data blocks (like DCT operation on 8x8 block of coefficients).
If you are looking for threaded JPEG implementation I'd recommend you to take a look at UIC sample (Unified Image Codecs), which is C++ high-level image codec libs. In IPP 7.0 we do provide threaded JPEG, JPEG2000 and JPEGXR UIC codecs. They are threaded on top of IPP which is more efficient then threading on primitives level.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
its 2013 now and in IPP 7.1.1 samples I still find this comment:
UIC codecs are starting points, not product-ready components. They do not support their full specifications, including profiles and levels. They are also not fully optimized for performance.
When will they be product-ready?
Regards
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>...When will they be product-ready?
David, My understanding is that Intel never tried to make these codes as product-ready and I don't think it will ever do that. Consider these codes as templates for R&D, etc.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page