Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

Ways to improve Gimp 2.9 performance

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

24 of 24 messages available
Toggle history

Please log in to manage your subscriptions.

Ways to improve Gimp 2.9 performance Elle Stone 28 Feb 17:16
  Ways to improve Gimp 2.9 performance Nicolas Robidoux 28 Feb 18:30
   Ways to improve Gimp 2.9 performance Elle Stone 28 Feb 19:19
    Ways to improve Gimp 2.9 performance Nicolas Robidoux 28 Feb 19:29
  Ways to improve Gimp 2.9 performance Liam R E Quin 28 Feb 18:42
   Ways to improve Gimp 2.9 performance Elle Stone 28 Feb 19:51
    Ways to improve Gimp 2.9 performance Daniel Sabo 28 Feb 20:05
     Ways to improve Gimp 2.9 performance Elle Stone 28 Feb 22:07
      Ways to improve Gimp 2.9 performance Daniel Sabo 28 Feb 22:47
       Ways to improve Gimp 2.9 performance Elle Stone 02 Mar 13:49
        Ways to improve Gimp 2.9 performance Partha Bagchi 02 Mar 14:36
         Ways to improve Gimp 2.9 performance Elle Stone 02 Mar 15:00
          Ways to improve Gimp 2.9 performance Partha Bagchi 02 Mar 15:31
         Ways to improve Gimp 2.9 performance Elle Stone 22 Mar 20:34
          Ways to improve Gimp 2.9 performance Liam R E Quin 23 Mar 04:50
           Ways to improve Gimp 2.9 performance Nicolas Robidoux 23 Mar 15:39
            Ways to improve Gimp 2.9 performance Clayton Walker 23 Mar 19:17
             Ways to improve Gimp 2.9 performance Elle Stone 23 Mar 19:42
        Ways to improve Gimp 2.9 performance Nicolas Robidoux 02 Mar 14:55
         Ways to improve Gimp 2.9 performance Carsten Juttner 02 Mar 19:46
          Ways to improve Gimp 2.9 performance Nicolas Robidoux 02 Mar 21:15
           Ways to improve Gimp 2.9 performance Carsten Juttner 02 Mar 21:38
    Ways to improve Gimp 2.9 performance Liam R E Quin 28 Feb 22:05
     Ways to improve Gimp 2.9 performance Elle Stone 28 Feb 22:32
Elle Stone
2013-02-28 17:16:19 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

When working with full-size camera files (3906 X 2602 px, not large compared to more recent cameras), Gimp runs at 100% CPU. Painting a brush stroke takes forever, my system swap drives fill up completely, etc. And yesterday Gimp filled up 15GB's worth of empty space in my home directory, leaving mere kilobytes of empty space - I'm not sure what file was taking up all the space, but it disappeared as soon as I closed Gimp.

So I'm seeking advice on how to improve performance. I broke the question into 3 parts:

1. Hardware 2. Configuring Gimp
3. Image size, type, precision

1. Hardware

What are the recommended (not miminal) system specifications for running Gimp? My system specs are:

