lag investigation thread

[badosu]

Ok, so I got some answers (thanks ivand), BAR indeed does this in C with Lua/Scripted hooks that can be overloaded for customization. It's also single threaded.

If my assumption that ranges query is JS then I'm pretty sure it's where the bottleneck is in 0ad. BAR architecture seems better.

If 0ad is not scripted in the fundamental ranges queries then I assume its badly optimized.

Edited January 13, 2022 by badosu

[Stan`]

1 minute ago, badosu said:

If my assumption that ranges query is JS then I'm pretty sure it's where the bottleneck is in 0ad. BAR architecture seems better.

If 0ad is not scripted in the fundamental ranges queries then I assume its badly optimized.

Range queries are done in C++ through the CCmpRangeManager class. That class component is attached to what we call the SYSTEM_ENTITY.

Those calls can be made from JavaScript and C++ by creating a range query.

The issue is when 1 000 units start a range query at the same time. As far as I know the processing is sequential.

From my recent testing of wraitii's patch to unthread the ai though not having to copy the whole simulation over to the AI makes a huge improvement on performance.

https://code.wildfiregames.com/D3769

[badosu]

Weird, range queries afaik are not a bottleneck in BAR and still single threaded. As ivand said the code is convoluted but you can check this entrypoint for some insight: https://github.com/beyond-all-reason/spring/blob/BAR105/rts/Game/GameHelper.cpp#L635

[badosu]

Moreover, BAR also does physics simulations for range queries and projectiles so it's definitely something that can be very optimized in 0ad even single threaded, the problem is if the architecture on 0ad is a blocker.

[badosu]

Some insight from TarnishedKnight on BAR:
 

Quote

One factor I suspect is that 0ad must use Fixed Point math whereas we can use floats and SSE. Another is that 0ad must use OpenGL 2.1, whereas we have batch loading of assets in GL4 - the graphics improvements have made a HUGE impact on performance. Prior to those changes, my stress test had an average rendering pass time of 80ms, afterwards I think it dropped to below 20ms. That has a significant impact on Sim.

 

[vladislavbelov]

38 minutes ago, badosu said:

the graphics improvements have made a HUGE impact on performance

No promises, but I'm working on that

 

[badosu]

Another bit from TarnishedKnight:

Quote

I haven't seen 0ad's code, but one trick used a lot in the Spring engine to keep a decent performance is what we call SlowUpdate. So anything that doesn't absolutely have to be done every sim tick can be put in a SlowUpdate. SlowUpdate runs updates over half a second (in our case 15 frames) so each frame 1/15th of the units get their SlowUpdate run, then the next frame the next 1/15th of units get their SlowUpdate run as so on.

 

[Freagarach]

7 hours ago, badosu said:

Another bit from TarnishedKnight:

 

That is how we update the AI.

And for units that sounds somewhat like our timer system. We don't need to check for enemies every turn when attack-moving, so we do it every second.

[wraitii]

13 hours ago, badosu said:

Moreover, BAR also does physics simulations for range queries and projectiles so it's definitely something that can be very optimized in 0ad even single threaded, the problem is if the architecture on 0ad is a blocker.

In fact, doing physics simulation most likely makes them much more efficient than us.

In 0 A.D., arrows are actually purely graphical, the "hit" itself is a timer (this, by the way, has a number of odd consequences, e.g. #5965 or #5964). The consequence is that on timer hit, we must query units around us and check collisions in JS manually (sorta). if there are 100 arrows, this will do 100 range queries.

In a physics-system approach, the arrows would move each "physics update" through the world, a very local phenomenon that can be highly optimised. Detecting a hit is a fast operation by itself, and there is no need to do range queries. Thus arrows are not _specifically_ slow, just part of the whole physics engine.

0 A.D. does not have a physics engine at all, and it probably wouldn't work that well for us because of our 200ms turns. I suspect BAR uses a much more fine-grained "physics turn" of e.g. 10 or 20ms (edit: based on 500ms being 15 turns, 33ms) , so their physics-related lag is less 'spikey'.

--

We could update 0 A.D. to have more turns and do fewer things on each turn, which would end up making it more possible to use a physics engine (though there are floating point / determinism concern), but that's a lot of work given where we come from.

---

That being said, this doesn't prevent us from changing how projectiles work -> it's probably a semi-good idea to consider moving stuff to C++ and making them behave more realistically, given that the current code ends up being slow-ish anyways.