2017.11.20 17:04 "[Tiff] TIFF tag and compression registration", by Kemp Watson

2018.01.16 00:15 "Re: [Tiff] Strategies for multi-core speedups", by Bob Friesenhahn

On Mon, 15 Jan 2018, Mike Stanton wrote:

> To begin with I am an Operating Systems guy. When you are looking > at going to multi-threading, what have you determined as your

> setup/teardown cost for the individual threads? How large a chunk > will each thread be processing? Will the individual Scan-lines

> and/or Tiles be sufficiently large to absorb the cost of that setup > and teardown by the inherent performance you are projecting?

It is normal to use a pool of threads where threads are created in advance (or added to the pool on demand) and obtained from, and returned to, the pool. This significantly reduces overheads caused by starting/stopping threads.

The performance gain does depend heavily on how much work each thread has to do. If there is not enough work, then there could be a performance penalty. Choosing how many threads to use and how to partition the work for each thread is a major part of tuning an application.

How the threading would be done is up to the user (e.g. OpenMP, SILK, TBB, home-brew) since no one is suggesting that libtiff incorporate threads. Libtiff should provide interfaces which take threading into account (when possible).

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