After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791424 - multithreading slows down color to grey
multithreading slows down color to grey
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: operations
git master
Other Linux
: Normal normal
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2017-12-09 23:39 UTC by Bret Towe
Modified: 2017-12-13 23:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bret Towe 2017-12-09 23:39:21 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?
Comment 1 Jehan 2017-12-10 16:00:28 UTC
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(-)
Comment 2 Jehan 2017-12-10 17:09:06 UTC
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.
Comment 3 Øyvind Kolås (pippin) 2017-12-10 22:25:26 UTC
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.
Comment 4 Øyvind Kolås (pippin) 2017-12-13 23:33:33 UTC
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.