Effect of LUA Scripting

[SpliFF]

The only assumptions that were made about you were that you didn't know enough about Lua or Spring to be telling us its too slow. Other than that your questions appear to be answered.

BTW, the majority of modders are artists or high-school level programmers. Giving them a C++ interface to the Spring Engine is guaranteed fail. Few other scripting languages are as fast, easy-to-use or compact in memory as Lua. It's the the best tool for the job.

[computerquip]

My original thought isn't that it was too slow. My original thought was that it was too slow for large operations that can be more efficient simply because it being interpreted. Also, I never said Spring itself was slow. I think Spring itself is at least well made on the outside and I'm 90% sure on the inside.

Plus, I'm a high school student as well. I'd fit right in.

Many a time have I seen people, preferably friends, code bullshit in Java, or something else in a side script that wasn't needed and as a result making it slow, clunky, and bad in general. Sure it's convenient but for the longer run, I'd rather not sacrifice performance and efficiency on convenience when it might matter. That's how my mind works.

EDIT: Though this statement might seem to go well with coding everything in ASM, it's a well known fact that ASM is a long and complicated language. In many cases, a C++ compiler can make better ASM than a human. Pretty much any compiler beats me at ASM :$

[imbaczek]

Sure it's convenient but for the longer run, I'd rather not sacrifice performance and efficiency on convenience when it might matter. That's how my mind works.

Ah, here's the culprit. We have exactly the same attitude, but with one crucial difference: we only care about performance when it matters, not when it might.

[computerquip]

I know I'm a bit paranoid :/

[KDR_11k]

Premature optimization is the root of all errors.

[computerquip]

Premature optimization is the root of all errors.

I don't prematurely optimize. I just wish to make a plan that leads to the best performance and efficiency.

[aegis]

how can you know the path of greatest efficiency and performance without seeing solid scientific data or having extensive experience in the matter?

[AF]

To the mathmobile!!!

[Beherith]

This thread actually cleared me up on some stuff about Lua. So i rate this on a scale of 1 to gota: gota.

[SpliFF]

My original thought isn't that it was too slow. My original thought was that it was too slow for large operations that can be more efficient simply because it being interpreted.

It is a common mistake to equate "slower than" with "too slow". So let's put things in perspective.

Lua's "interpreter" doesn't operate on strings. It compiles strings to bytecode and operates on that. So after a small delay to load the Lua file (tiny actually relative to reading the file off disk) we have Lua's internal C routines operating on arrays of binary code and data.

Now let's say for arguments sake that these benchmarks are accurate and Lua is on average 30x slower than C for the same set of operations. Let's also say this implies Lua requires 30 instructions for every 1 of C/C++.

Now let's also assume that this chart is also accurate and a modern processor like the Intel Core 2 Extreme X6800 can really do 27 billion instructions per second.

If you assume that, on average each basic C operation requires 10 microcode instructions That implies Lua can do ~ 100 million Lua instructions per second. Anyway I put it to the test. The following tests perform a billion additions and assignments:

loop.c

Code: Select all

int i=0;
int j=0;

int main() {
        for (i=0; i<1000000000; i+=1) {
                j+=i;
        }
        return 0;
}

loop.lua

Code: Select all

local i=0
local j=0

for i=1, 1000000000 do
        j = j+i
end

Code: Select all

spliff@betamax ~ $ sh speedtest.sh ./loop
It took 3 seconds
spliff@betamax ~ $ sh speedtest.sh lua loop.lua
It took 22 seconds
spliff@betamax ~ $ sh speedtest.sh lua loop.luac #compiled lua
It took 22 seconds

Much less than 30x slower on my Core2 3.0Ghz even accounting for loading the Lua interpreter and compiling the script. Which goes to show you shouldn't trust benchmarks. At any rate, what we can take away from this is that lua is capable of performing something like 45 million lua instructions per second in addition to the overhead of the loop itself.

How many lua instructions per second would your average mod run? No idea. Nor do I feel like finding out. Mainly because it isn't even necessary to guess these things, there are at least two code profilers that will report exactly how much time widgets/gadgets use.

