Lua <-> cob interaction
Moderator: Moderators
Lua <-> cob interaction
I'm constantly being told how slow this is and to avoid it at all costs. Has anyone actually done any real testing on the slowness or is it conjecture due to the overhead of the number of calls between lua, cob and the engine it entails?
Re: Lua <-> cob interaction
I dunno about the luacob function calls, but there's no reason for the lua/cob variable interaction to be slow from what I've seen in cobinstance.
Re: Lua <-> cob interaction
Wasn't it Argh who started the whole 'LuaCOB is slow' talk? He sometimes has strange views on performance issues (as in he often overestimates the value of small performance losses). We probably need to test this matter, shouldn't be hard to do. I'll try making a unit call a simple lua function from COB and see what happens with 500 of that unit ingame compared to 500 of the same unit, but without lua calls.
Update: results are as follows.
Spring version: svn r5889 compiled using scons, gcc 4.2.1
fps with no units on screen: 60
fps with 500 units without lua calls: 29-30
fps with 500 of the same unit, but with COB->Lua call repeating every 150ms for every unit (called lua function does nothing except comparing 2 variables so that it isn't completely empty): 27-28
Units were /cheat /given both times.
Seems like a very small difference to me.
Update: results are as follows.
Spring version: svn r5889 compiled using scons, gcc 4.2.1
fps with no units on screen: 60
fps with 500 units without lua calls: 29-30
fps with 500 of the same unit, but with COB->Lua call repeating every 150ms for every unit (called lua function does nothing except comparing 2 variables so that it isn't completely empty): 27-28
Units were /cheat /given both times.
Seems like a very small difference to me.
Last edited by yuritch on 15 May 2008, 21:42, edited 2 times in total.
Re: Lua <-> cob interaction
If you'd do that I will love you forever yuri.
even more than I already do.
From a programmers point of view, considering a script looking to perform a function whenever the unit fires a weapon with a particulr tag, it seems much more elegant to me for said unit to call the lua function from its cob when and only when that weapon is fired, rather than the alternative currently used for the S44 ammo system, in which a table maintains the weapons with the tag, and an infinite loop checks for changes in the reload state of said collection of weapons every few frames . Of course, the latter will have a constant performance drain and the former will spike during battles. It'd be interesting to compare the two methods directly.
even more than I already do.
From a programmers point of view, considering a script looking to perform a function whenever the unit fires a weapon with a particulr tag, it seems much more elegant to me for said unit to call the lua function from its cob when and only when that weapon is fired, rather than the alternative currently used for the S44 ammo system, in which a table maintains the weapons with the tag, and an infinite loop checks for changes in the reload state of said collection of weapons every few frames . Of course, the latter will have a constant performance drain and the former will spike during battles. It'd be interesting to compare the two methods directly.
Re: Lua <-> cob interaction
Updated my post above with the results. The difference is small, nearly too small for my liking, so if someone can repeat the test, we'll have more reliable results.
Re: Lua <-> cob interaction
Sweet.
Looks like I'm rewriting our ammo system afterall then.
Looks like I'm rewriting our ammo system afterall then.
Re: Lua <-> cob interaction
Um, I started writing a TL:DNR version, but meh, I stopped, there's a simpler way to express how I feel about this, after grinding on P.U.R.E.'s code for months:
1. Calling COB via Lua is not bad, and I use it a lot. I just don't do it every frame, because that is very wasteful. Call things irregularly- use random numbers, etc. Instead of every 150 ms, use a range, from 100-200 ms. And a 2FPS drop seems like no biggie, but that's a purely CPU-based drop, at that point- if you, say, then have a bunch of CPU-hungry CEGs running... trouble may ensue. A much better stress-test... make the 500 units, then have them pathfind a patrol route around the map... the spikes in CPU activity caused by steering code are a better way of seeing what a "2 FPS" drop actually does, when there are a lot of CPU-crunching things happening occasionally.
2. Calling Lua from COB is not bad, and again, I use it a lot. Same issues, same speed, or close enough it doesn't matter.
3. Anything that has to be run every frame via LuaCOB had better be both very important... and short. Lua runs faster than COB, so it's probably tempting to do certain types of things there, but... there's all that overhead of moving the data back and forth, transforming the numbers, etc. I have not done anything like definitive tests on this, but I suspect it's a net loser to do most math this way.
4. Anything that isn't frame-bound had better be vital or amazingly cool looking... or it should get cut.
Basically, it's about length-of-execution only a small amount of the time, imo.
Mainly, it's about frequency and load-balancing your code, so that you don't overwhelm people's CPUs. Pretty much all I have to say about this.
1. Calling COB via Lua is not bad, and I use it a lot. I just don't do it every frame, because that is very wasteful. Call things irregularly- use random numbers, etc. Instead of every 150 ms, use a range, from 100-200 ms. And a 2FPS drop seems like no biggie, but that's a purely CPU-based drop, at that point- if you, say, then have a bunch of CPU-hungry CEGs running... trouble may ensue. A much better stress-test... make the 500 units, then have them pathfind a patrol route around the map... the spikes in CPU activity caused by steering code are a better way of seeing what a "2 FPS" drop actually does, when there are a lot of CPU-crunching things happening occasionally.
2. Calling Lua from COB is not bad, and again, I use it a lot. Same issues, same speed, or close enough it doesn't matter.
3. Anything that has to be run every frame via LuaCOB had better be both very important... and short. Lua runs faster than COB, so it's probably tempting to do certain types of things there, but... there's all that overhead of moving the data back and forth, transforming the numbers, etc. I have not done anything like definitive tests on this, but I suspect it's a net loser to do most math this way.
4. Anything that isn't frame-bound had better be vital or amazingly cool looking... or it should get cut.
Basically, it's about length-of-execution only a small amount of the time, imo.
Mainly, it's about frequency and load-balancing your code, so that you don't overwhelm people's CPUs. Pretty much all I have to say about this.
Re: Lua <-> cob interaction
I'm going to do more in-depth testing including luacob itself later, but I might as well mention the preliminary cob and lua results from a couple weeks back.
Running an empty for loop in lua was twenty times faster than one in cob, and get calls took the same amount of time.
Running an empty for loop in lua was twenty times faster than one in cob, and get calls took the same amount of time.
Re: Lua <-> cob interaction
Is cob code executed in a seperate thread to the rest of the engine?
Perhaps we should recreate the supcom animation API so that e can take advantage of the cob->lua tools for porting TA units to supreme commander..
Perhaps we should recreate the supcom animation API so that e can take advantage of the cob->lua tools for porting TA units to supreme commander..
Re: Lua <-> cob interaction
It's all done in one thread. I tested this with loops that locked the entire process for over 10 seconds, so it's definitely not an issue of delayed execution. And frankly, putting cob in its own thread would be extremely difficult and wouldn't really pay off. Things like pathing and LOS are far better targets. And obviously rendering, because that's not even part of the sim.