[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Openexr-devel] zip decompression and multithreading
From: |
Uwe |
Subject: |
[Openexr-devel] zip decompression and multithreading |
Date: |
Mon, 4 Jun 2018 18:22:45 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 |
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
- [Openexr-devel] zip decompression and multithreading,
Uwe <=