Convert not using multiple threads

Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
Post Reply
Bingo
Posts: 24
Joined: 2007-03-26T03:43:14-07:00

Convert not using multiple threads

Post 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 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
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 !
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Convert not using multiple threads

Post 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.
snibgo's IM pages: im.snibgo.com
Bingo
Posts: 24
Joined: 2007-03-26T03:43:14-07:00

Re: Convert not using multiple threads

Post 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 ?
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Convert not using multiple threads

Post 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.
snibgo's IM pages: im.snibgo.com
Bingo
Posts: 24
Joined: 2007-03-26T03:43:14-07:00

Re: Convert not using multiple threads

Post 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 ?
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Convert not using multiple threads

Post by snibgo »

I don't know, sorry. Perhaps a developer will comment. You could try adding it, and see if that makes a difference.
snibgo's IM pages: im.snibgo.com
Bingo
Posts: 24
Joined: 2007-03-26T03:43:14-07:00

Re: Convert not using multiple threads

Post 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 !
Post Reply