GNOME Bugzilla – Bug 791424
multithreading slows down color to grey
Last modified: 2017-12-13 23:33:33 UTC
Just installed 2.9.6 on Arch and I've found that c2g is much slower when multithreading is enabled. watching top with 8 threads allowed (4 core/8 thread cpu) I see all cores being used but its only using 20% of each core setting it to 1 thread it uses 100% of 1 core and goes much quicker. watching the display tiles they look smaller than gimp 2.8 if that size feeds c2g perhaps it needs to be much larger to overcome lock contention?
Confirmed. This operation is already quite slow in single-threaded actually, but as multi-thread, it is just slow as hell. I did a test on some photography, it took about 2 minutes in single-threaded, and 12 minutes with 4 threads (I did not do an accurate timing because the runtime difference is so huge that it it not useful)! So I disabled multi-threading for this operation so that the rest of GIMP can be used multi-threaded while this will run single-threaded until we optimize it. Also moving to GEGL because that's where it will happen. commit 58fcebb96505459c9aa29f910f04315d988e9c0c (HEAD -> master, origin/master, origin/HEAD) Author: Jehan <jehan@girinstud.io> Date: Sun Dec 10 16:22:24 2017 +0100 Bug 791424 - multithreading slows down color to grey. This makes the operation unbearably slow though the results don't seem wrong. Let's disable multi-threading until we improve this. operations/common/c2g.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
For info I see no obvious difference in images produced with multi and single-threaded c2g, but after exporting to PNG and running: > gegl img1.png -o diff.png -- gegl:image-compare aux=[ gegl:load path=img2.png ] It looks like the pixels are actually different. So the gegl:c2g operation produces different result with threading. P.S.: also realizing that I didn't need to do this. Just using a difference layer mode also shows that the pixels are not identical.
The difference in output is due to use og GRand instead of position dependent seeds with gegl_random (or a stable seed if it is a LUT being used). The observed slow-down isn't really a problem with color to grey - but how badly the multiple nearest neighbour samplers seem to deal with multi threading.
commit 48ca09d7342a4cd0742bb04af8211cc4e3093579 Author: Ell <ell_se@yahoo.com> Date: Wed Dec 13 03:53:27 2017 -0500 Bug 791424 - multithreading slows down color to grey After the last commit, reenabling multithreading for c2g makes it notably faster when GEGL_THREADS>1 (however, it only brings it on- par to GEGL_THREADS=1.) This reverts commit 58fcebb96505459c9aa29f910f04315d988e9c0c.