🔒 Locked

AngelScript x86 asm VirtualMachine

Started by Lioirc Oct 6, 2004 at 4:31 PM 16 replies 4.3k views

Original Post

Oct 6, 2004 at 4:31 PM

Hi here are some performance tests that i did today, i dont have real scripts to test it with, but i wanted to test it, so here they are This is with for(i=0; i<100; i++) (all TestFrameWork tests) ----------------------------------------------------------------- Timings at 10:09:57 Wednesday, October 06, 2004 ----------------------------------------------------------------- AngelScript X86 ASM Virtual Machine ----------------------------------------------------------------- ExecuteNext() took 12.35 milli secs (called 6,100 times) ExecuteNext() took 12.08 milli secs (called 6,100 times) ExecuteNext() took 12.23 milli secs (called 6,100 times) ----------------------------------------------------------------- Timings at 10:11:45 Wednesday, October 06, 2004 ----------------------------------------------------------------- AngelScript Normal Virtual Machine ----------------------------------------------------------------- ExecuteNext() took 37.14 milli secs (called 78,200 times) ExecuteNext() took 38.21 milli secs (called 78,200 times) ExecuteNext() took 38.74 milli secs (called 78,200 times) This is with for(i=0; i<100; i++) (all TestFrameWork tests and the testexecutescript in STEP_INTO ) ----------------------------------------------------------------- Timings at 10:34:55 Wednesday, October 06, 2004 ----------------------------------------------------------------- AngelScript X86 ASM Virtual Machine with STEP_INTO flag ----------------------------------------------------------------- ExecuteNext() took 136.43 milli secs (called 6,200 times) ExecuteNext() took 142.61 milli secs (called 6,200 times) ----------------------------------------------------------------- Timings at 10:31:31 Wednesday, October 06, 2004 ----------------------------------------------------------------- AngelScript Normal Virtual Machine with STEP_INTO flag ----------------------------------------------------------------- ExecuteNext() took 244.61 milli secs (called 83,600 times) ExecuteNext() took 236.91 milli secs (called 83,600 times) This is with in testexcutescipt for(i=0; i<1000; i++) { ctx->Prepare(main_function) ctx->Execute() // TestAsmVm.as } TestAsmVm.as script is int i; int n; void main() { i = 1; n = 1; o_stream(i, n); // output the values if(i == n) { i = 2; o_stream(i, n); } else { i = 3; o_stream(i, n); } if(i == 4) { i = 0; o_stream(i, n); } else { i = 1; o_stream(i, n); } } ----------------------------------------------------------------- Timings at 11:33:40 Wednesday, October 06, 2004 ----------------------------------------------------------------- AngelScript X86 ASM Virtual Machine ----------------------------------------------------------------- ExecuteNext() took 1.29 milli secs (called 1,002 times) ExecuteNext() took 1.29 milli secs (called 1,002 times) ExecuteNext() took 1.28 milli secs (called 1,002 times) ----------------------------------------------------------------- Timings at 11:31:45 Wednesday, October 06, 2004 ----------------------------------------------------------------- AngelScript Normal Virtual Machine ----------------------------------------------------------------- ExecuteNext() took 181.56 milli secs (called 54,011 times) ExecuteNext() took 116.85 milli secs (called 54,011 times) ExecuteNext() took 151.52 milli secs (called 54,011 times) look at this last test, this is more what i was expecting, and compare the times ExecuteNext() function is called, so you can add here the savings of the function call overhead, that was not included, as the performance was tested inside the ExecuteNext() function In the first test, thee are a performance gains of about 200% to 220% only, but keep in mind that most of the testframework tests are a single line script, but in the third performance where a more longer script is executed 1000 times in a row (a situation more like a real game, every frame) you see a big gain in speed The x86 asm vm is implemented in the as 1.8.2beta1, the plain vm was replaced with mine, no extra optimizations to the bytecode or the bytecode generator/compiler, that is why i expect the perfomance increase greatly impelmenting this X86 vm in the last AS, but this is hard as the library is currently in a state of high optimization from each release, and now focused on multithreating, and i dont want to focus on this as i expect to optimize the X86 vm a little more and gain like 10% more of speed, but i want to use the edi register to hold the bytecode_ptr, and in multhithreating this is not posible, if several scripts will run on parallel, on a single processor machine I think that will be better if WitchLord and i can sincronize this vm with the current release or wip, because updating it can be easier than trying to update to the last release, when releases are separated by a few days Best Regards, Lioric

WitchLord

Oct 6, 2004 at 5:47 PM

WOW! These are certainly impressive results. I look forward to seeing exactly how this was implemented. It will also be interesting to see how the performance changes for the other performance tests that I have.

What does it mean that you call ExecuteNext() only 6100 in the optimized version as opposed to 78200 times in the normal version? I understand that you are putting a loop inside ExecuteNext(), right? I hope you exit this loop at the right places, when the execution should be allowed to be suspended.

I will release version 1.10.0 WIP 1 today (I hope), but if you send me the code I will incorporate it in 1.10.0 WIP 2. I don't think it should be that difficult, as the VM doesn't really change that much between versions. I should be able to update your implementation with the new bytecodes. When I release 1.10.0 WIP 2 you can look over the code again to see if you can find more optimizations.

Lioirc

Oct 6, 2004 at 6:37 PM

Hi

The reason why ExecuteNext is called a few times is because i changed the way the vm works, that was a switch vm, and mine uses a reloc table that it creates in the first compilation time, and i dont see a reason why ExecuteNext have to be called for every code

The execution is allowed to be suspended in the normal way

Im not using loops in the ExecuteNext, its a big function with no loops, even the pop and push functions where removed

The library has to be compiled with the USE_ASM_VM define, and can be switched to the normal vm with the USE_NORMAL_VM, but the code compiled with any vm can be only executed with that vm

About script compilation, i like the idea of having a debug and a release script compile modes, a few bcodes extra for the debug compilation of scripts, like linenumbers ans so (but, linenumber is removed in the last release) and we can create a database with the local variables and the type (for interpretation and display) and the release version can be further optimized

Lioric

WitchLord

Oct 6, 2004 at 8:16 PM

I'm very curious to know how this implementation works. When can you send me the code?

I was planning on building the database with variable types for a future version. It's something that is needed to serialize script states, which is something I've decided to support in the future. Once that is complete it shouldn't be too much work to give the application the possibility to peek into the context stacks and even change it.

The line numbers has been removed from the bytecode but can be looked up when needed, which is done when you set an exception.

Gyrbo

Oct 7, 2004 at 10:09 AM

I was wondering how difficult it would be to make both versions bytecode compatible? I'm asking because storing the bytecode would be useless if it might be using a different (incompatible) VM to execute it.

What are the main differences in bytecode?

evolutional

Oct 7, 2004 at 10:37 AM

I'm really impressed by these results. Is the AsmVM hand crafted or JIT'd using something like Softwire? Good work Lioirc :)

