zip decompression and multithreading
Uwe <[email protected]> Mon, 4 Jun 2018 18:22:45 +0200
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Organization | Science-D-Visions |
| Message-ID | <[email protected]> |
Hello everyone, I am using openexr-2.2.1 on Linux and OSX. I'm developing an application which loads a sequence of zip-compressed EXR-files and converts them into some kind of archive. I would like to load and dispatch images multithreaded. I'm testing my application on a 12-core machine running linux, so, watching performance by means of 'top' (the shell command) should ideally give a performance of nearly 1200%, but I get only 150%. If I analyze this with gdb, I see that in fact I have 12 threads (the ones I created myself outside openexr), but 11 of them are waiting at some mutex within openexr, while the 12th is busy decompressing somewhere inside zlib. What I would like to have is 12 threads decompressing... One solution seems to be to compile openexr with option --enable-threading=false, so that openexr uses a single thread for everything, but my applications runs 12 threads reading exr-files. If I do this, I nearly get the full performance, something around 1050% for 12 cores, but this might slow down other decompression modes. My question is: 1. Is there some reason for openexr to use only one thread for decompressing with zip? As far as I know zlib is thread-safe, so I'm puzzled... 2. Or is there a way to enforce multithreading during zip-decompression? Best regards Uwe Sassenberg