GIMP Not Using Available Resources

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