2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer

2016.01.26 16:01 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer

On Tue, Jan 26, 2016 at 9:46 AM, Olivier Paquet <olivier.paquet@gmail.com> wrote:

2016-01-26 8:45 GMT-05:00 Aaron Boxer <boxerab@gmail.com>:

Sounds like the simplest approach is to allow the user to set a lock callback method,

which, if not null, will protect the global/static variables with a lock of the user's choice.

I'm not sure that would do much without a lot of other work. As has been said, the bulk of CPU work is in the compressors and if I remember correctly they have a significant amount of preallocated state. This needs to be duplicated for each thread to get any useful speedup.

IMO, the cleanest approach is to split read/write and decompression/compression and make the latter thread safe (no global/static data in that part of the code). Then OpenMP or whatever else can be used at a higher level to run the compression work in multiple threads.

It's all a lot of work though because the code is not written with that in mind at all and the compressor can change when you move to a different IFD. As we only needed multithread reading in our project, what we did instead is use several TIFF handles on the same file. This works well enough for reading.

Yes, so you don't think there is a "quick and dirty" solution for speeding up compressed reading?

For my purposes, I am only interested in reading uncompressed files, so TIFFClientOpen

on a memory buffer should be good enough.

But, I still think it is a shame to leave the library single threaded in this multi-core world.

It is just finding the time to work on improvements.