Any reason why OpenMP couldn't be use? Adding it to C++ code is as simple as adding few OpenMP Directives (no need to rewrite whole code creating client-server, emulators, etc...) and each for loop with independent elements could be divided to processor cores with almost zero effort.
I *Highly* doubt it would be as easy as you are making it out to be, however, it would be a good method to investigate to see if there are any plausible areas where it could be used in DF without major code re-writes. (since things only need to be synchronized at the frame barrier, there could be large area's that could be parallelised.. Maybe not though.) But yes, alot better than a ground up re-write to handle client/server interface (which I didn't quite get, it may be good but I just couldn't see how it would help that much besides decoupling the interface.. Doesn't mean it wouldn't help though I just don't get how.)
The nature of Temprature is that it doesn't need to update changes very fast, with the except of stuff moving like water, magma and stone. Changes in temprature can happen at 1/16 the rate (and 16x the power?) rate of water is now and nobody will every notice. Then bear in mind that temprature doesn't require pathfinding like water does.
Exactly how will you make 100 threads of moving fluid?? Threads are not cheap to create or destroy, nor can you run more threads than the number of processors available.
Far better to make 1-5 threads and allow those threads to handle seperate bodies of water, or individually numbered tile.
I suppose that might actually work, but there is some syncronization overhead necessary.
Depending on the implementation, It might or might not be faster with just 2 processors, and would require some really impressive threading magic.
"Every pathfinding job could each have its own thread..."
The pathfinding jobs only cause lag when they start colliding with each other. Only one creature can stand up on a tile at a time! The problem is how DF handles these conditions. All paths that conflict are dumped into memory. This will invariably occur with two paths at a time, and can cause syncronization-issues. issues that are very problematic no matter how you attack them, short of revamping the whole movement system.
I know multi-threading is possible, I just don't want Tarn to destroy DF to make it support multithreading. Just because other people built the engine with multithreading from the bottom up doesn't mean it takes Tarn a mere four months to write in Multithreading.
I was using the specific example of having a massive number of processors available, such as stream processing units in a video card, or for future proofing the code for the days when we have computers with 48 main cores and 16,000 math cores...
( I figure it is only a matter of time before AMD or INTEL introduce limited math cores to compete with the CUDA's and FUSION's of the world, Honestly I am really surprised they haven't already...)
As for the movement... Well.. maybe that is the problem, but I am sure even badly designed code done by 4x the processors is faster than badly designed movement code done by 1. But yeah maybe it would be better to fix it up somehow... I don't know.
As for speedups.. Dwarf fort NEEDS some desperately.. I cannot say with 100% certainty that many threads are the best way to go.. They are just the only obvious way.
But.. after working on an open tibia server I do know that making it multi-threaded did speed it up somewhat by using a greater number of cores... however what really made the difference in the end and caused processor usage to be tolerable even when you had 400 people on was code cleanup...
Not that the code cleanup was easy.. it took 40+ (not working full time but still) people nearly 3 years to find all the bugs that were causing issues and clean it up... the multithreading was way faster in the end. They did that in a couple days, and it only took a few weeks to make it semi stable... Not that it was stable before so... More like getting it back to the original stability.. (now it is much more stable but they have been working on it for years)
Apache and Mysql... As far as I know they have just always been threaded and threaded well... I see apache has hundreds of threads sometimes, and it does not seem to be slowing things down.