LUA script -> native spring features

[Masure]

Hi,

Is it planned to put some LUA features in the spring code ? I don't have a particular LUA script in mind but if one day something is used by everybody, could it be hardcoded in spring ?

Can you have serious speed improvement implementing features in spring instead of scripting LUA ?

I think LUA scripting should be a springboard to try & accept new features. As everybody can make lua scripts, it doesn't mess spring code and allows to validate some good stuff.

Maybe I overestimate the cpu cost of running tons of LUA widgets (gfx + unit scripts).

[SwiftSpear]

No, we're moving away from hardcoding as much as possible. Hardcoding in spring = poo for modders who want to do something different.

[Tobi]

Hi,

Is it planned to put some LUA features in the spring code ? I don't have a particular LUA script in mind but if one day something is used by everybody, could it be hardcoded in spring ?

In theory, yes. With the current amount of available man-hours I do not think it would be a good idea, there is better stuff to do then to port LUA scripts to C++ and integrate them into the engine.

Can you have serious speed improvement implementing features in spring instead of scripting LUA ?

Probably yes, but as is always the case with optimization, first find the 5% of code (whether LUA or C++) that is actually worth optimizing, and only optimize that piece of code. IOW, it may be a better idea to just add a call out to perform some generic expensive calculation instead of porting entire LUA scripts to the engine.

[Masure]

I was wondering about the performance between LUA scripted and hardcoded.

I don't say that everything should be hardcoded. For exemple, see healthbar widget. It reduces fps a lot. Would hardcoding it (with modding capabilities) give better performance ?

[imbaczek]

Probably yes, but as is always the case with optimization, first find the 5% of code (whether LUA or C++) that is actually worth optimizing, and only optimize that piece of code. IOW, it may be a better idea to just add a call out to perform some generic expensive calculation instead of porting entire LUA scripts to the engine.

BTW I recently did just that, functions that use more than 1% of total time:

Code: Select all

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
  7.10      5.27     5.27      953     0.01     0.01  LzmaDecode
  6.15      9.84     4.57                             streflop_libm::__ieee754_sqrtf(float)
  5.08     13.61     3.77                             _fu429____glewProgramEnvParameter4fARB
  4.58     17.01     3.40    30226     0.00     0.00  CLosHandler::LosAdd(LosInstance*)
  3.85     19.87     2.86 49955115     0.00     0.00  CPathFinder::TestSquare(MoveData const&, CPathFinderDef const&, CPathFinder::OpenSquare*, unsigned int)
  3.54     22.50     2.63 156498805     0.00     0.00  CMoveMath::SquareIsBlocked(MoveData const&, int, int)
  3.22     24.89     2.39 153408504     0.00     0.00  CVertexArray::AddVertex0(float3 const&)
  2.77     26.95     2.06    37823     0.00     0.00  CLosHandler::CleanupInstance(LosInstance*)
  2.56     28.85     1.90     6061     0.00     0.00  CLosHandler::SafeLosAdd(LosInstance*, int, int)
  2.22     30.50     1.65 10031112     0.00     0.00  CGround::LineGroundSquareCol(float3 const&, float3 const&, int, int)
  1.84     31.87     1.37   758140     0.00     0.00  CCobInstance::Tick(int)
  1.58     33.04     1.17 13907448     0.00     0.00  void std::__adjust_heap<CPathFinder::OpenSquare**, int, CPathFinder::OpenSquare*, CPathFinder::lessCost>(CPathFinder::OpenSquare**, int, int, CPathFinder::OpenSquare*, CPathFinder::lessCost)
  1.52     34.17     1.13    10989     0.00     0.00  CProjectileHandler::CheckUnitCol()
  1.49     35.28     1.11  2212187     0.00     0.00  CUnit::Update()
  1.36     36.29     1.01                             _fu216____glewActiveTextureARB
  1.28     37.24     0.95     1619     0.00     0.00  CBFGroundTextures::LoadSquare(int, int, int)
  1.16     38.10     0.86   154608     0.00     0.00  CPathFinder::DoSearch(MoveData const&, CPathFinderDef const&)
  1.09     38.91     0.81 32968815     0.00     0.00  CMoveMath::SpeedMod(MoveData const&, int, int)
  1.06     39.70     0.79                             __cxxabiv1::__si_class_type_info::__do_dyncast(int, __cxxabiv1::__class_type_info::__sub_kind, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info const*, void const*, __cxxabiv1::__class_type_info::__dyncast_result&) const
  1.04     40.47     0.77    10210     0.00     0.00  CMiniMap::DrawForReal()
  1.02     41.23     0.76    10210     0.00     0.00  CProjectileHandler::Draw(bool, bool)
  1.01     41.98     0.75 33450085     0.00     0.00  CMoveMath::IsBlocked2(MoveData const&, int, int)

What comes out of it is this:
- square roots are expensive
- LOS is very expensive and could use a lot of optimization, possibly a rewrite
- pathfinding is expensive
- the rest are details, but of course if you've got some wacky Lua, it's not going to be better.

[Tobi]

What kind of test case? Demo from a real game or just some playing around?

In any case it looks like earlier profiles; in certain load cases you can get some QuadField functions to show up on top though, IIRC (that was reason for SJ to optimize them a bit, quite a while ago already).

[imbaczek]

Playing around with planes and flashes, nothing big, but I expect the same functions at the top, just in different order.

[AF]

try it with kernel panic for 20 mins using the easy AI script zwzsg wrote

[imbaczek]

AF: You'll need to provide a sane makefile for NTai first, or wire it up in scons ^^

[AF]

scons automagically does it IIRC, but trepan unwired it IIRC, I think someone else mentioned it too.

I think ti would help enourmously if it was wired back in for the sole reason that it means NTai crashes could be fixed using spring stack traces whereas atm I have failed tog et a single debugger to actually work, code blocks, netbeans, VS2005, VS2003, VC++ 6 all horrible nightmares of unexplainable failure.

[Tobi]

I enabled it locally but it needs to link to some boost stuff to work fine (on MinGW, on Linux it would probably work fine because of the different dynamic linking design).

Once the build system is hacked to do that it can be enabled again.

(Though I'm actually thinking about splitting off the AIs from the buildsystem to make it a less monolithic beast and to be able to move engine stuff to trunk/Engine without breaking AI compilation.)