Only using one CPU on a Quad Core

[ubernissen]

Noticed that out of the 8 cpu's listed in System Monitor, 0 A.D. only uses 1 and ~800 MB memory.

With a total of ~450 units and ~200 structures the game starts pausing 1-2 seconds increasingly.

Details:

0 A.D. version: 0ad 0~r11863-1~ubuntu12.04.1 / compiled svn revision 12663

OS: Ubuntu 12.04 x86_64

CPU: Intel® Core™ i7-3612QM CPU @ 2.10GHz × 8

Memory: 4GB PC3-12800

Graphics: NVIDIA GeForce GT 630M - 2 GB / Intel HD Graphics 4000

Bumblebee: 3.0.1-3~preciseppa1

Swap: 8GB SSD, swappiness 10

Tried different setups, with default Intel GPU or bumblebee-nvidia with setup changes, changed swappiness and now I'm all out of ideas.

Besides the "out of memory" bug already filed, I haven't found anything helpful, so I'm open for suggestions

[feneur]

0 A.D. was first created when multi-core processors were not common, so it only uses one CPU, and unfortunately it's hard to change that at this time.

[ubernissen]

That's a simple explanation. Thanks

The pausing is annoying and I hoped the cpu "issue" would explain it.

[luziferius]

it needs a major redesign.

the single-threaded attempt works somewhere like this:

you have a main-loop (that runs until some sort of exit-message arrives). that mainloop checks the different components in a deterministic way (it starts an action and wait for its end to evaluate the result)

like this: process the input buffer(mouse/keyboard events), then update the UI, change variables in the simulation component,find paths, do a simulation step,do an AI step, trigger a re-render on the gpu according to the changes in the simulation, check the sound component for pending sounds, do other things (whatever^^)

to get a multi-threaded application, you have to use a different attempt:

you have a main-thead that starts many other threads and lets them run until some sort of exit-message arrives

it runs like this: the input watcher wakes up and sends messages each time input events arrive, the UI thread evaluates those and sends messages to other threads(sound, graphics, sim update), those do their things and send messages arround… until the whole thing exits

some things can’t be parallelized easily(like sim update and pathfinding; you can’t calculate paths when the obstruction map is dynamically changed through the sim update all the time, etc)

and all the time you have one big and non-trivial problem: being thread-safe; you can’t modify data that is used by another thread.

doing that produces garbage almost instantly that will crash the application or does other unwanted and unpredictable things

==========

some parts of the game can be more easily put in a separate thread, like the sound (thats already WIP) and maybe the UI/input stuff and AI (idk)

Edited September 15, 2012 by luziferius

[historic_bruno]

That's a good summary luziferius, and don't forget issues like deadlock which start to occur with multiple threads. The simulation will probably remain single threaded to avoid changing the architecture (again!), while things that influence the simulation state and are more naturally parallel may become threaded. Examples: pathfinding (one long path calculation isn't affected by another path calculation, so 100 units could conceivably perform 100 long path calculations in parallel - not sure about short paths), AIs (they might share some state but they make independent decisions and the simulation doesn't need to wait for the AI to send commands). UI is a bit trickier because it still has to be drawn to the video buffer which it would share with the renderer in another thread, not that it's impossible to solve that but we'd need a clear reason for it first. Short term it would be great to optimize the game assuming a single thread, unless someone out there can tackle both problems at once