*1 single-core 2.6 GHz processor (the system board will take 2 processors, but only single core)
*4GB ram; the system board will hold 16GB *256MB nvidia GeForce 7600 GTgraphics card *4 sata hard drives (I don't think I set the sata drives correctly to take advantage of their fastest write speeds)

Short of building a new computer (not going to happen!), what else can I do to improve Gimp performance? Which hardware upgrade(s) might give the most performance improvement for the least amount of money?

*We can replace the single processor with two slightly faster processors. Will two processors make a difference? *Will reconfiguring the sata drives to use their fastest write speed help? How much does write speed matter? *Are there figures for optimal RAM, other than "as much as possible"? *How much does the GPU affect Gimp's processing speed? Would upgrading the graphics card help? If so, how much of an upgrade would it take to make a perceptible difference?
*Other possibilities?

2. Configuring Gimp:

I'm running 64-bit openSUSE 12.2 with the Icewm minimal window manager. I set the Gimp tile cache size to 3GB, and I've followed much of Aaron Paden's Gimp setup advice:
http://gimp.1065349.n5.nabble.com/gimp-2-8-prohibitively-slow-td34425.html

Given that my computer has four physical hard drives, is there an optimal way to allocate GimpSwap, Gimp temporary folder, the location of the image files I'm working on, system swap, and etc? Here is my current arrangement:

*HD1: all system folders, including the "tmp" folder that Gimp uses (Preferences/Folders). Also my home directory and all the Gimp configuration files are on HD1.
*HD2: The GimpSwap (Preferences/Folders) is on this drive (along with other stuff, of course)
*HD3: There is a 3GB system swap partition on this drive. Also this HD is where any images that I'm editing with Gimp are located. *HD4: There is a second 3GB system swap partition on this drive.

*Would it help if I add a third system swap partition on the second hard drive? Or move the image being edited to the drive that doesn't have a system swap partition?
*Does it matter how many dockers are open? *Does it matter how many system fonts are installed? *Would it help if the Temporary Folder and/or the GimpSwap had their own partition (not a whole separate drive, but a separate partition on an existing drive), instead of just their own folder? Should the Temporary Folder be on a drive separate from the Gimp configuration files? What are these two folders used for? *Anything else?

3. Image size, type, precision

Short of working on smaller files, what else affects how much processing power Gimp needs? Specifically,

*Does it make a difference what precision is used? 32-bit floating point vs 16-bit integer?
*Does it make a difference if the image is grayscale rather than RGB (one channel rather than 3)?
*Does the total number of layers, masks, and/or alpha channels matter? Or is it just the overall image size in pixels? *Anything else?

I know Gimp 2.9 is a work in progress and likely things will get faster as times goes on. But in the meantime, any advice on how to improve performance would be greatly appreciated.

Kind regards, Elle Stone

http://ninedegreesbelow.com - articles on open source digital photography
Nicolas Robidoux
2013-02-28 18:30:04 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

Warning: Untested

If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source, maybe you should try

CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ...

instead of the usual

./autogen.sh ...

This may, or may not, make a noticeable difference.

But if I was concerned about speed on my specific hardware, I'd try that first.

And actually, if I do this with BABL and GEGL, make check within GEGL runs 26% faster on my modest laptop.

So, my guess is that propagating the above suggestion to GIMP itself and a few key libraries may make things slightly less painful.

Liam R E Quin
2013-02-28 18:42:53 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On Thu, 2013-02-28 at 12:16 -0500, Elle Stone wrote:

Short of building a new computer (not going to happen!), what else can I do to improve Gimp performance? Which hardware upgrade(s) might give the most performance improvement for the least amount of money?

More memory. Max it out.

In the meantime, (1) look at what other processes are running - e.g. in "top" you can press M (not m) to sort processes by size, and the results can sometimes be surprising...

(2) in gimp...

make the gimp tile cache be large - this is the amount of the image gimp will keep in memory, and for a 4G 64-bit system you want it to be 3G, for a 16G system I'd set it to 12 or 4G probably.

even with more memory gimp goes faster if you clear the undo history frequently. Save snapshots as needed... and then... to do this... i) make sure the Undo history dock is visible ii) press the Rubbish/Waste/Trash/Clean/Broom icon (it depends on theme) at the bottom of the undo history dock to clear the undo history. iii) make sure the title or status bar of gimp shows you memory usage, and when it grows by more than about 500MBytes, clear the history again.

*We can replace the single processor with two slightly faster processors. Will two processors make a difference?

Somewhat, because one can be running gimp while the other is working on updating the screen, running the Web browser etc.

*Will reconfiguring the sata drives to use their fastest write speed help? How much does write speed matter?

Not significantly - read speed matters more on Unix/Linux systems, because writing todisk is done in the background aynchronously.

*Are there figures for optimal RAM, other than "as much as possible"?

I have 8G for use with GIMP 2.7 or 2.8. I am about to order a system with 32G for using higher bit depths.

*How much does the GPU affect Gimp's processing speed? Would upgrading the graphics card help? If so, how much of an upgrade would it take to make a perceptible difference?

Make sure you have the latest driver offered by your Linux distribution; the non-free drivers for nvidia and ati cards make a huge difference but they ypically need ot be patched slightly by your Linux distribution or things may go horribly slwoly and/or wrong (the drivers by default overwrite some of the standard X libraries)

Turn off 3d desktop effects, as these can make gimp painting go two, three, or more times more slowly (e.g. do not run compiz).

*Does it matter how many system fonts are installed?

Doesn't seem to for me but I have 8G of ram. $ fc-list | wc -l
2533

so I have 2,500 fonts installed right now (and many more that are not installed).

3. Image size, type, precision

Short of working on smaller files, what else affects how much processing power Gimp needs? Specifically,

*Does it make a difference what precision is used? 32-bit floating point vs 16-bit integer?

8-bit grayscale is fastest by far, and usually what I use.

Avoid transparency (alpha channel) if you don't need it, and flatten a single-layer image after any transform operation.

