JIT seems to be very fast

[KWo]

Eveyone who says that small language is too slow in executing (and because of this he doesn't like it), look at the results of some benchmarks made by Bailopan.
For more details - what exactly is JIT - ask T(+)rget or Bailopan.

http://www.tcwonline.org/~dvander/bench.htm

[@$3.1415rin]

I know that JIT can be fast, since that's why it's been introduced, anyway this benchmark doesnt tell me anything. I mean, why should Assembler be slower than JustInTime compiled stuff ? I mean, they have to do the same work, and for example floating point ops don't rely if it's native written ASM or called by some JIT code, the execution time is the same. Ok, if this benchmark wants to show that the JIT compiler is able to do optimizations, ok. but why dont you optimize the ASM code then ...

or is that interpreted asm ?

[Pierre-Marie Baty]

interpreted ASM ? I subsmell a good dose of irony here

[BAILOPAN]

AMX/Small bytecode is a block chunk of memory, split into one cell (4 or 8 bytes) per opcode and another for each parameter. Each opcode takes one parameter, except for debug opcodes which can take multiple parameters.

There are four ways of executing this bytecode.

Normal: Each cell is read and interpreted at face value. Jumps/calls are relative addresses, opcodes are interpreted through a huge case/switch table.

GCC/Linux: GCC has a label addressing feature, so beforehand all of the opcodes are browsed and relocated to be physical addresses of a big list of labels... this means opcode interpretation is direct instead of a switch statement, and gives about a double speed increase on Linux.

ASM: The assembly method is the GCC method, except opcode interpretation is in x86 assembly instead. The opcodes are physical address jumps into assembly procs that handle the parameters.

JIT: The JIT is something quite different. It pre-processes the bytecode and does AOT (ahead-of-time compilation):
1. Reads an opcode (say, PUSH.PRI)
2. Copies a few assembly instructions which perform this to garbage data.
3. Copies the opcode parameters over the garbage.
4. Finds the next opcode and goes back to 1.
5. When done, it has destroyed the original bytecode and replaced it with native x86-assembly.
It also relocates all jumps/switches/etc to physical addresses. Further execution is simply jumping into the code, rather than using amx_Exec()'s bytecode interpreter.

This means the JIT takes all of the AMX bytecode and outputs optimized assembly which accomplishes the same thing. And because it has NO interpreted jumps or opcode switched (unlike the others) it's lightning fast. It also ignores all debug opcodes when compiling for speed - on AMXx I wrote a feature where you can have it keep these so you can debug properly, but it's optional.

On my tests the JIT was usually 10-12 times faster than normal bytecode.

KWo asked me to clear this up, I hope it helps

[@$3.1415rin]

yes, ok, this is about the bytecode only. no comparision to how fast this would be if compiled using C/C++

[BAILOPAN]

I think you misinterpreted what I wrote. That IS the comparison:

Normal: AMX bytecode, C interpreter.
ASM: AMX bytecode, ASM interpreter.
JIT: x86 native code, CPU executes.

[@$3.1415rin]

yep, somehow I don't get it.

just pick the "Normal" case : the AMX bytecode is translated to C and then compiled and executed ? or is this C code then interpreted ? since you wrote "C interpreter" ...

why not compile the AMX bytecode to native machine code and then execute it ? why do you need JIT ? JIT is useful with java e.g. to have optimal performance on different systems, but if you just want it to run on some x86 compatible system, where is the advantage over compiled code ? Or should I think more about the Transmeta approach and codemorphing to archieve better performance from already compiled code ? the worst point in the benchmark is the math stuff I already pointed out. feeding the CPU using some native code should be the fastest way possible, since JIT is basically the same ... why should that be faster. but as I said, somehow I dont get it what's the categories in the benchmark about, even with your explanation, sorry

[BAILOPAN]

If you still don't get it at this point there's not much I can do for you ;]

Originally Posted by @$3.1415rin

just pick the "Normal" case : the AMX bytecode is translated to C and then compiled and executed ? or is this C code then interpreted ? since you wrote "C interpreter" ...

The bytecode is never translated to C. The bytecode is interpreted by an interpreter written in C (and none of this was written by me).

Originally Posted by @$3.1415rin

why not compile the AMX bytecode to native machine code and then execute it ? why do you need JIT ?

That is exactly what the JIT does. Technically, I said earlier you could make the distinction that AMX JIT is actually an AOT (Ahead of Time compiler) but I won't because the author calls it a JIT.

Java's JIT is supposedly an AOT as well... Microsoft's .NET has a true JIT wich compiles certain portions of bytecode on the fly, as it analyzes the code as its running and is able to make specific optimizations.

I may be wrong about Java, but there you have it.

[sfx1999]

I wonder how you would go about writing a JIT. I would love to make an emulator.

[Pierre-Marie Baty]

<TROLL>

Wouldn't it have been more straightforward, I would even say... more "common sense compliant", to write your plugins in trusty old C, or whatever C++ if you absolutely want it, and include a free C compiler (Watcom, Borland, Microsoft's command-line CL, or the other one there, GNU) that would compile them on the fly each time the server is started ?

It takes about 3 seconds to compile a medium-sized metamod plugin. Performance wise, it's unbeatable. And already debugged. You have nothing to worry for. Man...

</TROLL>