- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've recently run into a problem getting any gains with Intel IPP ZLIB for my application.
I'm running a program that streams data but prior to streaming has the option to zlib compress the content. Problem is, zlib is very expensive and we can stream maybe 1/10th the data per cpu core when enabling zlib.
I'm running on a Linux HP G10 box which and when I relink with IPP ZLIB, I'm getting slightly worse performance than I do with the standalone ZLIB.
15 years or so ago I tried a similar test and IPP ZLIB had a massive improvement from ZLIB but can't recall the version we were using then. Anyone else see similar to worse performance with IPP ZLIB?
I've tried both zlib1.3.1 and zlib1.2.6.1 and see the same performance for both.
One thing I notice with ipp zlib is perf top shows the following.
28.47% adszlib1261 [.] pqdownheap
24.63% adszlib1261 [.] l9_ippsDeflateLZ77Fast_8u
5.82% adszlib1261 [.] l9_ippsDeflateHuff_8u
I think with standard zlib, huffman encoding occurs while performing the LZ77, from the Intel IPP code it looks like a completely secondary pass once LZ77 is completed.
With standard zlib I see the following. The pqdownheap is in both implementations but only the IPP version has this show up which makes me wonder if its because it's a second pass.
20.61% adszlib124 [.] build_tree
16.85% adszlib124 [.] longest_match
16.35% adszlib124 [.] deflate_fast
10.26% adszlib124 [.] compress_block
6.37% adszlib124 [.] fill_window
Was really hoping to relink with IPP to solve performance problems but now wondering if standard zlib efficiency just improved over last 15 years or so to make the IPP version irrelevant.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From the IPP release notes, IPP has improved compression ratio and throughput with new optimization patch for zlib 1.3.1 in IPP 2021.12.0 release notes
Can you tell us your environment?(OS, CPUs, and IPP version, etc.). And it's also helpful to share out your reproduce steps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm running on Redhat 7.9 on a 28 core Intel Xeon E5-2697.
I'm using the latest Intel IPP that I just downloaded last week. I believe this is 2022.0. I'm also using zlib-1.3.1.
To recreate, I'm just running a slightly modified minigzip. I'm feeding a 27 meg binary capture file I took from my application and running minigzip with and without -DWITH_IPP.
With IPP, the tool is averaging around 1.2 seconds to compress this entire file. Without IPP it is taking on average 1.1 seconds.
I've also tested this directly within my application and seeing a similar performance drop with my app.
I'm using clock_gettime(CLOCK_MONOTONIC) to measure the amount of time it takes for gz_compress to complete within minigzip. I do get some occasionally erratic results though with IPP achieving lower minimums of around 700 milliseconds and the non IPP achieving a minimum of 870 milliseconds but these are the rarer cases. Not sure if there is something I'm doing that can result in such a large standard deviation between runs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info. We will investigate first and update here if we have any progress.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
Looks we can't reproduce the performance issue. Can you share us a simple reproducer as well as the steps that you perform.
Regards,
Ruqiu

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page