viewtopic.php?f=23&t=12303

[Argh]

Um, I'm totally unqualified to argue the deep numbers, but this is what I see every day, in practical testing of a fairly mature project:

1. Soundcode, pre 0.7.9, is a significant CPU hit. It should be significantly reduced when games are taking advantage of the new soundcode.

2. The map rendering system is a massive CPU-sucking object, largely because of issues I've already pointed out.

3. The pathfinder can occasionally cause big loads. Nothing can be done about this, it's pretty well optimized already.

4. BOS can create huge loads if poorly optimized. Seriously. Optimize your BOS, save many cycles. And don't do fancy math in BOS if you have any alternatives.

5. Lua is usually only a significant source of CPU load if:

A. You write poorly-optimized code. Especially regarding table searches. I'm guilty of this a lot.
B. You're using large numbers of spherical searches. Spring's spherical-search algorithm is very fast, but this is still very expensive. However, you have to do that quite a lot for many things.
C. You're doing stuff that would be very slow in any language. Then Lua's relative slowness is a big issue.

In general, I think that Lua's rapid development and ability to fire it up and test right away far outweighs its lack of raw speed. Well-optimized Lua isn't as fast as well-optimized C++, but you're more likely to get there with Lua, because you're not waiting for the entire engine to compile.

Perhaps in the future, DLLs will be a better route, but I really doubt it, tbh.

[SpliFF]

B. You're using large numbers of spherical searches. Spring's spherical-search algorithm is very fast, but this is still very expensive. However, you have to do that quite a lot for many things.

Since the entire search runs in C this would only be a lua issue if the bottleneck was returning the results (which I doubt). I realise that you probably realise that, but the point needs clarification. This is _not_ a lua issue and moving to C++ wouldn't solve it.

On an OT note, Supreme Commander has a much better way of doing these searches. You pass in a category filter like so:

Code: Select all

GetUnitsInCircle( pos, radius, (categories.COMMAND*categories.ENGINEER) + categories.AIR )

This will give you every unit that is either a commander with build capabilities -OR- an air unit within the specified area. This saves the inefficient step of retrieving all units and running filters against the larger set from a lua loop.

Spring is capable of implementing something like this from within C but the required functions haven't been written. It can filter by teamID but that's it. I've put in a feature request before but if it doesn't happen I'll get around to it sometime.

[IllvilJa]

A few random points:

Regarding "convenience".

