AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing 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
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2016.01.25 18:25 "OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:05 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:17 "Re: OpenMP enabled libtiff", by <kandel3@illinois.edu>
2016.01.25 19:18 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 20:21 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 20:45 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.25 23:27 "Re: OpenMP enabled libtiff", by <kandel3@illinois.edu>
2016.01.26 09:12 "Re: OpenMP enabled libtiff", by <jcupitt@gmail.com>
2016.01.26 13:45 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 14:46 "Re: OpenMP enabled libtiff", by Olivier Paquet
2016.01.26 16:01 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 17:10 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.26 19:32 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 19:29 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 20:36 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.27 18:32 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.27 19:55 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.29 13:28 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 14:46 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.29 15:48 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 15:49 "Re: OpenMP enabled libtiff", by Aaron Boxer
2016.01.29 18:12 "Re: OpenMP enabled libtiff", by Bob Friesenhahn
2016.01.26 09:36 "Re: OpenMP enabled libtiff", by Mat Maher
2016.01.26 09:52 "Re: OpenMP enabled libtiff", by Even Rouault
2016.01.26 14:22 "Re: OpenMP enabled libtiff", by Fred Rothganger
2016.01.27 18:51 "Re: OpenMP enabled libtiff", by Larry Gritz

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

On Mon, 25 Jan 2016, Aaron Boxer wrote:
> 
> 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.  One easy way might be to partition ahead of time which 
> 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/