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.

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

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

-----

Make sure to wear safety goggles and a flak jacket.

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

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

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.

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

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.

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

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

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

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

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

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".)

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.