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

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

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?

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

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

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