Bad perfs > *makes a little test* > the culprit is the CPU !

[serveurix]

Usually, on simple, small two-players maps (like the Acropolises), 0AD is quite fluid at the beginning, and at a certain time, begins to struggle when the number of units increases. On those maps however, the game is playable till the end. But on some maps it's not the case.

I've identified two cases in which 0AD is really slow on my computer (Lubuntu 12.04 with mesa libs from oibaf's PPA, AMD Athlon II X3 445 CPU, 4GB RAM and AMD 880G aka Radeon HD 4250 aka RS880 GPU (IGP) ) :

- Maps with a lot of water (like the Azure Coasts). The game struggles more and more as more water can be seen by the player.

- Big maps. The game is not particularly slow at the beginning, but slows down faster than usual (despite only a small part of the map is revealed). This happens in Arcadia (the size of the map is "default", but it seems bigger than the others). Strangely I get the same effect in Death Canyon, which is not a big map, AFAICT.

The maps with a lot of players slow down fast too, but I've not tested them enough to be able to say if it's not the quickly increasing number of units that's at the origin of the struggle.

Anyway, on all maps I've played, the game significantly slows down when the population number reaches a certain level (around 120 - 130 units). I've not tried to get a more precise number because I have not verified if it's really the number of my units (in fact : the units I can see) which is problematic, or the total number of units on the map (including the nemy units I don't see). Maybe I get always a similar result because the AI and me are creating units at the same rate ?...

I've put a Radeon HD 6450 in my computer and I was suprised not to get a significant increase of performance (except at the beginning of a match, the game is perfectly fluid, but then I get the same struggle, at the same moments. I was also concerned by the case of the Arcadia and Death Canyon maps, so I've decided to run 0AD in windowed mode, while watching the graphs of gnome-system-monitor and radeontop.

I don't know those things well enough to understand what each line of radeontop means, but this is what happened :

- When starting a match, the CPU 3 usage increases to 90%, and slowly increases until it fluctuates around 99% after several minutes of game. The bars of radeontop oscillate irregularly between 30 and 90%, depending on what I'm doing/displaying. At a moment I create 30 citizens at the same time, the population increases to 149 units, and I see the CPU 3 usage sticking to the 100% line (no more fluctuation). The bars of radeontop keep oscillating as before.

I open the settings window and uncheck all the boxes. Strangely, when I open this window the CPU activity goes down to 70% and the GPU activity increases to 80-90%. I go back to the game. CPU load goes back to his 100%, GPU load goes back to his irregular oscillation.

Verdict :

The limiting factor here seems to be the CPU. My knowledge in the domain is very poor, and my method is not rigorous at all, but this is what comes up to my mind after this test. This is a bit disappointing, as the Athlon II X3 445 admittedly is not a racing machine, but is not a particularly bad CPU either.

Conclusion : If 0AD is slow on your machine, don't blame the GPU too fast. And if you choose to buy a CPU with the idea of making 0AD Alpha XI "Kronos" run on it, prefer a CPU with powerful core rather than a high number of cores, as 0AD will exploit only one of them.

(PS : Has a "performance and config feedback" thread been started yet ? It would be useful to know what the best configurations to run 0AD on the different OSes/kernels/drivers are.)

[k776]

serveurix, you are correct. CPU is the bottleneck, but it's not the CPUs fault. There are many parts of the app that aren't as effecient as they could be.

In particular, the AI and the Pathfinding. Work is being done in both areas to make them faster.

Eventually too we'll split things like AI and PAth finding into threads, so CPU's with multiple cores can split the processing.

But that's still a few releases away.

[zoot]

It's a bit strange that this issue keeps coming up. As mentioned in the "known issues" thread (and by k766 above), the reasons for the poor performance are well-understood. There are profiling features built into the engine that allow developers to measure exactly how much processor time is spent in each component of the game.

In other words: do not blame your CPU Don't blame your GPU either as the slowness is not a hardware issue at all. Rather, it is an artifact of using alpha quality software not intended for general consumption.

Edited September 29, 2012 by zoot

[serveurix]

Eventually too we'll split things like AI and PAth finding into threads, so CPU's with multiple cores can split the processing.

That's good news because the Known Problems post says the opposite

0 A.D. was designed when multiple cores were not yet common, and it would take too much work to program the game to get it to use multi-core processors efficiently. Still, it can be good to have multiple cores, because they may be available to other programs running while you play 0 A.D.

I've always thought it was a shame that 0AD wasn't able to take advantage of multiple cores (I was ready to ask for a Haiku OS version ^^ ). But if you can split some processes into threads, that's good.

But that's still a few releases away.

How many exactly (or approximately, if you don't have planned for a precise release yet) ?

What can we expect in terms of performance improvements in the next Alpha XII release ?

Edited September 29, 2012 by serveurix

[quantumstate]

How many exactly (or approximately, if you don't have planned for a precise release yet) ?

What can we expect in terms of performance improvements in the next Alpha XII release ?

We don't have any fixed plans yet. It is very hard to give any estimate at all.

[fabio]

Maybe the default maps should just include fast maps (small and only one AI), the others could be put under a "Slow" group.