Why single thread is en of spring for me

[dansan]

I always get "[Threading] Main thread CPU affinity not set" (on a i5) in the infolog. Doesn't that mean exactly what I wrote, that my sim thread is scheduled "slowly", but "fixed" only inside a certain set of cores?

Then you disabled threadpool (configtag is WorkerThreadCount) and neither used SetCoreAffinity.

I didn't disable or set any of them.

Code: Select all

$ egrep -ic 'thread|affini' .config/spring/springsettings.cfg .springrc
.config/spring/springsettings.cfg:0
.springrc:0

I was assuming, that spring would set appropriate default values on its own.

Code: Select all

rts/System/Platform/Threading.cpp:39:CONFIG(int, WorkerThreadCount).defaultValue(-1).safemodeValue(0).minimumValue(-1).description("Count of worker threads (including mainthread!) used in parallel sections.");
rts/System/SpringApp.cpp:87:CONFIG(unsigned, SetCoreAffinity).defaultValue(0).safemodeValue(1).description("Defines a bitmask indicating which CPU cores the main-thread should use.");
rts/System/SpringApp.cpp:88:CONFIG(unsigned, SetCoreAffinitySim).defaultValue(0).safemodeValue(1).description("Defines a bitmask indicating which CPU cores the sim-thread should use.");

If it is desirable to set those differently than the defaults, please provide user documentation (a forum entry will suffice :).

[Anarchid]

Yes, the problem is that all users are on spring server

A fork is not entitled to its own share of infrastructure access and playerbase. Especially not a gpl-violating one. Usually if it's really better, it develops its own userbase.

Imagine you fork RHEL (and then conceal your sources). Does that mean Red Hat should support your fork with their servers? Should Red Hat take steps to make your closed-source fork easier to obtain?

[dansan]

Please go to another thread to talk about zervers MT code. OP is talking about the -multithreaded code.

[Anarchid]

Back on topic:

2) Why dev and people not playing BA tell spring 95 is faster and NONE of them is posting config file setting and replay to prove it ? Please, prove I am wrong and do so.

A replay is just startscript and series of commands. A replay made on super-performing machine on super-performant settings won't run any faster if run on a machine where spring is slow.

[smoth]

Yes, the problem is that all users are on spring server. So why should they go to another server to be able to play same game with multithread? Just because the devs cannot kiss and make up and work under same name?

fuck it, rage mode on!

Because it is NOT the same fucking game. it is a version zerver converted.

I am going to say this ONE, MORE, FUCKING, TIME.

In order for any project to properly utilize zerver's MT, you have to alter the structure of all gadgets. I don't even want to imagine how it handles all the custom shader stuff behe and I have begun to use.

it isn't just simply take version of game go do it play it in zervers illegal branch. It is take game, convert it go play in zerver's branch. The conversion process would require massive amounts of rewrite work and you will have to update it each release of the mod.

No way in hell should ANYONE HERE be expected to go and do it for each release, nor should we be brow beat by ignorant people like yourself or albator to do it. Just fucking wait a bit for the multithreading work JK is doing. It is better in the long run and it will not force extra work on the people who already give up damn near all their free time to work on a game that NONE OF YOU FUCKS pay us to work on.

[Beherith]

That replay gets slow for me around 2000 units. There are 8 players spamming constantly at each other, with unit count peaking around 2400. That is an insane amount of units and a very impressive feat for the spring engine! Name any other engine that can handle units in that count.

[zer_ver]

you have to alter the structure of all gadgets ... you will have to update it each release of the mod

(Sigh) Wrong! You update all gadgets that access SYNCED.xxx, and you do it only once. After the update, the gadgets are compatible with both multithreaded and singlethreaded engines.

Example: Zero-K 1.1.9.6 MT
http://www.file-upload.net/download-818 ... t.sdz.html

2000 units

Latest MT does 20000 patrolling fighters at 1.0 game speed and 25 fps (i7 2600k w/ ATI 7700).

[smoth]

you have to alter the structure of all gadgets ... you will have to update it each release of the mod

(Sigh) Wrong! You update all gadgets that access SYNCED.xxx, and you do it only once. After the update, the gadgets are compatible with both multithreaded and singlethreaded engines.

Not what you told me a long while ago, I still have to code in a specific way to ensure it is architecturally compatible with your way of handling threads. So even post conversion I will have to test all my code to find out where the gaps may be in the way I wrote something AND test thoroughly in 2 different engines. Unless you have majorly changed your approach, I still cannot have render anything in gadgets correct?

[knorke]

2) Why dev and people not playing BA tell spring 95 is faster and NONE of them is posting config file setting and replay to prove it ? Please, prove I am wrong and do so.

I didnt know who you are in http://replays.springrts.com/replay/2f4 ... e783ff94e/ so I locked camera to [Loet]Brenner instead then logged fps:

It is not really accurate as I could not be bothered to watch the whole game at 1x speed and so did other things on 2nd screen.
The game crashed before end, I guess same bug as http://springrts.com/mantis/view.php?id=4152 (supposedly fixed in > 95)

