1
DF Suggestions / Re: DF Eternal Suggestion Voting
« on: December 10, 2012, 10:12:34 pm »seeing multithreading as 11th in the voting list made me wish more people knew what it is.
MULTICORE SUPPORT MAN. YAYUS.
I think the reason it doesn't get more votes is because it would require a massive overhaul of the game to put in, and during that time Toady couldn't really do anything else. So the overall development would stall for a very long time without anything new being added. Sure, performance would improve, but that's about it.
Personally, I'd rather have more features and less bugs than better performance, and I'm sure a lot of other people feel the same way.
Same.
Also, some technical stuff: Concurrency is difficult and bug-prone, it would require different code for each supported OS, and even modern games still only run two or three threads: Device I/O (network, hard drive, whatever), Game Logic, and Graphics. Offloading the entire game logic to a different thread would be negligibly helpful in this case, and even if the game logic were spread out into multiple threads (like one for pathing, one for fluid simulation, and one for everything else for instance) all the game logic threads would still have to wait on the slow one to finish before updating the state of the game. tl;dr: Even if pathfinding and fluid simulation were offloaded, the rest of the game would still have to wait for it to before finish a "tick" of the game could happen. It would be of minimal benefit for colossal effort.
I think the idea is more that a problem is split up in subproblems that are then calculated in different threads. Pathing is a good example. Each path could be forked into an own thread, which would greatly increase the speed of producing a pathing result for the next game tick. But you are right, it is not easy to do, and if pathing isn't the bottleneck, it will actually hurt more than help, because the thread-switching of course means an additional overhead.
The game should be profiled to identify the problematic code locations, then these should be improved. Toady is probably a very good programmer, but I'm quite sure that there is still potential for performance improvements. Maybe, for some of the code, multi-threading will be the solution. Maybe not.