Add Mutihtreading
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
widelands |
Won't Fix
|
Wishlist
|
Unassigned |
Bug Description
As of RC19 Widelands uses a single Processor only. When you check top or other tools, Widelands is at about 100% for one core and alle the other cores are idle. As all moder CPUs (even a Raspi) have mutiple cores Widelands should support this. This could be done as follows.
* Fork off a "Rendering" Thread, cares for rendering only.
* Fork off one or multiple "AI threads"
* Fork off a "Sound" Thread.
* Fork off an "Autosave" Thread, this blocks the game flow a lot on big maps.
* Avoid a significate increase in memory usage.
The Wideland structures are _not_ Thread safe as of now and making them all
completly thread safe is a big task. To allow a simple transition there are
multiple ways migrate to a final solution:
a) Use a single "Update" Thread - and allow only this thread any modifications
* As Widelands already uses a kind of command queue this should be feasible.
* All read access must be blocked during the (atomic) writes.
b) Copy all need structures for some of the Thread.
* as the main Map is a huge structure this may increas the memory footprint and contradict the requirement above
c) Redesign major games structures for Mutithreading
* Well, this is a huge task of its own
As I am not that familiar with some of the Internas here,
I ask our "Architects team" ;-) for comments.
Changed in widelands: | |
importance: | Undecided → Wishlist |
Changed in widelands: | |
milestone: | build20-rc1 → build21-rc1 |
Widelands predates multicore architecture, therefore it was never designed with the idea of multithreading. I think it is very hard to design it into the core of the game, since we so strongly ingrain doing one thing at a time.
I also would suggest to not change this - never. The logic of Widelands is simple and a single core can handle a big game quite easily. There are obvious bottlenecks in the routing which could probably use a parallel approach locally - for example routing - but in general, I would always keep the core single threaded.
I think making AIs multithreaded is the obvious first step in distributing load and should be quite simple:
1) Introduce an API that let's AI observe the game and enqueue updates (through Player messages, i.e. the same way a network player needs to do it).
2) All updates happen at once at the end of a frame (same as for multiplayer right now).
3) Spin up a separate thread for each AI player.
I think this is closest to your a) suggestion, but more limited. It reduces the engine to a sort of server that processes time ordered player commands and guarantees immutability for a certain amount of time so that the view of each player is correct.