GIMP Not Using Available Resources

[Gidde]

So, I finished my rebuild, have lots of shiny new processor power and 6 GB of ram ... and GIMP won't use it. It chugs like the dickens while my resource monitor says I'm only using about 50% of my ram and 25% of my processor power.

Do any of the gimp experts around here know if/how I can tell it to hog all the resources it wants? I checked the preferences and it is set to use all 4 processors; none of the other settings look relevant.

The good news is that at least I can use my tablet now.

[waldronate]

It sounds like you have a Core i7-9xx machine (quad core, triple memory channels) running a 32-bit OS (maximum addressable memory of around 3 GB after space is taken out for hardware). To get the system to use all of your resources you'll need a 64 bit OS and a 64-bit build of GIMP. 25% would be using one of your cores, which means that it's quite possibly not a multi-threaded build for the operations you're using.
All speculation on my part, of course.

[Gidde]

All completely valid -- I'm using a quad-core processor (not sure about the memory channels) -- but I'm running 64-bit vista and I installed the x64 version of gimp. However, I'm thinking that something is going on akin to what you're describing, because last night I was running gimp and doing a bunch of other stuff, and using the same ratio of resources (and everything was alot slower). It's my first multi-core processor and I'm new to vista from 32-bit xp, so maybe I have something set wrong >.<

[RobA]

Since you have already found the preferences page, check (and increase) your cache settings. The defaults are quite conservative.

-Rob A>

[Gidde]

I increased the Tile Cache to 3GB from 1GB and see the exact same usage profile Unfortunately, gimp has a hard limit at 3, so I can't test further.

I also got a gadget that watches all 4 cores and the RAM, and it is using all 4, though one seems to be maxing while the others aren't working nearly as hard (~ 90%,15%, 20%, 40% .... it fluctuates pretty wildly but that's probably a good average). I did see the total use of the processor peak at 48%, and RAM actually hit 53%.

I looked around for a vista-choking-resources solution, and basically found a whole lot of repetitive "it's only using that much because it only NEEDS to use that much" ... which I think is crap when it takes 15 minutes to finish a shaped gradient (while using less than half of the available juice). It doesn't seem to be fixable though, so I guess I'm just going to shrink the map.

How sad.

[waldronate]

I looked around for a vista-choking-resources solution, and basically found a whole lot of repetitive "it's only using that much because it only NEEDS to use that much" ... which I think is crap when it takes 15 minutes to finish a shaped gradient (while using less than half of the available juice). It doesn't seem to be fixable though, so I guess I'm just going to shrink the map.

The algorithm developers have to specifically enable multiple threads in their algorithm to make it multi-threaded. This sort of change can have unintended consequences. Eventually this type of multithreaded development may not be as tough as it is today, but for now it take a bit of effort to correctly use all of the computational resources on a multi-core system. If one core is 100% and the others are sort of idling along it's a classic example of a single-threaded algorithm at work.

One example of how a trivial multi-threading change can be difficult showed up on my work in Wilbur. When it was doing lots of processing, it would show a little window and update that window as it went along. Turns out that there were two problems with that: the window creation/update/destroy was taking a whole lot of processing power on its own and the UI interaction made it impossible to multi-thread that section of code in the same way as I had been doing it. When I added an OpenMP directive to enable multi-threading on code that was taking a long time (a simple task) the results were incorrect (the unintended consequences). The multi-threading didn't play well with the UI updates. So for now there are chunks of Wilbur that just appear to freeze the machine at 100% CPU usage because I multithreaded the computation and gave up on the UI updates. (Note that I indeed know how to do the UI updates in a proper multi-threaded manner but I just haven't taken the time to do the implementation yet).

[Notsonoble]

I'm running XP 64, on a dual core with 4 Gigs, I've seen GIMP get to 60% (100 on 0 and 10 on 1) and in the 2.5 gig ram usage range... but pretty much only when using the Layer effects python scripts...

GIMP does seem rather unwilling to dig deep if the image is large... also, have you tried setting the priority of the process... I've only noticed a difference on XP64 when setting it to "Realtime" but it did smooth out some then...

[Gidde]

@NotSoNoble: I'm going to try that, thanks!

@Waldronate: Thanks for the insight, I hadn't really thought of it from that angle (although I suppose I should have, after my multithreading experiences in java). I guess I had assumed that since gimp offered multicore support, it would be all smooth on gimp's end. I watched the usage pretty closely last night (filters still take a while even on the shrunken map) and I noticed an interesting usage pattern: one core would fill up, then it would spread the load evenly, then 3 would start going down as one filled back up again.

From what you were saying I'm thinking that gimp is maxing the one processor and vista is reacting to that and spreading the load out, but gimp's still using only one thread. Does that sound likely?

[waldronate]

The Windows NT scheduler (XP, Vista) is known for somewhat pathological behavior with regards to multiple threads. What it should do is try very hard to keep a task running on the same core as much as it reasonably can because switching cores involves some serious cache thrashing as it fills the caches on the new core. But the scheduler will often just round-robin a single task though all available cores, leading to sometimes significantly reduced performance. If the total usage on a quad-core CPU stays pegged at around 25% (one core full operation) but individual cores keep changing their amount of work in flight then it's more likely to be the result of the unpleasant scheduler behavior than it is anything to do with the running program. Windows 7 is supposed to be much better in this regard than the earlier versions.
Sometimes you can get a performance boost for single-threaded programs just by changing the task affinity to a single core. The Turbo boost on the Intel Core i5/i7 runs the clock speed higher with fewer cores running so the affinity trick can potentially get much larger gains on those processors than would be expected from a simple reduction in cache thrashing.