For some filters you need RGB mode, and then can go back to greyscale afterwards (sometimes it's surprising which filters they are - but as the filters get ported to GEGL that will probably change)

*Does the total number of layers, masks, and/or alpha channels matter? Or is it just the overall image size in pixels?

It's (roughly) overall image size times number of image-sized layers.

For more detail, say which operations exactly are unbearably slow....

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Elle Stone
2013-02-28 19:19:12 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On 2/28/13, Nicolas Robidoux wrote:

Warning: Untested

If you build/compile GIMP and key libraries (e.g. GEGL, BABL) from source, maybe you should try

CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3" ./autogen.sh ...

CFLAGS is for c code CXXFLAGS is for c++ code, according to info gleaned from stackoverflow. Does Gimp, babl, and/or gegl have any c++ code? Does it hurt to use both? I think I'll give this a try, can't hurt, right?

Nicolas Robidoux
2013-02-28 19:29:30 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

There is a little bit of c++ floating around here and there TTBOMK.

-----

Make sure to wear safety goggles and a flak jacket.

Elle Stone
2013-02-28 19:51:51 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On 2/28/13, Liam R E Quin wrote:

In the meantime,
(1) look at what other processes are running - e.g. in "top" you can press M (not m) to sort processes by size, and the results can sometimes be surprising...

Thanks very much! for the tip on how to sort in top.

(2) in gimp...
even with more memory gimp goes faster if you clear the undo history frequently. Save snapshots as needed... and then... to do this... i) make sure the Undo history dock is visible ii) press the Rubbish/Waste/Trash/Clean/Broom icon (it depends on theme) at the bottom of the undo history dock to clear the undo history. iii) make sure the title or status bar of gimp shows you memory usage, and when it grows by more than about 500MBytes, clear the history again.

These are things I haven't been doing, will give it a try.

Make sure you have the latest driver offered by your Linux distribution; the non-free drivers for nvidia and ati cards make a huge difference but they ypically need ot be patched slightly by your Linux distribution or things may go horribly slwoly and/or wrong (the drivers by default overwrite some of the standard X libraries)

I switched to the nonfree nvidia distributed by openSUSE because the nonfree driver manages the fan better. Do you think the openSUSE version might be properly patched? I was using nouveaux, could go back to it.

Turn off 3d desktop effects, as these can make gimp painting go two, three, or more times more slowly (e.g. do not run compiz).

*Does it matter how many system fonts are installed?

Doesn't seem to for me but I have 8G of ram. so I have 2,500 fonts installed right now (and many more that are not installed).

That's a lot of fonts!

3. Image size, type, precision

8-bit grayscale is fastest by far, and usually what I use. Avoid transparency (alpha channel) if you don't need it, and flatten a single-layer image after any transform operation. For some filters you need RGB mode, and then can go back to greyscale afterwards (sometimes it's surprising which filters they are - but as the filters get ported to GEGL that will probably change)

I need 16-bit precision for working with linear gamma files. I'm already switching back and forth between grayscale and RGB as needed, but I wasn't sure if it made much difference. I also wasn't sure if 16f vs 32f made any difference as gegl processes at double? precision 32f.

*Does the total number of layers, masks, and/or alpha channels matter? Or is it just the overall image size in pixels?

It's (roughly) overall image size times number of image-sized layers.

OK, good to know. Gimp seems to throw in alpha channels all over the place, not sure why. I never add alpha channels deliberately, but I've been deleting a lot of them.

For more detail, say which operations exactly are unbearably slow....

I do a lot of painting with large and small brushes on layer masks. That brush just crawls across the screen, makes real-time painting impossible. I think I will try working on scaled-down files until the masks are right, then scale up to the original size and drag the masks over to the full-sized image file.

Regarding how to make optimal use of the available hard drives, there was a time when working on one drive, with swap files on another drive, etc really did make a big difference for image editing applications. I'm not sure about today's hard drives (and none of my drives are "today's"). Any thoughts on optimal layout of swap, GimpSwap, Gimp's temporary folder, and the actual working image files? And do you have any idea what large file(s) might Gimp have been writing to its system configuration file that filled up 15GB? The undo history?

Thanks very much! for all the concrete information. I will be putting it to good use. One nice thing about having two processors instead of just the one is I'll be able to add twice as much ram, which seems to be the main thing needed for faster image editing.

Elle

Daniel Sabo
2013-02-28 20:05:20 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

You might want to try running gimp with GEGL's swap turned off, this will avoid filling up your drive with cache files: GEGL_SWAP=RAM gimp-2.9

If you don't have OpenCL set up forcing it off will give a bit of a performance boost (due to a bug in the detection code): GEGL_USE_OPENCL=no GEGL_SWAP=RAM gimp-2.9

Painting speed is due to bugs in GEGL and Gimp's paint core, there's really nothing you can do right now to get it speedy.

- Daniel