WitchLord

Oct 7, 2004 at 10:47 AM

Gyrbo:

The bytecode that is saved with SaveByteCode() should be compatible with either VM. I don't know if Lioric's code already is, but if it isn't I will make the necessary changes to guarantee this.

Lioirc

Oct 7, 2004 at 4:09 PM

Hi

the saved compiled script is not compatible with the other vm, as the normal vm is bytecode based, but for performance i removed the bytecodes after the optimization phase in the x86 vm, it dont uses bytecodes anymore, but more like a normal execution where the pointer to the next instruction is updated (like the eid register), so i dont have to decode a bytecode and "switch" to the correct code
Because of this capability, i want to update my code to use the edi register to store the code_ptr (currently uses a DWORD*), but this is a problem in multithread if you want several scripts to run in parallel
I prefer to do optimizations for single thread, and a define that compile the library in multithread version where these optimizations can be disabled for thread safe

Now that you mention about compatibility, it wont work with a very modified library other than the library where the code was saved. This is not a problem for me, because i dont see where you will have problems with this, and if you update the library in your project, a recompile of the script will do the job (for example adding a silent function that tests the library version number or checksum and if is different than the compiled script version or checksum, recompile it or alert the user)

I havent see application projects where you periodically update a dll or library that is part of the application, most of the time you will update the main executable, because you will use a stable libraries before you release your project, and releases where the libraries need to be updated are major releases and the user need know that, because of this, old files have to be resaved or recompiled

The relocation table that stores the code locations is calculated on the first run, so modified libraries "might" give different code locations

Keep in mind that different vms gives you more options, performance or compatibility, it all depends on your needs,
for example if your compiler dont support asm, you can compile the normal but slower vm

@evolutional :
the virtual machine is not using any external library, it dont modify the AS in the terms that it keeps on being stack based (the next step is to make AS become a register based script)

@WitchLord:
Im sending the code right now

Lioric

WitchLord

Oct 7, 2004 at 5:56 PM

Lioric, it seems that you are basically doing a JIT compilation, in that you change the bytecode to use direct machine code instead of interpreting bytecodes. If that is so, it is exactly what I had in mind when thinking about the future implementation.

It's simple business making the bytecode saved compatible with the another instance of the same application. The library just have to keep the original bytecode and save that one. After loading a bytecode the same optimization process is run again.

Although I agree that singlethreaded applications are much easier to optimize for, I do need to make the library compatible with multiplethreaded applications. I would prefer not to disallow this excellent optimization for multithreaded applications.

I look forward to seeing your implementation and comparing the performance with version 1.9.2 using the same tests I did before.

Lioirc

Oct 7, 2004 at 6:37 PM

Hi

i tried sending the code but the mail server is not working here, i will try later when i have some more time (this weekend), but yes its easy to implement compatibility with the other vm, saving the code un-reloced (un-resolved) and before the execution it can resolve the symbols

