Hi Bob,

As some of you may be aware, GraphicsMagick has become multithreaded via OpenMP.

That's a big improvement. Congrats to all GraphicsMagick team.

As you have already discovered, lcms 1.x has some important issues on multithreading. Some have been adressed in lcms 2.0, so maybe the best option here would be to give a try to new code to see how many of those issues are gone. First beta is expected to be available in a month or two. Meanwhile, you could use the development snapshop which is
complete but lacks documentation and qualification (so it is still buggy):

http://www.littlecms.com/lcms-2.0-sep-2.tar.gz

There is a multithreaded version of cmsCreateTransformTHR() which accepts a ThreadID which may be passed to the memory management and error logging to identify the thread. Also, the function should be re-entrant. In the case you wish to check it, please let me
know if it works to you (it does in my testing).

Best regards
Marti


Bob Friesenhahn wrote:
As some of you may be aware, GraphicsMagick has become multithreaded via OpenMP.

My original implementation of speeding up CMS transforms assumed that lcms is thread safe so that all threads shared the same transform created by cmsCreateTransform(). It turns out that lcms is not as thread safe as desired. Several profiles cause image corruption if lcms is used in this way. Even without the corruption, there is no speedup from multithreading (just more CPU consumption) so there must be some read/write contention for shared data which does not happen to influence the result in the common case.

I tried building lcms using its special thread safety option and this did eliminate the image corruption, but it also made lcms several orders of magnitude slower.

My current implementation uses cmsCreateTransform() to create an independent transform for use by each thread. This avoids image corruption and I see linear speedup with efficient use of the CPU.

Unfortunately, it turns out that cmsCreateTransform() is not thread safe. In order to improve performance on NUMA hardware it would be beneficial for cmsCreateTransform() to be invoked by the thread which will be using the data. Since cmsCreateTransform() blows up if several threads invoke it at once, I have to prepare the transforms in advance, so the memory is allocated ideally for the thread which prepares the transforms but not for the rest of the worker threads.

Is there a better way to multithread the use of lcms without invoking cmsCreateTransform() sequentially in advance for the number of worker threads?

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.78/2347 - Release Date: 09/05/09 05:51:00


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Reply via email to