Page 1 of 1

Convert not using multiple threads

Posted: 2017-11-10T01:33:01-07:00
by Bingo
Hi all,

I am using IM 6.9.3-8 Q16 x64 2016-04-10 (I know it's quite old, but I've had some problems trying to upgrade, I might start another thread on the subject).

I run this command :

Code: Select all

convert.exe -limit memory 5000 -density 1600 -set colorspace RGB -background white source.eps -flatten +matte -compress LZW -depth 8 -crop 1000x1000 dest.tif
It runs fine, but it only uses a single core.
Since the eps is quite large, and using density 1600, the output image is very big and would definitively benefit from multiple threads.

version tells me I have a version compiled with OpenMP, so I don't know what limits the number of core used ?

output of version :

Code: Select all

Version: ImageMagick 6.9.3-8 Q16 x64 2016-04-10
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
Visual C++: 180040629
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib cairo freetype jng jp2 jpeg lcms lqr openexr pangocairo png ps rsvg tiff webp xml zlib
Any help would be appreciated !

Re: Convert not using multiple threads

Posted: 2017-11-10T02:56:41-07:00
by snibgo
Reading the EPS is done by a delegate, Ghostscript, and IM has no influence over whether GD [EDIT: I meant GS] uses multiple threads.

"-flatten" and writing the LZW compressed tif might be capable of being multithreaded, but I don't think the writing (in coders/tiff.c) is.

Re: Convert not using multiple threads

Posted: 2017-11-10T03:31:09-07:00
by Bingo
Ah, yes, GhostScript ! I forgot about that, thanks !
So if flatten & LZW compressed tif is multithreaded, should I see an increase in the number of threads used at the end of the conversion process ?

Re: Convert not using multiple threads

Posted: 2017-11-10T03:51:35-07:00
by snibgo
Sorry, I wasn't clear. I've looked at the code that writes LZW compressed TIFF (and any other form of TIFF), and I don't think it's multi-threaded. It does "SetMagickThreadValue()", and I don't know what that does, but I don't think the actual code uses multiple threads.

"-flatten" uses MergeImageLayers() which uses CompositeImage() which does use multithreading. But this doesn't mean it will always be multi-threaded; IM uses a formula to determine whether multi-threading is worth the effort.

I expect "-flatten" to be a very small part of your overall command. It's just a single pass over the image. Even if multi-threading reduced the time taken to "-flatten" to zero, it wouldn't have much impact on the overall command.

Re: Convert not using multiple threads

Posted: 2017-11-10T04:03:39-07:00
by Bingo
Yes, I never really benchmarked the command, but I believe that reading the EPS and expand it to a raster is the most expensive operation.
And that is handled by GhostScript.
BTW, since EPS are using a delegate, I checked in delegates.xml, and there is no dNumRenderingThreads option in the command line. Is there a reason for this ?

Re: Convert not using multiple threads

Posted: 2017-11-10T04:19:32-07:00
by snibgo
I don't know, sorry. Perhaps a developer will comment. You could try adding it, and see if that makes a difference.

Re: Convert not using multiple threads

Posted: 2017-11-10T05:54:59-07:00
by Bingo
I added it but AFAICT there is no difference.
I thought that gs was the most expensive operation, but from what I see in Process Explorer it definitively isn't.
I do see convert running on all cores at some point though, but again this is very brief and most of the time it is running in a single thread.

Thanks for your help !