Page 2 of 3
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 00:39
by zerver
This reduces the CPU usage for 1500 patrolling fighters by ~50%:
http://github.com/spring/spring/commit/ ... 7d6a7241db
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 08:13
by aegis
caches recent hits in the same area so the separate units effectively share lookups?
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 08:27
by thesleepless
looks like it! nice
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 16:05
by Tobi
Lol, what had you been smoking when making this?
I pretty much said exactly how the functions could be improved, and the code needed for this was already present in GenerateTargets... no need for cache at all.
I implemented this now, and it's more then twice as fast as your caching solution, without making the algorithm inexact and without adding new code (everything I used was already present in GenerateTargets.)
Timing results
This is total time spent in CGameHelper::GetClosestEnemyUnit and CGameHelper::GetClosestEnemyAircraft, in a game using BA 7.00 on Bluebend, 1500 armhawks.
Manual test:
Code: Select all
2 min game, 1 min patrol, original: 17.70 sec
2 min game, 1 min patrol, zerver : 4.89 sec
2 min game, 1 min patrol, Tobi : 1.58 sec
Test using replay, so 100% identical game each time:
Code: Select all
3 min game, 2 min patrol, original: 30.05 sec
3 min game, 2 min patrol, zerver : 5.05 sec
3 min game, 2 min patrol, Tobi : 2.47 sec
EDIT: ok, maybe on long term (after 17 minutes on exactly same patrol route, follows from simple linear extrapolation) yours might be slightly faster, as I got this for 10 minutes:
Code: Select all
10 min game, 9 min patrol, zerver: 12.37 sec
10 min game, 9 min patrol, Tobi : 10.99 sec
(But OTOH, my optimization also helps ground units and Lua gadgets that use GetClosestEnemyUnit, which aren't considered in this test.)
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 16:52
by ginekolog
Nice one Tobi, figter patrols are biggest causes of lag in big games :)
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 20:10
by Pendrokar
Tobi : Zerver
2 : 1
Let the competition really begin!!! Competition => Progress
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 20:40
by Beherith
Thank you both (Tobi and zerver) for adding a great performance improvement!
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 21:24
by hunterw
this game is so awesome
if only more ppl played it
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 21:33
by zerver
Tobi wrote:
Lol, what had you been smoking when making this?
I pretty much said exactly how the functions could be improved, and the code needed for this was already present in GenerateTargets... no need for cache at all.
EDIT: ok, maybe on long term (after 17 minutes on exactly same patrol route, follows from simple linear extrapolation) yours might be slightly faster, as I got this for 10 minutes:
So just because you say how to improve it, I have to follow orders? I didn't smoke anything and the caching can be even faster - just increase the cache expiration time.
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 21:39
by imbaczek
lkml-class flamewar on the horizon, captain! /me dons asbestos suit
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 21:57
by Tobi
zerver wrote:Tobi wrote:
Lol, what had you been smoking when making this?
I pretty much said exactly how the functions could be improved, and the code needed for this was already present in GenerateTargets... no need for cache at all.
EDIT: ok, maybe on long term (after 17 minutes on exactly same patrol route, follows from simple linear extrapolation) yours might be slightly faster, as I got this for 10 minutes:
So just because you say how to improve it, I have to follow orders? I didn't smoke anything and the caching can be even faster - just increase the cache expiration time.
If it's arguably the best / a better thing to do to the code, then it's a bit silly IMO to implement a suboptimal solution, in particular if the better solution is handed to you on a silver platter (both in my posts and in the existing CGameHelper::GenerateTargets code; I only had to copy paste it to implement my code)...
Sorry if I offended you with the joke about smoking though
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 22:05
by zerver
1500 fighters in DSD style patrol pattern:
Mine: 57% cpu.
Yours: 63% cpu.
Mine+yours: ?
Sorry to disappoint you, but there wont be any flamewar.
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 22:06
by Argh
Yeah, I want to see the peanut and jelly together before reading more flames.
Moreover, I'm more interested in what happens when you split that 1500 fighters into 10 groups on different paths. It's been my experience that the slowdown in Patrol is when you have aircraft all over the Map... not some ridiculous bunched-up cluster.
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 22:09
by zerver
Like tobi said, my solution wont be that good if the patrol routes are random or complicated...
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 22:12
by Argh
Yours will help with the cluster- for raids where Patrol gets used as the control parameter. That's fine- there is a point to that, for gunships especially. I'm just saying... the main clobberin' time is when you have factories on Repeat, building fighters on long, complex Patrol paths, as a for-instance.
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 22:26
by Tobi
Both solutions reduce the number of units visited immensely. Zerver's reduces it -after one call- by the number of allied units in every quad in the search space which does not contain any enemy units. Mine reduces it unconditionally by the number of allied units in the search space, though it adds a tiny constant overhead per quad (a loop through all allyteams).
Combined solution probably wouldn't help much, as then you're caching the result of the best running time case of GetClosestEnemyUnit/Aircraft. (Only looping through all allyteams and observing none of the enemy allyteams have any units in that quad.)
Re: fighters on "patrol" = performance hit
Posted: 14 Sep 2009, 22:31
by zerver
Tobi wrote:Combined solution probably wouldn't help much
I have confirmed that, it seems now that other things are predominant in hogging up the CPU.
Re: fighters on "patrol" = performance hit
Posted: 15 Sep 2009, 06:51
by Dragon45
tobi wrote:
Lol, what had you been smoking when making this?
Nice zinger there, Linus Shaw Hannson.
Re: fighters on "patrol" = performance hit
Posted: 17 Sep 2009, 08:39
by hoijui
thanks you two!
fighterscreens are really the killer of my machine, and i was usually not alone with this in average till big games.
Re: fighters on "patrol" = performance hit
Posted: 18 Sep 2009, 22:52
by Soul
A slight offtopic post, but LOS was mentioned eariler so its only a small sin.
Does anyone know if every unit have their LOS overlapping eachother, or if one units LOS "ends" where another units LOS begin?
And yes, i'm not stupid, the LOS overlapping would be the most probable, but I still want to be certain.
I'm not saying that making LOS end where another units LOS begins would draw down the CPU usage, most likely the opposite (due to the additional code that needs to be processed).
Oh, and to make this post slightly more on track: Wasn't fighter spam nerfed like ages ago? I remember NOiZE killing my com with a handfull fighters one day, while I couldn't even hurt his commander below 80%HP with twice the amount of figthers after the nerf.
And he was like "Dude, didn't you read last nights patchlog?"