Anyway, making DF multithreading at the end... won't work (very well) multithreading has to be in the core design
After writing code in a multi-threading environment for a long time I can generally say your statement is not true. What's true is that you should know what you are doing and what you are trying to achieve . Without going into details you can generally convert any for loop that process independent data into a work queue scheduler .
Sure, but that's sorta the point.
If the code is written already in such a way that it has lots of independent tasks, and modifications to shared data are rare and well-controlled, then sure. Refactor, and you've got a multithreaded program. But in a large, complex code base like Dwarf Fortress that wasn't designed with threading in mind, how likely is it that everything is already independent?
No processing steps are modifying data structures in place as they're traversed, for instance? The hard part, I imagine, of reworking DF for multithreading wouldn't be converting for loops to work queues; the problem would be finding every little niggling synchronization point and either acquiring a lock (which could erase performance gains if contested locks are common, and would introduce extra randomness (dunno if that matters)) or delaying and batching the writes somehow (which could be a lot of work in itself).
In short, I tend to agree with the suspicion that the low-hanging fruit has got to be in the pathfinding algorithms, and getting those right could improve performance just as much, if not more, as multithreading, and with way less work and way fewer irreproducible crasher bugs …
)
)