it's been a while so. Why is spring so darned slow.
Moderator: Moderators
Re: it's been a while so. Why is spring so darned slow.
I am no looking for an arbitrary measurement argh. This is entirely why I asked you to stay out originally you mean well, I do understand but this is not what I was asking
Re: it's been a while so. Why is spring so darned slow.
What's arbitrary about it, Smoth?
Explain.
Explain.
Re: it's been a while so. Why is spring so darned slow.
All of KDR's mods use LuaRules pretty extensively?Pxtl wrote:I think KDR proved a half-dozen times that naked Lua-less Spring can be used for distinct, non-TA gameplay,
Re: it's been a while so. Why is spring so darned slow.
KDR was making Spring mods before Lua was introduced into the engine. Does nobody remember that tank mod with shields on the fronts of every tank, early versions of Kernel Panic, and CvC?
Re: it's been a while so. Why is spring so darned slow.
Yeah, they were cute and fairly buggy. Anyhow, this is a derail.
Re: it's been a while so. Why is spring so darned slow.
i think smoth means he doesn't want to go benchmarking and guessing since there are a hojillion competing variables, and even after benchmarking you'll get people doing guesswork that would be better-provided by a dev.
IE: Why is having 500 planes slow? Is it obstacle-avoidance or just calculating LOS?
He wants the devs to come down and say "this function is a beast and we get O┬▓ performance on units with this feature".
IE: Why is having 500 planes slow? Is it obstacle-avoidance or just calculating LOS?
He wants the devs to come down and say "this function is a beast and we get O┬▓ performance on units with this feature".
Re: it's been a while so. Why is spring so darned slow.
The problem there is that those kinds of "absolute" numbers aren't really that useful, from a standpoint of "what do I need to change to make my game work faster" perspective.
And unless a test is done with a game that's using most of the features, it's pretty meaningless. For example, BA doesn't use anywhere near the triangle counts or texture throughput of a S3O game. And other than S'44, I don't think anything that's released uses unitRendering yet.
IOW, what the real chokepoints are is often largely dependent on what people are actually doing and what they want the engine to be able to do, as opposed to ivory-tower speculations about code efficiency for any given function.
Lastly, if Smoth just wanted to know the ivory-tower numbers, there are all those huge fancy profiles that have been posted here before, with detailed breakdowns, showing pathfinding and other things to be the big killers... when they're testing with BA.
I don't think that's what we'll see with tests of other games at all.
And unless a test is done with a game that's using most of the features, it's pretty meaningless. For example, BA doesn't use anywhere near the triangle counts or texture throughput of a S3O game. And other than S'44, I don't think anything that's released uses unitRendering yet.
IOW, what the real chokepoints are is often largely dependent on what people are actually doing and what they want the engine to be able to do, as opposed to ivory-tower speculations about code efficiency for any given function.
Lastly, if Smoth just wanted to know the ivory-tower numbers, there are all those huge fancy profiles that have been posted here before, with detailed breakdowns, showing pathfinding and other things to be the big killers... when they're testing with BA.
I don't think that's what we'll see with tests of other games at all.
Re: it's been a while so. Why is spring so darned slow.
Go fuck yourself run time analysis is a an important part of understanding how a data structure will hurt you performance wise just because you pack the education does not give you the right to call it ivory tower bullshit. If it wasn't for those ivory towers your dumbass would not be able to interface with a computer.
We. Stand on the shoulders of giants and it would behoove you to respect those very large footprints
We. Stand on the shoulders of giants and it would behoove you to respect those very large footprints
Re: it's been a while so. Why is spring so darned slow.
Please rewrite that to make some sense and try cursing less.
I've explained why the numbers aren't that useful, and if you're not able to use the search function and look up the previous profiling work, then you should not be cursing at people who read that stuff and concluded that the resulting numbers weren't that useful in terms of understanding what's going on in games with very different parameters.
I've said some pretty reasonable things here, in my opinion:
1. Testing with BA tells the devs a lot of lies. Testing needs to use something else, or it's not telling us much that's useful.
2. We need an agreed-upon way to present benchmarks and evaluate our games' operations in this engine, so that these discussions aren't full of guesswork and people behaving badly.
3. No one game will use all the features that need to be evaluated to give us a good idea where the real chokepoints are.
4. I don't think the devs know what is causing issues with your game, or my game, or anything but BA. So their statements aren't the word of "giants", they're the statements of fallible computer scientists. It's not that they aren't brilliant people; but even brilliant people can fail to see the obvious.
5. Profiling is more art than science. It's useful, but it requires context. A function that's really fast but gets used 10K times per cycle is effectively a lot slower than one that gets used once but is 1000 times slower.
I've explained why the numbers aren't that useful, and if you're not able to use the search function and look up the previous profiling work, then you should not be cursing at people who read that stuff and concluded that the resulting numbers weren't that useful in terms of understanding what's going on in games with very different parameters.
I've said some pretty reasonable things here, in my opinion:
1. Testing with BA tells the devs a lot of lies. Testing needs to use something else, or it's not telling us much that's useful.
2. We need an agreed-upon way to present benchmarks and evaluate our games' operations in this engine, so that these discussions aren't full of guesswork and people behaving badly.
3. No one game will use all the features that need to be evaluated to give us a good idea where the real chokepoints are.
4. I don't think the devs know what is causing issues with your game, or my game, or anything but BA. So their statements aren't the word of "giants", they're the statements of fallible computer scientists. It's not that they aren't brilliant people; but even brilliant people can fail to see the obvious.
5. Profiling is more art than science. It's useful, but it requires context. A function that's really fast but gets used 10K times per cycle is effectively a lot slower than one that gets used once but is 1000 times slower.
Re: it's been a while so. Why is spring so darned slow.
I will no because I am posting from my phone. Get out the thread you are derailing the discussion and don't understand what I am asking. You are not the one I asked the question to do not answer a question asked to some one else
smoth wrote:well is the pathfinder still expensive?
How much does unit piececount effect performance?
If I reclaim features does that cause a pathfinder update? if so, is it expensive?
Why is it the spring graphics are so taxing? As in often halving fps where as I can run many other games just fine(keep in mind I am talking even recent titles).
Does the mapsize alone(due to pathfinder updates etc) eat performance?
How accurate is the debug graph or is it really more of a crude performance calculation?
These are some of the questions.
Re: it's been a while so. Why is spring so darned slow.
Most of your questions were answered in the profiling tests that have been done, but here are a few answers, off the top of my head:
1. Piececount is a big performance consideration, due to the way that the engine handles the OpenGL setup per piece, which is fairly expensive and involves some matrix math. There's also the impact on sim, which needs to track all Pieces every gameframe, which uses the same math.
2. Features effect the pathfinder, period. When they're removed, the pathfinder does need to update, and yes, that's fairly expensive.
3. Spring graphics are very taxing, and I have no idea why, but my first guess is because of issue no. 1. I think there's more to it, though, but I can't hazard a guess because I haven't read that code in ages. I started the vertex animation thread largely because my guess is that if issue no. 1 is gone and most Units use just one display list, Spring's graphical performance will jump a lot, even if the underlying technique is a little slower.
4. Mapsize has a very large performance impact, not just because of pathfinding but also because of data fetch operations.
5. The debug graph is pretty worthless atm, because it's not storing the results in a format that we can read in another application like Excel to see changes over time, nor is it breaking up the operations enough to tell us what we really need to know, nor is it measuring all the things that matter.
Anyhow, hope that was useful, and I welcome developer responses to any of the parts that need correction or fuller explanation.
1. Piececount is a big performance consideration, due to the way that the engine handles the OpenGL setup per piece, which is fairly expensive and involves some matrix math. There's also the impact on sim, which needs to track all Pieces every gameframe, which uses the same math.
2. Features effect the pathfinder, period. When they're removed, the pathfinder does need to update, and yes, that's fairly expensive.
3. Spring graphics are very taxing, and I have no idea why, but my first guess is because of issue no. 1. I think there's more to it, though, but I can't hazard a guess because I haven't read that code in ages. I started the vertex animation thread largely because my guess is that if issue no. 1 is gone and most Units use just one display list, Spring's graphical performance will jump a lot, even if the underlying technique is a little slower.
4. Mapsize has a very large performance impact, not just because of pathfinding but also because of data fetch operations.
5. The debug graph is pretty worthless atm, because it's not storing the results in a format that we can read in another application like Excel to see changes over time, nor is it breaking up the operations enough to tell us what we really need to know, nor is it measuring all the things that matter.
Anyhow, hope that was useful, and I welcome developer responses to any of the parts that need correction or fuller explanation.
Last edited by Argh on 29 Sep 2010, 23:48, edited 1 time in total.
Re: it's been a while so. Why is spring so darned slow.
@Argh, do you know if that piececount performance stuff includes issues with invisible pieces? I mean, I know Sim needs to be tracked for non-visible pieces, but what's the performance of OGL ones? I ask because invisible pieces are the obvious easy solution to customizable units.
That said, there are issues that really do need dev consideration, and it's fair for Smoth to want to hear those concerns answered directly.
For example, it would be good to know which performance costs grow with map size - that will tell modders what can be done to mitigate the performance problems on superhuge maps, if any.
That said, there are issues that really do need dev consideration, and it's fair for Smoth to want to hear those concerns answered directly.
For example, it would be good to know which performance costs grow with map size - that will tell modders what can be done to mitigate the performance problems on superhuge maps, if any.
Last edited by Pxtl on 29 Sep 2010, 23:50, edited 1 time in total.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: it's been a while so. Why is spring so darned slow.
1. Yes, but I don't know how much, so you can safely ignore this answer.smoth wrote:well is the pathfinder still expensive?
How much does unit piececount effect performance?
If I reclaim features does that cause a pathfinder update? if so, is it expensive?
Why is it the spring graphics are so taxing? As in often halving fps where as I can run many other games just fine(keep in mind I am talking even recent titles).
Does the mapsize alone(due to pathfinder updates etc) eat performance?
How accurate is the debug graph or is it really more of a crude performance calculation?
These are some of the questions.
2. For clarifications sake, are you speaking of actual pieces or just the points we use for emitting things or all of the above?
3. I don't believe so, but I really don't know.
4. To some degree, I'd like to know the answer to this myself.
5. Yes, that much can be easily found by comparing a ton of units on a small 8x8 map to a 16x16 map. The performance difference I would say is roughly 50%, from my experience anyway.
6. Dunno.
Re: it's been a while so. Why is spring so darned slow.
@Pxtl:
IIRC, invisible Pieces incur the same costs. Again, IIRC (and devs feel free to say I'm an idiot if I've remembered wrong) the Piece matrix is calculated once per game frame, and once per render frame, whether it's visible or not. This is because we need that matrix to give us vectors for things like emitting FX.
@Forb: points are considered to be Pieces.
Oh, and:
IIRC, invisible Pieces incur the same costs. Again, IIRC (and devs feel free to say I'm an idiot if I've remembered wrong) the Piece matrix is calculated once per game frame, and once per render frame, whether it's visible or not. This is because we need that matrix to give us vectors for things like emitting FX.
@Forb: points are considered to be Pieces.
Oh, and:
I am seriously considering halving the size of all the P.U.R.E. maps, halving the LOS, halving ranges / speeds / Unit sizes, and using SSMF to make it pretty. I'm not sure how practical it will be yet, but I'm going to do some tests and find out.For example, it would be good to know which performance costs grow with map size - that will tell modders what can be done to mitigate the performance problems on superhuge maps, if any.
Re: it's been a while so. Why is spring so darned slow.
Seems a bit premature to close discussion, tbh. A lot of interesting stuff has been said, and I'd like to hear more from everybody.
Re: it's been a while so. Why is spring so darned slow.
I have luajit to where it doesn't segfault on linux, but I still have weird broken behavior on windows. I should have my desktop back online in a week, miswired outlet killed it.
Re: it's been a while so. Why is spring so darned slow.
How much of a big deal was it, when you got it rolling? I'm not going to be surprised if the answer is, "not as much as you hoped for", but even little things would be nice 
Re: it's been a while so. Why is spring so darned slow.
I didn't benchmark it. I didn't even bother taking off the API safeguards or turning on JIT.
Re: it's been a while so. Why is spring so darned slow.
OK, so it just got to the "it compiles, yay" point. I guess we'll just have to wait and see.