Liam R E Quin
2013-02-28 22:05:34 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On Thu, 2013-02-28 at 14:51 -0500, Elle Stone wrote:

On 2/28/13, Liam R E Quin wrote:

I switched to the nonfree nvidia distributed by openSUSE because the nonfree driver manages the fan better. Do you think the openSUSE version might be properly patched?

Yes, that's fine, just avoid downloading the drivers from Nvidia's Web site.

so I have 2,500 fonts installed right now (and many more that are not installed).

That's a lot of fonts!

There are about as many again in my Adobe Font Folio folder.

Quark Express used to have the notion of a "project folder", and if you put fonts in it, they'd be activated only when working on the files in that folder. I miss this, but gimp is scatterbrained when it comes to folders, with export going to the last place where you saved something two days ago for an unrelated project unless you are careful.

[...]

I need 16-bit precision for working with linear gamma files. I'm already switching back and forth between grayscale and RGB as needed, but I wasn't sure if it made much difference. I also wasn't sure if 16f vs 32f made any difference as gegl processes at double? precision 32f.

OK, for 2.9 I have not measured.

[...]

For more detail, say which operations exactly are unbearably slow....

I do a lot of painting with large and small brushes on layer masks. That brush just crawls across the screen, makes real-time painting impossible. I think I will try working on scaled-down files until the masks are right, then scale up to the original size and drag the masks over to the full-sized image file.

Years ago there were programs that could automate this workflow.

Turning off 3D effects / compiz can increase drawing speed, and so can clearing the undo history often (that might be changed in 2.9 though).

I'm still using 2.7/2.8 because of some filters that I used a lot not being ported (and I'm too busy to think about porting them, sigh), e.g. "sharpen".

Regarding how to make optimal use of the available hard drives, there was a time when working on one drive, with swap files on another drive, etc really did make a big difference for image editing applications.

It still does, but if you have enough memory GIMP won't be accessing the disk while you work, and it won't make as much difference apart from startup and image loading times.

And do you have any idea what large file(s) might Gimp have been writing to its system configuration file that filled up 15GB? The undo history?

Yes, the tile cache and undo history. And if it was that big, your gimp would *really* have had a limp.

My guess is that post-gegl gimp will need much more memory, and this has been my experience so far.

I have just ordered a desktop computer with 32G of ram... next will be to try and get xsane to speak 16 bits per channel (the widest my scanner offers) to gimp without requiring an intermediate file.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Elle Stone
2013-02-28 22:07:07 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

I followed Nicolas' suggestion and recompiled babl, gegl and gimp with CFLAGS="-march=native -O3" CXXFLAGS="-march=native -O3". The computer didn't blow up or anything. But I can't say whether Gimp runs any faster.

The idea of optimization seemed promising and I found this thread: http://www.gimpusers.com/forums/gimp-user/14320-benchmarking-gimp-gegl#message66197