In order to successfully develop software (especially open source software in one's spare time) it is important according to some sources that the obstacles/thresholds/difficulties that the developer(s) have to overcome are low rather than few. That is, a strategy/programming language/etc that result in the need for resolving a huge number of quite "conveniently" solved issues will most likely be more successful than a strategy/language/etc that result in a few (or even ONE) problem that is hard to solve. Actually, the presence of one high threshold to overcome among many low thresholds might be enough to completely kill a project.

So convenience is not about being lazy, stupid or shortsighted. It is a matter of doing what is necessary to get forward progress (or even creating the software in it's first instance) at all! Especially as many people who develop these things have real lives going on with work, family etc, the development process must be "convenient".

Premature optimization, no matter how ambitious intents it has, might very easily introduce such high level thresholds into the project, making the development process less fluid to the point the project halts. I've seen it happen, I know from my own experience as a software developer that high level obstacles are dangerous for a projects success. Extreme programming does have a point when they claim that one should start with something ridiculously simple to get something that actually runs and then continue in small increments.

Many programming languages are more suitable for that model than C/C++, at least in initial development. Later on in the development process, C and C++ (or even assembler) can be used to speed up critical parts. The network monitoring application MRTG were originally written in perl (otherwise it would probably never been a reality in the first place) but were fully functional. Then someone took time to reimplement the CPU intensive parts (storing data on disk and generating PNG graphs) and put them into a small piece of C-code, speeding up the performance by a factor of ca 100. The bulk of MRTG is still Perl code and the cost in "inconvenience" of turning that code into C or C++ does not warrant the performance gain of a conversion into C/C++.

So don't look down on "convenience choices". They often helps the project to survive in the first place.

Another aspect of Lua which makes me absolutely love it (and reject Perl, Javascript and also Python no matter how cool the latter is...): it can run sandboxed (which native C/C++ absolutely can not). I can download a Spring mod including Lua code, let that code run and I don't need to worry about the intents of that code. If it is well behaved and let's the mod run nicely, excellent, then it does so. If it tries to crash my machine (or Spring itself) or behave bad in other ways the Lua interpreter in Spring will, basically, say "screw you" to that malicious piece of Lua and either ignore it's request to format the harddrive or halt the execution of the script right there.

If I had compiled C/C++ code as part of that Spring mod and that code were malicious, then by far more damage can be made to my Spring session, to my home directory and perhaps to the system as a whole.

Sure, Lua is slower than C and C++ and I am one of those who "suffer" from that as I run Spring on a laptop which really cannot cope with the Spring44 mod (toooo many infantry men being spammed to keep track of, poor laptop). Still I'm very glad to see that the new C.R.A.I.G AI included in the latest Spring44 seem to be written in Lua. Why would that make me happy, who run on an already underpowered machine, to have an AI which has a performance penalty?

First, I do get an AI that works at all (works in the sense that it is capable of very clearly in the form of infantry and vehicles send the message "fuck off" to me as a human player and swiftly eliminate me from the game). If the developers decided to create the thing in C/C++ I'm not certain that the AI would have been as competent or if it had been available at all!

Second, I can read the Lua code myself and let my ignorant, impatient fingers mess around with it juslt like that without the need to setup any C/C++ development environment. Sure, I run Linux and thus got that environment "for free" but most people run windows and for them (and their impatient fingers) an AI written in Lua is a big win when it comes to access to "play around" with sensitive parts. Many disasters might follow, but such work might also lead to actual development and patches to the C.R.A.I.G devs.

So at the end of the day, I get an AI in Spring44 which I actually can use, provided I figure out how to limit the number of units in the game so I keep it low enough for the Lua AI as well as the rest of the game to run nicely. And to be honest, I really don't know how much CPU hit this AI has due to it being written in Lua. In any case I think it's increased portability and distribution convenience for that AI might warrant that CPU hit.

Ok, enough ranting (another damn long post from me...).

So, computerquip, take a deep breath. I understand your ambition, we all do, but we do see that there are a number of pitfalls with your ambition to do premature optimization (by warning us for the performance dangers of Lua) and we try to point those pitfalls out. Sometimes the tone in the discussion is somewhat harsh, which is unfortunate (and one reply you got were unecessarily rude I think) but I have to admit I think you contributed as well to the harshness...

But nevermind, you said you wanted to learn. You have a great opportunity, which does not mean that I think you are ignorant but I think you have a number of people here who actually are trying to help you and who are patient enough to explain things to you and not just dismiss you as "incompetent lamer" and other insults (like I've seen in some other forums). Sure, some people are annoyed, but they still try to be constructively educating. (Yes, really.)

Take that opportunity!

Best regards

/IllvilJa

[Auswaschbar]

I can write fast code in Lua, and I can write slow code in Lua.
Just like I can write fast code in C++, or slow code in C++.

So what?

[computerquip]

I can write fast code in Lua, and I can write slow code in Lua.
Just like I can write fast code in C++, or slow code in C++.

So what?

You missed the point completely. The point of it is that in some cases, slow code cannot be avoided in Lua. Or that was the original argument.

[lurker]

The early posts suggest that this is a common case. But I can't think of any cases in regular use.

[KDR_11k]

B. You're using large numbers of spherical searches. Spring's spherical-search algorithm is very fast, but this is still very expensive. However, you have to do that quite a lot for many things.

Note that this means LARGE numbers. The areadenial.lua damage code runs every frame and from what I've seen doesn't cause slowdown in KP or Fibre.

[Argh]

I agree, it has to be really large numbers. A few in a frame is no biggie.

We see a lot of hits when it's dozens and dozens (and it certainly hits that threshold with P.U.R.E. occasionally- I'm seriously considering consolidating all of it down to one big search posted to a globalized table, for unsynced stuff.