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 20:21 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 20:45 "Re: [Tiff] OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 23:27 "Re: [Tiff] OpenMP enabled libtiff", by Mikhail
[...]

2016.01.25 20:45 "Re: [Tiff] OpenMP enabled libtiff", by Bob Friesenhahn

I believe SSDs perform well under multiple reads, but this would

> have to be carefully bench-marked, of course.  

For NVMe, this is very true, for SAS more true, for SATA (most common) not very true at all. But SSDs normally have low latency and a high transfer rate so multiple reads do not help so much. Multiple reads helps more for traditional hard disks, and particularly RAID arrays, where many reads can be scheduled for the hardware at once and the latencies are relatively large.

Thanks. easy way might be to partition ahead of time which   One strips are processed by which threads. I will take a look at the code and see if I can come up with a simple way of doing this.

Are you talking about the simplified RGBA interfaces intended for "new" users? Serious applications do not use those interfaces.

It would be ideal to support reading/writing multiple strips/tiles at once using multiple threads on a single TIFF handle, with each thread allocating and holding its own allocated handle to store thread-specific data. This would require enhancements to the libtiff API.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/