Does optimization depend on the actual processor? Is there a set of optimizations that makes sense for a circa 2005 AMD Opteron 252 (soon to be 262) processor? It has built-in floating point etc, was considered very fast when doing mathematical operations (that's why I picked it). What about these: -Ofast -ffast-math -ftree-vectorize ? Others? Is there any danger to the computer when recompiling packages using these flags? Or just the danger of the occasional math error?

What about cairo, gtk, etc? Would it make sense to compile these from source using optimizations of some sort or another? Or are they already compiled with all sensible optimizations by openSUSE?

On 2/28/13, Daniel Sabo wrote:

You might want to try running gimp with GEGL's swap turned off, this will avoid filling up your drive with cache files: GEGL_SWAP=RAM gimp-2.9

Does this mean Gimp and gegl would be competing for my meagre 4gb of ram? I didn't know gegl wrote cache files. Where does gegl write its cache files?

If you don't have OpenCL set up forcing it off will give a bit of a performance boost (due to a bug in the detection code): GEGL_USE_OPENCL=no GEGL_SWAP=RAM gimp-2.9

How does one set up OpenCL? Is it just a matter of having the right graphics card and driver? I will try both ways, with and without opencl, and with nvidia driver and nouveau driver (both have OpenCL support, it seems) and see if there seems to be a difference. Is there a way to tell Gimp to use or not use OpenCL? Or a way to tell if it really is being used?

Painting speed is due to bugs in GEGL and Gimp's paint core, there's really nothing you can do right now to get it speedy.

Ah, well, someday... Other things are also slow. Just hiding/unhiding a layer is slow, until the image is resized down. 768x512 is reasonably fast, though the brush is still slower than I'd like it to be (but useable).

When compiling Gimp, would any of the following compile options speed things up while using Gimp? --without-libexif --without-aa --without-libxpm --without-libmng --without-wmf --without-webkit --without-librsvg --without-poppler --without-print --without-gvfs --without-alsa --without-mac-twain --disable-gtk-doc --without-script-fu --disable-python --without-dbus --without-linux-input --without-hal

And while I'm asking questions, what is the "Linux Input Controller module"? Does it have anything to do with tablet support (I use a tablet)?

Sorry to be asking so many questions! I've been using Gimp a lot in the last couple of weeks and liking it more and more and more, except for the speed of execution. So I'm trying to figure out what the options are for improving performance.

Elle

http://ninedegreesbelow.com - articles on open source digital photography
Elle Stone
2013-02-28 22:32:47 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On 2/28/13, Liam R E Quin wrote:

Quark Express used to have the notion of a "project folder", and if you put fonts in it, they'd be activated only when working on the files in that folder. I miss this, but gimp is scatterbrained when it comes to folders, with export going to the last place where you saved something two days ago for an unrelated project unless you are careful.

I've noticed this odd behavior. A project approach would be nice.

Turning off 3D effects / compiz can increase drawing speed

I use Icewm, which doesn't really have any "effects"; all the underlying kde eye candy (shadows on windows, hi-color icons, etc) has been eliminated.

And do you have any idea what large file(s) might Gimp have been writing to its system configuration file that filled up 15GB? The undo history?

Yes, the tile cache and undo history. And if it was that big, your gimp would *really* have had a limp.

It was stopped in its tracks. I used "kill" to put it out of its misery.

Elle

Daniel Sabo
2013-02-28 22:47:30 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

Does this mean Gimp and gegl would be competing for my meagre 4gb of ram? I didn't know gegl wrote cache files. Where does gegl write its cache files?

~/.cache/gegl-0.2/

Yes it will limit you to available ram for the image buffers; but if you're in a circumstance where you would actually need cache for a single image you'll already be in a lot of pain with the current GEGL code.

When compiling Gimp, would any of the following compile options speed things up while using Gimp? --without-libexif --without-aa --without-libxpm --without-libmng --without-wmf --without-webkit --without-librsvg --without-poppler --without-print --without-gvfs --without-alsa --without-mac-twain --disable-gtk-doc --without-script-fu --disable-python --without-dbus --without-linux-input --without-hal

And while I'm asking questions, what is the "Linux Input Controller module"? Does it have anything to do with tablet support (I use a tablet)?

Sorry to be asking so many questions! I've been using Gimp a lot in the last couple of weeks and liking it more and more and more, except for the speed of execution. So I'm trying to figure out what the options are for improving performance.

Nothing you can do at configure time is going to give you a meaningful performance improvement.

Elle Stone
2013-03-02 13:49:39 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

Being curious about optimization, I set up two identical installations of babl, gegl, and Gimp, in separate, side-by-side prefixes (same partition, hard drive):

In "gimp291" babl, gegl, and Gimp were compiled with ./autogen.sh . . .

In "gimp292" babl, gegl, and Gimp were compiled with CFLAGS="-march=native -Ofast" CXXFLAGS="${CFLAGS}" ./autogen.sh . . .

I made two copies of the same image (both copies in the same directory) and ran both Gimps simultaneously, started from a terminal using GEGL_SWAP=RAM. Then I did the same edits on both images, switching back and forth:

./gimp291.sh (not optimzed) Curves: 1.90939 MPixels/sec
Curves: 2.05433 MPixels/sec
Levels: 2.01868 MPixels/sec
Levels: 2.11656 MPixels/sec
Levels: 1.18821 MPixels/sec
(usm)
GEGL Operation: 1.55727 MPixels/sec
GEGL Operation: 1.98604 MPixels/sec
GEGL Operation: 1.46279 MPixels/sec
(blur)
GEGL Operation: 1.5169 MPixels/sec
GEGL Operation: 1.59023 MPixels/sec
GEGL Operation: 1.36274 MPixels/sec

./gimp292.sh (optimized) Curves: 2.952 MPixels/sec
Curves: 3.41224 MPixels/sec
Levels: 4.92665 MPixels/sec
Levels: 5.54835 MPixels/sec
Levels: 1.937 MPixels/sec
(usm)
GEGL Operation: 1.76634 MPixels/sec
GEGL Operation: 2.21788 MPixels/sec
GEGL Operation: 1.87769 MPixels/sec
(blur)
GEGL Operation: 2.02932 MPixels/sec
GEGL Operation: 2.04801 MPixels/sec
GEGL Operation: 1.80537 MPixels/sec

The identical test images were 1302 867 pixels. I monitored the ram usage on the status bars and both images showed the exact same amount of ram at each step of the editing process. I also monitored system ram using "free", and for the whole process there was plenty of free ram, with no writing to the system swap files. Comparing the numbers, the optimized babl/gegl/Gimp was always faster (higher MPixels/sec is better, yes?).

I also did a series of brush strokes using 50% opacity, hardness 50, 1000px paint brush, trying to keep the brush strokes identical for both versions of Gimp, switching back and forth between the two versions. Timing was subjective, of course, but the optimized Gimp brush strokes always completed in less time, sometimes in about half the time as the non-optimized Gimp.

References: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html http://openbenchmarking.org/result/1210138-RA-GCCAMDBUL77 http://www.gentoo.org/doc/en/gcc-optimization.xml http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt

The openbenchmarking article compares speed of execution of selected tasks using several open source programs that were compiled with different optimization levels. Usually but definitely not always -Ofast was the fastest.

There is no way a Linux distribution can optimize for a particular processor. So it sounds like it might actually help if the other programs on which Gimp depends, like Cairo and gtk, were also optimized. Has anyone tried this? Several sources mentioned programs that heavily use glibc as a possible exception to using higher levels of optimization. Would that affect Gimp?

Elle

http://ninedegreesbelow.com - articles on open source digital photography
Partha Bagchi
2013-03-02 14:36:46 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

I thought Gentoo was all about optimizing a linux distribution to your specific proecessor. :)

