AWARE [SYSTEMS]
AWare Systems, Home TIFF and LibTiff Mail List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2016

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



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
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.