At 29:00 there seemed to be CPU spike for all players and afterward fps were "unplayable, ~10 fps." Until ~25:00 it was good fps.

Interessting is that at the end the game has 2000 units but the player rarely sees more 50-100 at once.
Unitcount goes up and up and up but the player does not really notice it that much.
The "visible units count" only rarely spikes, when zooming out.
But this zooming out is only for very short periods, most of the game is played with the fewer units visible.
So I think the gamedesign has lots of "overhead":
Why have battles with 2000 units when the players will only really play with ~100? That is the same unitcount as in an 1v1 or other small game.

I dont play much BA (and never these lolsized games) but XTA is imo similiar:
For me performance in 95 seems noticable better.
There was some games where I was surprised I did not lag where I surely would have in 94. Catching up when joining a running game also seems faster.
The unit count in games I play is maybe 1000-1200 max: As can be seem from graph with such numbers the game is smoothly playable. I do not need another 1000 units in the game when I never see them anyway?
Dual Core CPU with some integrated graphic card.
I think that is to date my most technology advanced way of saying that DSD8V8 sucks

[klapmongool]

Interesting is that at the end the game has 2000 units but the player rarely sees more 50-100 at once.
Unitcount goes up and up and up but the player does not really notice it that much.
The "visible units count" only rarely spikes, when zooming out.
But this zooming out is only for very short periods, most of the game is played with the fewer units visible.
So I think the gamedesign has lots of "overhead":
Why have battles with 2000 units when the players will only really play with ~100? That is the same unitcount as in an 1v1 or other small game.

I dont play much BA (and never these lolsized games) but XTA is imo similiar:
For me performance in 95 seems noticable better.
There was some games where I was surprised I did not lag where I surely would have in 94. Catching up when joining a running game also seems faster.
The unit count in games I play is maybe 1000-1200 max: As can be seem from graph with such numbers the game is smoothly playable. I do not need another 1000 units in the game when I never see them anyway?
Dual Core CPU with some integrated graphic card.
I think that is to date my most technology advanced way of saying that DSD8V8 sucks

I don't play DSD8V8 and yet I play games that get so large that the fps drops to unplayable levels. For other players often earlier than for me, so they drop out. But after that has happened my lagging will commence sooner or later (as the unit count increases into the thousands).

These aren't 'lolgames'. These are games with a pretty normal player count (5v5/6v6) on a decently sized map for that number of players (so no horrible overcrowding like 8v8 on DSD).

You say you don´t need more units in game because you don´t see all those units at the same time anyway? So when I'm looking at a fight at one of the fronts it is not relevant that I have a base, static def, eco, expansions, fighters, bombers/sonars heading for the enemy and perhaps some sea-land invasion underway? Not only do I switch a lot between these activities, I also zoom out all the time.

Having all these different tactics packed into the strategy of the game makes the game more fun for me. This requires large numbers of units. So no, 100 is not enough.

I wish people who don't play this kind of games and thus are not affected by the slowdown from 94.1 MT to 95 would stop saying they don't notice anything.

Who here actually plays these games? I would like to see some hands. If you are wondering: If you don't play ZK, BA or TA you are automatically not qualifying.

[smoth]

Knorke what are you using to graph those details?

[Forboding Angel]

5v5 is not a normal player count.

You're doing it wrong.

[Jools]

Who here actually plays these games? I would like to see some hands. If you are wondering: If you don't play ZK, BA or TA you are automatically not qualifying.

I think we are all old TA players. But who plays this still?

[smoth]

I wish people who don't play this kind of games and thus are not affected by the slowdown from 94.1 MT to 95 would stop saying they don't notice anything.

Yes 95 is not yet as fast as MT. MT was optimized for BA.

This isn't the BA engine, it is the spring engine.

I wish players like yourself stopped seeing something that works for only the *A as good for the engine.

I wish you players would realized that these are necessary growing pains to get things done correctly.

I have lots of wishes, but hey it's cool by all means lets break all non *A projects by forcing them to adopt a very specific architecture and FURTHER raise the code complexity. Because you don't realize or appreciate all the work that has to go into working out all the (synced<->unsynced )<->widget shit we have to do already

[Forboding Angel]

Toss out 3do support and listen to the glorious QQ.

[knorke]

These aren't 'lolgames'. These are games with a pretty normal player count (5v5/6v6) on a decently sized map for that number of players (so no horrible overcrowding like 8v8 on DSD).

Did you watch the linked replay? It is 8v8 and what I commented on.
Even if the map is big enough to not be crowded, the gameplay is still fail which makes it a lolgame.
For example the whole interessting early game with raiding does not exist when units take so long to get to the enemy. Also cooperation between players is usually too chaotic.

You say you don´t need more units in game because you don´t see all those units at the same time anyway? So when I'm looking at a fight at one of the fronts it is not relevant that I have a base, static def, eco, expansions, fighters, bombers/sonars heading for the enemy and perhaps some sea-land invasion underway? Not only do I switch a lot between these activities, I also zoom out all the time.