Anyway, try the following optimization and see if it makes a difference in your setup:

./autogen CFLAGS="-O3 -ffast-math -ftree-vectorize" ...

On Sat, Mar 2, 2013 at 8:49 AM, Elle Stone wrote:

Being curious about optimization, I set up two identical installations of babl, gegl, and Gimp, in separate, side-by-side prefixes (same partition, hard drive):

In "gimp291" babl, gegl, and Gimp were compiled with ./autogen.sh . . .

In "gimp292" babl, gegl, and Gimp were compiled with CFLAGS="-march=native -Ofast" CXXFLAGS="${CFLAGS}" ./autogen.sh . . .

I made two copies of the same image (both copies in the same directory) and ran both Gimps simultaneously, started from a terminal using GEGL_SWAP=RAM. Then I did the same edits on both images, switching back and forth:

./gimp291.sh (not optimzed) Curves: 1.90939 MPixels/sec
Curves: 2.05433 MPixels/sec
Levels: 2.01868 MPixels/sec
Levels: 2.11656 MPixels/sec
Levels: 1.18821 MPixels/sec
(usm)
GEGL Operation: 1.55727 MPixels/sec
GEGL Operation: 1.98604 MPixels/sec
GEGL Operation: 1.46279 MPixels/sec
(blur)
GEGL Operation: 1.5169 MPixels/sec
GEGL Operation: 1.59023 MPixels/sec
GEGL Operation: 1.36274 MPixels/sec

./gimp292.sh (optimized) Curves: 2.952 MPixels/sec
Curves: 3.41224 MPixels/sec
Levels: 4.92665 MPixels/sec
Levels: 5.54835 MPixels/sec
Levels: 1.937 MPixels/sec
(usm)
GEGL Operation: 1.76634 MPixels/sec
GEGL Operation: 2.21788 MPixels/sec
GEGL Operation: 1.87769 MPixels/sec
(blur)
GEGL Operation: 2.02932 MPixels/sec
GEGL Operation: 2.04801 MPixels/sec
GEGL Operation: 1.80537 MPixels/sec

The identical test images were 1302 × 867 pixels. I monitored the ram usage on the status bars and both images showed the exact same amount of ram at each step of the editing process. I also monitored system ram using "free", and for the whole process there was plenty of free ram, with no writing to the system swap files. Comparing the numbers, the optimized babl/gegl/Gimp was always faster (higher MPixels/sec is better, yes?).

I also did a series of brush strokes using 50% opacity, hardness 50, 1000px paint brush, trying to keep the brush strokes identical for both versions of Gimp, switching back and forth between the two versions. Timing was subjective, of course, but the optimized Gimp brush strokes always completed in less time, sometimes in about half the time as the non-optimized Gimp.

References: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html http://openbenchmarking.org/result/1210138-RA-GCCAMDBUL77 http://www.gentoo.org/doc/en/gcc-optimization.xml http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt

The openbenchmarking article compares speed of execution of selected tasks using several open source programs that were compiled with different optimization levels. Usually but definitely not always -Ofast was the fastest.

There is no way a Linux distribution can optimize for a particular processor. So it sounds like it might actually help if the other programs on which Gimp depends, like Cairo and gtk, were also optimized. Has anyone tried this? Several sources mentioned programs that heavily use glibc as a possible exception to using higher levels of optimization. Would that affect Gimp?

