AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer
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 09:36 "Re: [Tiff] OpenMP enabled libtiff", by Mat Maher
2016.01.26 09:52 "Re: [Tiff] OpenMP enabled libtiff", by Even Rouault
2016.01.26 14:22 "Re: [Tiff] OpenMP enabled libtiff", by Fred Rothganger
[...]

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:

  1. . Performance of disk read/writes
  2. . 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:

  1. . 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)
  2. . 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.