and about the execution on different libraries or new versions, we can store the reolcations offsets (symbols) relative to the segments that they are, in this case the script can be run on any library version while the vm is not modified

Lioric

WitchLord

Oct 8, 2004 at 8:34 AM

Ok, I'll wait, though it will be difficult. I'm extremely curious to see your code. I'm almost jumping up and down like a child waiting for a present [wink].

I don't think we have to worry about compatibility between different versions of the library. It's enough that the original script code is compatible.

Lioirc

Oct 8, 2004 at 4:12 PM

Hi

WitchLord, yesterday the email server keept bouncing, so i will send you the code on monday, im not at my computers right now (for the weekend)

I want to know what are your design goals with this library,

speed (a must in the game area)
features
stability
ease of use
......

I searched on your web site and on the documentation, but there was nothing about it (or probably i missed it)

I need to know this to decide about my project

Lioric

WitchLord

Oct 8, 2004 at 5:06 PM

My goals are all of those. You can read the original goals here: http://www.angelcode.com/angelscript/goals.asp. They may have changed slightly during this last year, but they should be pretty accurate.

If I have to prioritize the goals it would be in the following order:

1. stability
2. ease-of-use
3. features
4. speed

Stability goes first, because a library that is not stable will not be used. Ease-of-use goes next, because it's in my nature to always think about how I can make things easier to use.

Features are important. The library will have all the necessary features that cannot be made an add-on. For example the library will never have a built-in xml parser because it could easily be made as a registered class, but the library will have native support for co-routines as this is not something that can easily be made externally.

Of these four speed is the least important. This is not to say that I won't make the library as fast as it can possibly be, it's just that if I have to choose between a necessary feature and speed I will choose the feature.

With your help I think the speed part at least should be mostly taken care of. I think only native code will be able to compete with the speed of AngelScript after you and I have finished optimizing the library. With your current changes I believe that AngelScript is very close to being the fastest scripting library around. (Does it show that I'm excited about the optimizations you made? [wink])

Did I give the right answer to win you over, i.e. will you use AngelScript in your project? [wink]

Regards,
Andreas

Rain Dog

Oct 9, 2004 at 1:42 AM

I am really excited about coming closer to being able to use Angel script in my program. I originally chose to use it because of its c syntax and ability ability to call application defined functions similar to the vbscript/jscript engine that the .NET framework so easily exposes.

One thing i have read is that the LuaInterpreter for the .NET framework bousts to be 3x as fast as the jscript engine, i did not look into it much but is the LUAI the same as the Lua that you have been testing against?

WitchLord

Oct 9, 2004 at 6:07 PM

Personally I haven't done any tests with any other scripting library. I suppose I should but I simply don't have the time to do so.

I'm aware that I might be called a liar for saying that AngelScript will be one of the fastest scripting libraries, but I only say what I believe. If someone shows to me that another scripting library is faster it will only make me work extra hard to make my library even faster. That is what spurred this latest optimization of AngelScript.

RCL told me that Lua was almost 2 times as fast as AngelScript. I knew that AngelScript could theoretically be faster than Lua so I set about optimizing it, and managed to make my library almost 2 times faster. Then RCL came back and told me that he had made a mistake and Lua actually wasn't so much faster as he had originally stated, it was more like 50% faster. Which was fortunate for me because it means that AngelScript should now be faster than Lua.

Of course with the new VM that Lioric has written for AngelScript, my library should be way faster than Lua is and might even compete with other scripting languages that have JIT compilation.

You say that you are coming closer to being able to use AngelScript in your project. May I ask what is keeping you from using it already?

Rain Dog

Oct 11, 2004 at 8:49 AM

What currently is keeping me from using AS in my program is that my program is not far enough developed for AS to be of use.

Lioirc

Oct 11, 2004 at 4:04 PM

Hi

WitchLord, im sending it right now

About the speed over features, a feature is of no use if its performance is making it nonusable, if angelscript is a game scripting library, probably speed of execution needs to be a little up in the goals list, but if AS would be a multiprupose library then its ok

The problem now with all the software is that people are saying that because of the power the computers have now, they dont need to worry about the speed of execution, and that is why now we need a 2.000+ MHZ cpus to run an advanced 3d game or an office application, the former doing ten thousand times the work of the second, or some web browsers now requires that high specs for html rendering

I tried to test all the bcodes but there are a few (2 or 3) that i didnt tested

Lioric

WitchLord

Oct 11, 2004 at 7:39 PM

Rain dog:

Well, that is certainly a valid reason not to use AS [wink]

Lioric:

I know what you mean. It's difficult to say what to prioritize in such a generic way. There are some features that are more important than speed, and others that are less important than speed.

If there is a feature that I want to add to the library that requires sacrificing a lot of speed I will make sure that it is made optional. That way each user can choose what to prioritize themselves.

I will run the VM through all of my test cases, and if there is any problem I'll try to fix it. If I need help fixing it I will contact you, ok?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.