QUIT GOING OFFTOPIC IN OTHER PEOPLES THREAD THEN!monohouse wrote:im not here to do damage, im trying to improve spring AND osrts, but it appears that some "smart" people do not understand that.
Questions for the devs.
Moderator: Moderators
Code: Select all
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
6.05 4.13 4.13 48633 0.00 0.00 CLosHandler::LosAdd(LosInstance*)
5.73 8.04 3.91 48367 0.00 0.00 CProjectileHandler::CheckUnitCol()
4.98 11.44 3.40 streflop_libm::__ieee754_sqrtf(float)
4.89 14.78 3.34 6810960 0.00 0.00 CCobInstance::Tick(int)
4.65 17.95 3.17 2408 0.00 0.00 CBFGroundDrawer::DrawShadowPass()
3.99 20.67 2.72 79927787 0.00 0.00 CPathFinder::TestSquare(MoveData const&, CPathFinderDef const&, CPathFinder::OpenSquare*, unsigned in$
3.75 23.23 2.56 425628697 0.00 0.00 CMoveMath::SquareIsBlocked(MoveData const&, int, int)
3.66 25.73 2.50 10519030 0.00 0.00 CUnit::Update()
2.86 27.68 1.95 61194 0.00 0.00 CLosHandler::CleanupInstance(LosInstance*)
2.70 29.52 1.84 48367 0.00 0.00 CProjectileHandler::Update()
I've been pondering these pathing problems and am enamored by the way Spring tests for pathfinding. When its only a few units the pathing works great. Add a traffic jame and they never get mobile. Its almost like there needs to be some kind of pecking order for pathing priority, perhaps veteran units can lock claim to the next several steps of their own path over lesser units. Even if its done by unit mass it makes more sense than the current static system.
Basically by leaving a scent trail for units to detect it alleviates the constant need to check for open spaces. Each space is marked both by a unit number and a path marker stepping. If a unit is surrounded by the scent trails of the superior units then it has to wait until its turn emerges on the pecking order. If a superior unit stomps a previously written scent trail then the trail past that intersection point disappears due to the lesser units path marker moving back to a stepping point short of the collision. Testing squares repeatedly by a whole mass of units has to be painful to cpu cycles, while laying scent trails helps limit the amount of pathfinding necessary. The current system encourages some units to 'get the f%&%$ out of the way' more or less, but doesn't really fasciliatate traffic james at all.
Basically by leaving a scent trail for units to detect it alleviates the constant need to check for open spaces. Each space is marked both by a unit number and a path marker stepping. If a unit is surrounded by the scent trails of the superior units then it has to wait until its turn emerges on the pecking order. If a superior unit stomps a previously written scent trail then the trail past that intersection point disappears due to the lesser units path marker moving back to a stepping point short of the collision. Testing squares repeatedly by a whole mass of units has to be painful to cpu cycles, while laying scent trails helps limit the amount of pathfinding necessary. The current system encourages some units to 'get the f%&%$ out of the way' more or less, but doesn't really fasciliatate traffic james at all.
Basically any optimization to 1 of those functions would be negligible.
Look at the %time column (the first). You see that the slowest function takes 6.05% of the execution time. Suppose you can make that single function 20% faster, which is already very optimistic, then spring in total would be no more then 1,21% faster. Which won't be noticed by anyone...
Also it takes heaps of time to do so, so personally I don't really see the point of manual optimizing atm.
I might take a look at using profiling information as input to the branch probability heuristic (possible with gcc), this may be relatively easy to do and I think it might give a whooping 1%..3% performance increase in the whole program... Also I might try setting -march=i686, that could shave off a few percent too by using better optimized instruction ordering and employing some pentium only functions like cmov etc.
Look at the %time column (the first). You see that the slowest function takes 6.05% of the execution time. Suppose you can make that single function 20% faster, which is already very optimistic, then spring in total would be no more then 1,21% faster. Which won't be noticed by anyone...
Also it takes heaps of time to do so, so personally I don't really see the point of manual optimizing atm.
I might take a look at using profiling information as input to the branch probability heuristic (possible with gcc), this may be relatively easy to do and I think it might give a whooping 1%..3% performance increase in the whole program... Also I might try setting -march=i686, that could shave off a few percent too by using better optimized instruction ordering and employing some pentium only functions like cmov etc.
No, it's just that most stuff in spring is algorithmically quite OK already (ie. we don't use bubble sort where quick sort or insertion sort should have been used), and shaving last % off by non-algorithmic optimizations (ie. unrolling loops, using arrays on the stack instead of std::vectors) takes leaps of time and is barely effective. Thats how it works in software development, it's not specific for spring.
One thing that occurred to me now tho is that the map renderer could probably be optimized quite a lot by making it use VBOs. (which probably accounts for 90% of the FPS difference between SMF and SM3)
One thing that occurred to me now tho is that the map renderer could probably be optimized quite a lot by making it use VBOs. (which probably accounts for 90% of the FPS difference between SMF and SM3)
There are specific things that are definitely CPU-intensive (and probably need to be fixed):
1. The code for Missiles is a mess. Missiles still cause more CPU use than any other weapon by a very large margin. I suspect that that code is needlessly repeating some instructions in sync that do not need it while it loops.
2. I described what I think may be a better concept for steering on the Command Engine site. Collisions are a major drag on performance of both the steering code and on the collision code, and I think that improving steering to reduce traffic jams may have very beneficial results.
3. The code that handles FALL events needs to use default sizes (or better yet, user-defined sizes) for the collision spheres of all objects, instead of using the (expensive) code it uses to determine the size and origins of all objects subject to FALL. That code should also use the origins defined in the 3DO/S3O instead of creating a new one.
Anyhow, these are areas where I am pretty sure that significant, episodic gains can still be found. FALL events and missile code are things that drag down performance in bursts, which in turn probably causes a lot of lag during games. Any given event is not terribly costly, but during major fights, it gets expensive, fast.
And I think that things like automated aircraft-crashes, smoke using CSmoke coming from wreckage, smoke coming out've Geos, and a lot of other "little stuff" should be put under control of modders, so that we can decide if we want this code to run or not. A lot of these "little things" eat up performance episodically and could be optimized by modders- for example, if Geos called a customExplosionGenerator with a default script that invokes CSmoke, modders would have the option of eliminating it from their mods, modifying the script to use a less expensive option such as CSimpleParticleSystem, or whatnot. Opening such things to modders will probably benefit the game more than you'd think for the amount of time it'd take to code, and it'd provide modders with yet another area to look at for optimization.
Just my opinions, of course. Overall, this version of Spring is far smoother than the previous release, so you guys must be doing something right
1. The code for Missiles is a mess. Missiles still cause more CPU use than any other weapon by a very large margin. I suspect that that code is needlessly repeating some instructions in sync that do not need it while it loops.
2. I described what I think may be a better concept for steering on the Command Engine site. Collisions are a major drag on performance of both the steering code and on the collision code, and I think that improving steering to reduce traffic jams may have very beneficial results.
3. The code that handles FALL events needs to use default sizes (or better yet, user-defined sizes) for the collision spheres of all objects, instead of using the (expensive) code it uses to determine the size and origins of all objects subject to FALL. That code should also use the origins defined in the 3DO/S3O instead of creating a new one.
Anyhow, these are areas where I am pretty sure that significant, episodic gains can still be found. FALL events and missile code are things that drag down performance in bursts, which in turn probably causes a lot of lag during games. Any given event is not terribly costly, but during major fights, it gets expensive, fast.
And I think that things like automated aircraft-crashes, smoke using CSmoke coming from wreckage, smoke coming out've Geos, and a lot of other "little stuff" should be put under control of modders, so that we can decide if we want this code to run or not. A lot of these "little things" eat up performance episodically and could be optimized by modders- for example, if Geos called a customExplosionGenerator with a default script that invokes CSmoke, modders would have the option of eliminating it from their mods, modifying the script to use a less expensive option such as CSimpleParticleSystem, or whatnot. Opening such things to modders will probably benefit the game more than you'd think for the amount of time it'd take to code, and it'd provide modders with yet another area to look at for optimization.
Just my opinions, of course. Overall, this version of Spring is far smoother than the previous release, so you guys must be doing something right