AngelScript performance

RCL · 2004-09-05T09:13:33

Hi I've tested AngelScript performance against Lua. My synthetic test consists of pretty long loop (to make differences noticeable) with calls to various functions (both script ones and exported from C++), and some (rather simple) math calculations. This is what we need the in-game script for - mostly for calling exported functions, all the time-consuming tasks are done from within C++ code. And sorry to say, AngelScript is nearly 2.35 times slower than Lua. I really like AngelScript (because of its syntax and comfort at exporting functions - I hate Luabind and ToLua :)), so I decided to investigate the problem. The most time-consuming (according to profiler) function is asCContext::ExecuteNext() (no surprise here). Changing 'bcSize[ BC_* ]' to enumerated constants ('Sizeof_BC_*') when incrementing programCounter, and using temporary variables instead of class members helped me to get rid of some dereferencing and made the function more compact in memory. However, the performance gain was insufficient (AngelScript remained 2.10 times slower than Lua). I would say that BC_CALL opcode is not a 'light-weight' one, making code with a lot of function calls slow. Perhaps some further 'low-level' optimization (like making opcodes to be ints, not bytes, because ints ARE faster) could help (a bit), but I don't think that problem can be solved by this. I believe that the main reason why AngelScript is slower is that Lua bytecode consists of less opcodes, which are of higher level than those of AngelScript (for example, Lua has special opcodes for 'FOR' iterations, OP_FORLOOP/OP_TFORLOOP). It is a hard decision to choose between Lua and AngelScript. Performance IS important for games, so it would be really great if you managed to optimize AngelScript to make it at least on par with Lua. P.S. And yes, it would be also great if you supported [at least single :)] inheritance when registering object types, too :-)

AngelCode Affiliates

Started by RCL September 03, 2004 02:39 AM

13 comments, last by WitchLord 19 years, 7 months ago

RCL

123

Author

September 04, 2004 03:34 AM

Quote:Original post by abrken
I don't know what you're meaning when your saying *safely*

I meant situation like this:

Say, I have two (C++) classes, CChild and CParent, CChild : public CParent, which are exported to Angel Script (as unrelated types, alas).

Suppose I have an instance of CChild (in AngelScript) and I want to call a function which takes CParent &. How do I cast CChild to CParent?

To illustrate this:

void SomeFunc( CParent & p );...CChild c;SomeFunc( c ); // fails to compile - unrelated typesSomeFunc( (CParent &) c ); // fails to compile - expected expression value

Right now it seems like no such typecast is possible in AngelScript.

abrken

130

September 04, 2004 08:18 AM

Ok, I see now what your meaning by *safely* cast.

In such situation you've got two choices :
1/ Wait for AngelScript to have inheritance.
2/ Provide some extra code with the algo I have explained and change a little your script function.

bool RegisterObjectHierarchy(char *TypeParent, char *TypeChild)

should be changed to

bool RegisterObjectHierarchy(char *TypeParent, char *TypeChild, asUPtr funcPointerToCast)

funcPointerToCast is a C++ function that could be like this

CParent *castCChildToCCparent(CChild *p){  if p is kind of CParent    return (CParent*)p;   else    return NULL;}

in your RegisterObjectHierarchy you can then RegisterGlobalFunction with a preformated name ("%s_cast_%s", TypeChild, TypeParent) that point to the C++ cast function.

Next in your're script :
void SomeFunc( CParent *p );

CChild *c;

SomeFunc(CChild_casst_CParent(c));

This should work !

Of course, your're speaking about non pointer vars, so you can insert function dedicated to give a pointer in RegisterObjectHierarchy.

Does it sound good for you ?

WitchLord

4,834

September 04, 2004 01:22 PM

To add on what abrken said.

AngelScript doesn't have inheritance yet, which of course you already know. It also doesn't support any kind of typecasting for registered objects or pointers.

In your situation I would register a function that takes a pointer to CChild, and returns a pointer to CParent. Note that if the CChild has multiple inheritance then the actual value of the pointers are not guaranteed to be the same.

Object inheritance, and classes declared in the script is something that I'm delaying for a future version. Perhaps 2.x. There are many other things that I want to implement first, like arrays, exception handling, data structures, etc.

To go back to the subject of performance in AngelScript.

I've done some experimenting and believe I have figured out a way to improve performance with at least 30%. Still doesn't make it as fast as Lua, but at least it will be closer. I'll put some effort in making these performance improvements already for version 1.9.1.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

RCL

123

Author

September 05, 2004 08:58 AM

Quote:Original post by WitchLord
To add on what abrken said.

AngelScript doesn't have inheritance yet, which of course you already know. It also doesn't support any kind of typecasting for registered objects or pointers.

In your situation I would register a function that takes a pointer to CChild, and returns a pointer to CParent. Note that if the CChild has multiple inheritance then the actual value of the pointers are not guaranteed to be the same.

Object inheritance, and classes declared in the script is something that I'm delaying for a future version. Perhaps 2.x. There are many other things that I want to implement first, like arrays, exception handling, data structures, etc.

Well, I already considered using such functions, but it seemed like inconvenient and somewhat slow (additional calls) solution to me.

However, bigger issue here is inconvenience. I want to automate binding to AS by wrapping Register*() calls with macros (I know about AngelScriptBind, but I dislike the idea of maintaining separate *.pkg files), and things get more complicated with 'casting' functions. Nevertheless, I admit those can solve the problem, although in somewhat clumsy way.

By the way, in my humble opinion, arrays won't be as useful as class hierarchy would (especially considering the fact that arrays can already be simulated by operator[], which is sufficient in most cases) :)

Quote:Original post by WitchLord
To go back to the subject of performance in AngelScript.

I've done some experimenting and believe I have figured out a way to improve performance with at least 30%. Still doesn't make it as fast as Lua, but at least it will be closer. I'll put some effort in making these performance improvements already for version 1.9.1.

That's a good news. I believe that AngelScript should actually work *faster* than Lua, for it is not dynamically-typed, has no garbage collection, does not need wrappers for calling C++ funcs etc etc :-)

Cheers,
RCL

WitchLord

4,834

September 05, 2004 09:13 AM

All I can say is that I will investigate inheritance for a future version, but I can't guarantee anything. I recognize the need for automatic binding and I can assure you that I will do what's possible to support it.

I agree with you that AngelScript should theoretically be faster than Lua, but it seems that I'm far from there. I'll have to take a look at the source for Lua to see what they do to make it so fast. Maybe then I can get some further ideas for optimizations. But most likely it is that they are using specialized bytecodes to join many instructions in one.

AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game

AngelScript performance

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

AngelScript performance

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines