- 2016.01.25 19:05 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
-
2016.01.26 09:12 "Re: [Tiff] OpenMP enabled libtiff", by John
-
2016.01.26 13:45 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
-
2016.01.26 14:46 "Re: [Tiff] OpenMP enabled libtiff", by Olivier Paquet
- 2016.01.26 16:01 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
- 2016.01.26 19:29 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
-
2016.01.26 14:46 "Re: [Tiff] OpenMP enabled libtiff", by Olivier Paquet
-
2016.01.26 13:45 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
- 2016.01.26 09:36 "Re: [Tiff] OpenMP enabled libtiff", by Mat Maher
2016.01.26 09:36 "Re: [Tiff] OpenMP enabled libtiff", by Mat Maher
Hello List,
Is anyone interested in having OpenMP support in libtiff?
Is this feasible? am planning on adding this feature for another project I I am working on, so I am trying to gauge interest.
libTiff performance is governed by two factors:
- . Performance of disk read/writes
- . Performance of compression/decompression routines (eg CPU)
The latter would benefit enormously from multi-threaded implementation, BUT, will ultimately be throttled by the former.
There are a few simple things which could be done to improve matters:
- . Buffer the entire file in memory for processing. HOWEVER, this would only work with a user switch input, as it's always possible the application TIFFs would be larger than available memory. 'Blasting' an entire file to/from disk maximises the transfer rate due to seek-times and DMA-setup latencies. In this scenario, you will end up reading/writing at the line-rate of the disk: which about as fast as you can get (and actually, for write operations, shows SATA as the faster medium for file sizes > SSD cache)
- . Implement thread-per-strip CPU processing.
For these changes, I actually wouldn't use OpenMP. The TIFF strip arrangement is a perfect division for multi-threading utilisation. Trying to multi-thread at a lower granularity than this is likely to yield lower performance due to the compression/decompression libraries which are largely sequential in operation.
Mat
This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal.