Thanks for the update! I see now why the CPU is showing about 5%: I hadn't done the simple arithmetic for number of cores correctly. Wilbur has parts of the precipiton operation running on a single thread, which is what you see with the 100% usage on one core and about 5% (a bit less than 1/16 total usage) overall. The high GPU usage was the concerning part for me, but I expect that it's spillover from a poor choice in UI update constant that is causing Wilbur to spend a lot of useless time checking if the user has pressed a key to cancel, and which gives the OS a chance to do some things that aren't helpful.
When I do a new build, I'll see if I can get that code to be a little nicer on useless work. Total CPU usage is a little harder to optimize for in this case, though, because the system basically walks all over the surface. Statistically, multithreading it wouldn't be likely to affect final results (two threads would have to be processing exactly the same pixel on the surface at the same time), but this particular case might be particularly bad because the flowlines tend to converge along major pathways and the individual threads would be racing each other to excavate the terrain. There's a chance that a simple version of multithreading might go slower than it already is (unlikely, but possible). Maybe I'll stick in a checkbox to let the user make decision about something that they can't predict the outcome of!