The unitcount of a windfarm so far back in safe base that it never gets raided does not contribute to my fun. Neither does an airscreen of 500 fighters have much "gameplay value", I never really give orders to them, they simply follow their patrol loop from factory.
So I prefer games where all units are really useful instead of this spam chaos.

Who here actually plays these games? I would like to see some hands. If you are wondering: If you don't play ZK, BA or TA you are automatically not qualifying.

I play those, just not in 8v8 on large maps.

Maybe post some replays that you consider non-lolgames and where you wanted better fps?
So far there is one example.
And I would like prove that such game was decently playable in any spring version.

[klapmongool]

Did you watch the linked replay? It is 8v8 and what I commented on.
Even if the map is big enough to not be crowded, the gameplay is still fail which makes it a lolgame.
For example the whole interesting early game with raiding does not exist when units take so long to get to the enemy. Also cooperation between players is usually too chaotic.

'These' is referring to what I said earlier in my post: ' ...and yet I play games that get so large that...' I didn't want to throw DSD bashing into this thread as well. These games start out with interesting scout play/good t1 fights/etc and usually have cooperation as well. They just end up big because no one wins before that time.

The unitcount of a windfarm so far back in safe base that it never gets raided does not contribute to my fun. Neither does an airscreen of 500 fighters have much "gameplay value", I never really give orders to them, they simply follow their patrol loop from factory.
So I prefer games where all units are really useful instead of this spam chaos.

Yes. Some units seem more and some seem less used in a game. A single fighter in a 500 fighter air screen is microed less than a krog. Still I like the element in BA where you can make hundreds of the same unit the accomplish your goal. I think this adds to the game. If you don't keep an eye on you opponent he might just attack with 200-500 bombers/raiders/crawling bombs/whatever. This makes it harder to sit behind your defenses and feel safe. But perhaps you have a better solution instead. That would be something for game devs to consider though.

I play those, just not in 8v8 on large maps.

Maybe post some replays that you consider non-lolgames and where you wanted better fps?
So far there is one example.
And I would like prove that such game was decently playable in any spring version.

Which example is that? I did recently post a game that had horrible fps in late game (http://replays.springrts.com/replay/fe4 ... 879b8f899/ in http://springrts.com/phpbb/viewtopic.php?f=11&t=31223. I posted it on the forum because there was something else happening as well. Still the fps would have been higher before and after the 35 min mark in 94.1 MT.

But tbh i don't think that you going through replays I post to judge the quality of the games we mortals play is helpful. If you really want to you are welcome to sort through the games I played on replays.springrts.com. Probably all games that are 4v4-5v5-6v6 that last longer than 40 mins.

@FA: I guess you decide for the rest of us what the right teamsize is then.

@smoth: Yes, I am complaining as a BA player that the engine used to be faster. Thanks for noticing that. I would love to be able to keep playing BA in the future.

@Jools: By TA I mean Tech Anni.

[smoth]

You missed my point

[knorke]

Which example is that?

The one in start post of this thread.

I did recently post a game that had horrible fps in late game (http://replays.springrts.com/replay/fe4 ... 879b8f899/ in http://springrts.com/phpbb/viewtopic.php?f=11&t=31223. I posted it on the forum because there was something else happening as well. Still the fps would have been higher before and after the 35 min mark in 94.1 MT.

In that thread it says about your replay:

no, this did not "go a lot better in 94.1" (you can reproduce it as easily there as in 95.0), and no, MT would not have mattered either.

So if you want to compare 94.1 performance to 95.0 it is a bad example.

But tbh i don't think that you going through replays I post to judge the quality of the games we mortals play is helpful.

My point was not to judge the quality of games.
But the type of game must be considered when discussing performance.
I could try to play a speedmetal game with 50k units in 95.0 and then complain about the low fps.
Hope you agree that such game would not even work in 94.1?
And with the 8v8 example I feel same: I do not believe such game was ever played in 94.1 without players lagging out.

But perhaps you have a better solution instead. That would be something for game devs to consider though.

Consider this:
With modoption maxunits =1000 and 16 players, there can at maxium be 16 * 1000 units = 16.000 units.
Nothing is really stopping players to build so many units so it is in theory possible.
Now consider if a game with 16.000 units would be playable, 94.1 or 95?
If you think yes, then please record a video of 16.000 peewees fighting each other because I am sure that would look epic!

Still I like the element in BA where you can make hundreds of the same unit the accomplish your goal. I think this adds to the game. If you don't keep an eye on you opponent he might just attack with 200-500 bombers/raiders/crawling bombs/whatever.

Thing is in small games (player wise) you might actually controll those 200-500 bombers. In a 8v8, never. 2500 units divided to 16 players is just 155 units per players. Now from those 155 units substract eco, substract turrets, how big will your army be? Maybe 50 units...

[Beherith]

I enjoy large games, there is constant action. But I also think 2000 units is a lot. Btw, I re-ran the replay after a fresh reboot (that always increases performace for me) and after upping my cpu from 3 to 3.8ghz (i5-750), and the game was reliably 30fps even at the end.

Also, read this http://springrts.com/mantis/view.php?id=4171 it probably applies to many people, and is fixed for 96.