Elle

-- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Nicolas Robidoux
2013-03-02 14:55:50 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

Elle:

Factor of two in some cases. Not bad for two simple flags (-march=native -Ofast).

-----

If anybody wonders why -march=native is not used by these libraries by default, it's because it makes the binaries non-portable.

Also, the default build uses -g, which turns on debugging, for obvious reasons, but which of course gets in the way of performance.

Elle Stone
2013-03-02 15:00:50 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On 3/2/13, Partha Bagchi wrote:

I thought Gentoo was all about optimizing a linux distribution to your specific proecessor. :)

Anyway, try the following optimization and see if it makes a difference in your setup:

./autogen CFLAGS="-O3 -ffast-math -ftree-vectorize" ...

Sorry! I spoke in too broad a generalization. *Most* Linux distributions aren't optimized to a specific processor. Gentoo is set up so you roll your own, as is Linux from Scratch (others? Arch?). The Gentoo documentation recommends -O2 for general usage, to be on the safe side. The Linux from Scratch article recommends -O3. Neither article is especially new, so were written in reference to older versions of gcc.

Probably what level of optimization does what changes as gcc changes, but according to the gcc documentation, -Ofast includes -ffast-math and -ftree-vectorize. Is there a reason why using "-O3 -ffast-math -ftree-vectorize" might be better than using "-Ofast"?

Elle

Partha Bagchi
2013-03-02 15:31:29 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

Well, you have a point. But if you look at the documentation, it says:

-OfastDisregard strict standards compliance. -Ofast enables all -O3 optimizations.
It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math and the Fortran-specific -fno-protect-parens and -fstack-arrays.

So, While O3 turns on -ftree-vectorize, -Ofast is not strictly compliant and turns on fast-math, I do it separately I use the above incantation.

Finally, since I compile atk/glib/pango/cairo by myself, I do use the above optimization for all the builds.

Btw, I build Gimp on Windows and Mac, so your mileage may vary.

On Sat, Mar 2, 2013 at 10:00 AM, Elle Stone wrote:

On 3/2/13, Partha Bagchi wrote:

I thought Gentoo was all about optimizing a linux distribution to your specific proecessor. :)

Anyway, try the following optimization and see if it makes a difference

in

your setup:

./autogen CFLAGS="-O3 -ffast-math -ftree-vectorize" ...

Sorry! I spoke in too broad a generalization. *Most* Linux distributions aren't optimized to a specific processor. Gentoo is set up so you roll your own, as is Linux from Scratch (others? Arch?). The Gentoo documentation recommends -O2 for general usage, to be on the safe side. The Linux from Scratch article recommends -O3. Neither article is especially new, so were written in reference to older versions of gcc.

Probably what level of optimization does what changes as gcc changes, but according to the gcc documentation, -Ofast includes -ffast-math and -ftree-vectorize. Is there a reason why using "-O3 -ffast-math -ftree-vectorize" might be better than using "-Ofast"?

Elle

Carsten Juttner
2013-03-02 19:46:14 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On 03/02/2013 03:55 PM, Nicolas Robidoux wrote:

If anybody wonders why -march=native is not used by these libraries by default, it's because it makes the binaries non-portable.

Also, the default build uses -g, which turns on debugging, for obvious reasons, but which of course gets in the way of performance.

As far as I am aware the gcc option -g only adds debugging information (e.g. for gdb) but will not change the optimization level. So if these debug sections are stripped off the resulting executable will be identical.

Why do you think it will affect performance?

Regards, Carsten

Nicolas Robidoux
2013-03-02 21:15:52 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

Carsten Juttner
2013-03-02 21:38:59 UTC (almost 2 years ago)

Ways to improve Gimp 2.9 performance

On 03/02/2013 10:15 PM, Nicolas Robidoux wrote:

Indeed, maybe -g does not affect performance. I did not measure.

http://stackoverflow.com/questions/89603/how-does-the-debugging-option-g-change-the-binary-executable

Thanks for the link, interesting (and slightly unnerving) to read that the effect on optimizations is obviously compiler dependent.

Regards, Carsten

Elle Stone
2013-03-22 20:34:43 UTC (over 1 year ago)

Ways to improve Gimp 2.9 performance

More RAM does help quite a bit. With 12GB RAM instead of just 4GB. + using the optimized babl/gegl/Gimp installation. + starting Gimp with "GEGL_SWAP=RAM", painting with a brush is no longer quite the painful chore that it was.

The main sticking point now is redrawing the canvas (correct terminology?). Changing visibility, reordering layers, applying a blur, etc, makes the CPU run at 100% for what seems like a very long time. This is true even when the layer that was duplicated or reordered is completely hidden.

