Multicore support failing?

[l00s3s]

Hi
today I played spring the first time on a very large Battlefield with more than 3 AIs (just wanted to try out how much the Engine can take)

I opened a Singleplayer Game on Koom Valley v2 with BA 7.68.
I made 2 Teams 1 completely AI Team with 3 AAIs and 1 E323AI.
The other team included me, 2 AAIs and 1 E323AI.

After 2h playtime I realized that my prozessor load shown ingame was at ~60%. But if I looked in win task manager it was at ~15%. I also noticed that only 1 core was "active". (had definitely more load than the remaining 7 cores)

I think I should mention here that I played with a max-unit-limitation of 500 units and I think I reached that limit.

So my question is did multicore support of spring engine fail? Or did I reach the limits of spring engine? And is there anything I can do that spring uses more of my systems power?

[gajop]

well, there's spring-multithreaded, but it's never used in multiplayer games as it causes desyncs
you can always try and use that, and report errors with proper/desynced replays with infologs, and hope someone finds and fixes bugs

[l00s3s]

So if i got that right the original spring engine isn't multithreaded at all?

Well thats sad but me and my friends don't reach the limits on Lan Partys I reached in the above described game.

So I'm going to test out the multithreaded version for my single player battles

Thanks for the tipp :)

EDIT: The download of the multithreaded version has been deleted. Anyone here who got that version and could upload it for me?

[BaNa]

There is a multithreaded exe you can download and that can usually be used in multiplayer as well but it might be broken in current release (spams desync message but there is no problem).

[klapmongool]

well, there's spring-multithreaded, but it's never used in multiplayer games as it causes desyncs

I actually use MT all the time, in BA, Tech Anni and Robot Defense. Works fine for me, now. Also i'm not the only one.

[gajop]

So if i got that right the original spring engine isn't multithreaded at all?
EDIT: The download of the multithreaded version has been deleted. Anyone here who got that version and could upload it for me?

Well, spring does some simple multi-threading of large loops or something, regardless if it's the 'regular' spring or spring-multithreaded (I haven't checked that myself, but I read it in a post by a spring dev so it's probably true)

Regarding the acquisition of the spring-multithreaded - I'm a bit confused, I thought it's supplied with the original spring, it's just a different executable (there's also a spring-headless which doesn't render anything and is useful for servers or testing).

[100Gbps]

well, there's spring-multithreaded, but it's never used in multiplayer games as it causes desyncs

I actually use MT all the time, in BA, Tech Anni and Robot Defense. Works fine for me, now. Also i'm not the only one.

+1

[hoijui]

yes, spring-multithreaded should come with a default install of spring, that is why there is no separate download.
and as said already, it is only usable for some games, like BA, Tech BA, Chicken BA, ... not for ZK, and.. most other games (that use lots of Lua).
spring-multithreaded only separates parts of rendering into a separate thread... as in.. small parts that prepare stuf for the GPU. the main (only) benefit of it, is more FPS, while your simulation might still lack behind just as easily (or nearly as easily). so... spring might be/seem mroe responsive, but it will not be able to handle bigger games (bigger maps, more units, more players, ...).
OMP is used by spring and by spring-multithreaded, which is what was mentioned earlier... multithreading of bug for/while loops.
realisticly optimistic, you might get a 1% performance increase from that.

the best thing you could do, is implementing propper multithreading of the simulation in spring.
though, this requires very good skills in C++ and multi-threaded programming; it requires 2 years of time, and a very good understanding of how spring works, and of its codebase. it requires a huge frustration resistance, cause of the code-base, nad cause you first had to find a way how to implement it, and a consensus among spring devs, that this (or an other) way is good. you need trust from the spring devs. you need like.. 10 years of exp. in C++ and 5 in MT programming. and if you ever get to finnish it, you need 1+ years of bug hunting.
compared to this, working on the pathfinder is like going on vacation.

[zerver]

+1

[Floris]

To sum up simplified: MT is like the pathfinder for code, instead of units.


Hail zerver, you can go on vacation anyway!

[danil_kalina]

...the main (only) benefit of it, is more FPS... Spring might be/seem mroe responsive...

Players want this

[zerver]

The pathfinder itself could be threaded fairly easily though, only difference would be an asynchronous calling mechanism. This is good news, if someone makes a kickass pathfinder that unfortunately happens to eat much CPU.

WRT threading the Sim, it is good to have something that is overly challenging sometimes, the Spring equivalent of the P = NP challenge.

[hoijui]

@danil
it means, you have high FPS, but you might see 2+s delay when giving orders to your units.

with current MT (engine internally called GML), you will get a (visual only) improvement if you have more then one core, though it does not matter whether you have 2, 4 ,8 or 1024 cores.
if we had a very well made/highly parallel simulation, and you would have 32 cores (realistic at the end, when you consider someone starting to code MT sim now), it means you could have a perfromance increase of maybe 2000% (relative ot the number of cores). which means oyu could have 20 times as many units on hte field, before it starts lagging, or 4 times as many, with a bigger map and a more complex pathfinder.

[Forboding Angel]

Anyone with a decent GPU isn't playing BA anyways, so basically mt is a way for people with integrated cards to play large games of BA with 10 fps instead of 2.

[danil_kalina]

@danil
it means, you have high FPS, but you might see 2+s delay when giving orders to your units.

Yes, not good also! But better than you see slideshow on the screen.
it can be compared with the desktop application which does something heavy and your UI is not responsive. for example, when we select the battle in the battle list at the first time. we need to take picture of map in battle using unitsync library.

I tried to compare Spring and Spring MT in the beginning of 2011. The difference is huge!
When I join any already started battle. Speed set 20.0. Spring MT was so responsive. I can overtake the running battle in seconds. Notebook was warm not hot. The difference was obvious.

if we had a very well made/highly parallel simulation, and you would have 32 cores (realistic at the end, when you consider someone starting to code MT sim now), it means you could have a perfromance increase of maybe 2000% (relative ot the number of cores). which means oyu could have 20 times as many units on hte field, before it starts lagging, or 4 times as many, with a bigger map and a more complex pathfinder.

I don't know what you are developing for the next version of Spring, but parallel computing must be the priority now.

[danil_kalina]

Sorry, priority depends on game users play. For my view, the less number of units are using in Zero-K.

[zerver]

Anyone with a decent GPU isn't playing BA anyways, so basically mt is a way for people with integrated cards to play large games of BA with 10 fps instead of 2.

That's a rather dark way of looking at it. 89.0 is your opportunity to make EVO MT compatible.

I have a decent card and good CPU and MT is so much more responsive towards the end of big games.

[Forboding Angel]

I don't doubt it, but chucking all luaz is answering a problem with another problem and providing a solution to neither.

& dark/cynical yes, but more likely than you think.

There are of course some exceptions. Kaiser has a nice rig, so does jaz, but as a general rule, if someone is playing BA, their computer most likely sucks.

[PicassoCT]

The pathfinder itself could be threaded fairly easily though, only difference would be an asynchronous calling mechanism. This is good news, if someone makes a kickass pathfinder that unfortunately happens to eat much CPU.

WRT threading the Sim, it is good to have something that is overly challenging sometimes, the Spring equivalent of the P = NP challenge.

This would be really nice. Especially for those of us who repath alot during the game by maptransform.