He hasn't got a supercomputer. He's running the game in his mind with ~600 FPS and writing code on his netbook as it comes.
lmfao. Toady's brain is a Cray.
DF is written in C.
Toady has done and is doing what he can to improve performance. Particularly in the path finding optimizations.
But his time has to be split between bug fixes, new features, and speed improvement. Of those three, one is critical but not fun, one is fun but not critical, and the last is neither fun nor critical.
He balances them d@mn fine, considering he's a 1 man band, here.
Yes, multithreading would vastly improve performance, and there is enormous potential for it in DF. Most importantly, the UI needs to be in a separate thread. Sure, putting pathing for water & lava in their own thread would have a huge performance bonus.
Have you ever written multitasking in C? It is bloated and messy, bug-prone, and quite challenging. It is difficult to implement correctly for a project designed from the start to use it, but it is downright hazardous to implement on top of an existing giant codebase. He's not going to do it. It is unreasonable to expect it. Maybe, maybe, the UI will get it's own thread. Maybe.
<technical jargon>
I've never seen the source code, but based on the data structures I've seen in dfhack and StoneSense, there is one area which could improve speed at the cost of ram. Map tiles do not contain their own material information. Instead, they have a lookup index into the global Geology array, which in turn contains vein information and lookup indicies into the global Materials array. Caching the most important property information directly into the tile could have a noticeable performance increase, because every single pointer redirection requires the CPU to perform another fetch across the bus. No CPU cache can be used when you hop around memory like that, and the code within the tight loop will effectively run at your bus speed instead of your full CPU speed (e.g. for most 2ghz processors today, the FSB is typically around 800Mhz). Caching the values in the structure permits the CPU to pull the entire structure into its internal cache in one or two fetches, and Intel processors are impressively intelligent about this. There are probably some other things that could be done to the tile structure to improve pathing speed, while that was done. Since neither the material properties nor the geology data ever change during the course of the game, referential integrity is moot. Additionally, since the values are merely being cached, the save game file format would not be changed.
</technical jargon>
But that would probably take a few weeks to implement, and introduce some quirks. And its no fun to code.
I'll volunteer right now to do it.... but no source code == no work.
It all comes down to the four way split of Toady's time: Fixes, features, optimization, eat/drink/sleep/bathe/read forums.
He already sacrifices eat/drink/sleep/bathe a lot.
So which do you want to trade, Fixes or Features?