We also put in a second CPU, which literally cut compile times in half. But even though I specified "use 2 CPUs" in the Gimp "Edit/Preferences/Environment", Gimp still only uses 1 CPU at a time. It randomly switches back and forth between the two processors, but usually is using 100% of one CPU, and never gets over 50% total usage. So it doesn't seem to operate any faster with 2 CPUs than it did with one.

The odd thing is, even though Gimp is only using 50% of the total processing power, often other applications are frozen/unresponsive until Gimp is done.

I'd prefer that Gimp to monopolize both CPUs and get the job done twice as fast. Would a real-time kernel setup like the audio linux distributions use help? Is there a setting in Gimp that I missed? Or a compile-time switch in babl, gegl, or Gimp?

On 3/2/13, Partha Bagchi wrote:

I thought Gentoo was all about optimizing a linux distribution to your specific proecessor. :)

Partha's optimized Windows build has inspired me to do a test Gentoo install on a laptop, with the hopes of learning enough about Gentoo and optimization to be able to install a properly optimized Gentoo on my main computer. It will be interesting to see if Gimp runs any faster on a fully optimized Linux distribution.

Elle

Liam R E Quin
2013-03-23 04:50:54 UTC (over 1 year ago)

Ways to improve Gimp 2.9 performance

On Fri, 2013-03-22 at 16:34 -0400, Elle Stone wrote:

I'd prefer that Gimp to monopolize both CPUs and get the job done twice as fast. Would a real-time kernel setup like the audio linux distributions use help? Is there a setting in Gimp that I missed? Or a compile-time switch in babl, gegl, or Gimp?

Nothing so easy - it would require that more of GIMP be written to be multi-threaded at the C level. Gegl has experimental multithreading support, though, and I think it's a configure option. Try configure --help. Last I checked (over a year ago) it had problems, maybe it's good now?

On freezing other applications...

There are places where GIMP seems to do a screen/pointer grab, and there's a way to compile to disable those I think, which would probably help other applications to "unfreeze". Example: between clicking with "select by colour" tool and the time that the marching ants are drawn can easily be over a minute for me, and the system is unuseable for much of that time.

Speaking of that, slowing down the marching ants (in edit/prefs) can help a LOT on large images, at least in 2.6 and earlier, I didn't try in 2.9

Partha's optimized Windows build has inspired me to do a test Gentoo install on a laptop, with the hopes of learning enough about Gentoo and optimization to be able to install a properly optimized Gentoo on my main computer. It will be interesting to see if Gimp runs any faster on a fully optimized Linux distribution.

Compared to a 486-based distribution like older Debian systems, yes.

Compared to a more modern Pentium-based distribution, or on a 64-bit system, probably much less so. At one point some people compared gentoo and Mandriva linux systems, and found very small differences overall, the biggest of which was down to the way the prelinker was run, so Mandriva changed that to be more like Gentoo.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Nicolas Robidoux
2013-03-23 15:39:50 UTC (over 1 year ago)

Ways to improve Gimp 2.9 performance

Chiming in:

Multi-core requires "love" to work well. ImageMagick, for example, has been known to run considerably faster on busy systems with openMP disabled.

In GIMP 2.6, frequent "marching ants" were a CPU sink. (Bad "observer effect".)

Clayton Walker
2013-03-23 19:17:17 UTC (over 1 year ago)

Ways to improve Gimp 2.9 performance

All you have to do is set marching ants speed to 10 and watch it ramp up the CPU.
Perhaps setting marching ants speed to 0 should simply disable the updates altogether? Generate the ants at one time, and don't bother updating them again...

On Sat, Mar 23, 2013 at 9:39 AM, Nicolas Robidoux < nicolas.robidoux@gmail.com> wrote:

Chiming in:

Multi-core requires "love" to work well. ImageMagick, for example, has been known to run considerably faster on busy systems with openMP disabled.

In GIMP 2.6, frequent "marching ants" were a CPU sink. (Bad "observer effect".)

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Please note that this signature is licensed under the General Public
License. By embedding the signature, or parts of it, into your brain other
than by mere aggregation, your brain becomes a combined, and therefore
derived, work and thus must be licensed under the GPL too.
Elle Stone
2013-03-23 19:42:04 UTC (over 1 year ago)

Ways to improve Gimp 2.9 performance

Those marching ants do chew up CPU power at the default speed. I have them set at 1000, which means one update per second. Setting them to 1000, 5000, or 9999 doesn't make any perceptible difference in the total CPU usage. Just now I tried setting the default speed to "0", but it reset to 10.

http://ninedegreesbelow.com - articles on open source digital photography