Jump to content
  • Advertisement
Sign in to follow this  

How to implement jit? Addition : or do you need one?

This topic is 4802 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi! We are currently working on interpreting clr runtime for "only" embedding use, and I'm really interested how JIT can/could be implemented. I know something how it works (either combining whole thing to native code or replacing some parts of the code with native code?), but I don't have any clue how it can be implemented. I read somewhere that there isn't so much trouble implementing JIT as it first may seem, but I've searched the web without finding any good articles/books that actually explain this. I've checked the ms rotor source for finding the answer but no luck (it's a pain reading someone else's code really :). --- sandelz [Edited by - sandelz on March 25, 2005 6:02:39 PM]

Share this post


Link to post
Share on other sites
Advertisement
First, you require some way to generate machine code in a buffer and to be able to call into it and get back. That is the hard part. There are free libraries around that can do that on Intel.

Once you have that, than it's real easy to implement a stack machine on it. Literally translate the stack machine into assembler. push, push, pop, op, push... The resulting code is horribly inefficient but it is still much faster than an interpreter.

Share this post


Link to post
Share on other sites
You could look into using Softwire for 8x6 machines. Someone that used to frequent these forums was working on a JIT script system called 'Cull', it doesn't appear that he's still working on it but you can find the sources here.

Share this post


Link to post
Share on other sites
Hi!

Thanks for the answers.
I did look softwire's code and got little more understanding how it is done, the code generator part is the hard part though :)
Don't really know how to generate native binary on the fly, BUT hope that softwire helps with this. :)

Share this post


Link to post
Share on other sites
I did a little research and came to think that implementing JIT is kinda hard and it does cost much (meaning portability and safety of vm).

So new queston :

Do you really need jit for speed when creating only logic with scripting language?
We plan to make class libraries in pure c/c++ which does the "hard work", and every logic related stuff in clr.
Can you make interpreter/vm so fast that implementing jit becomes non-important/useless?

Share this post


Link to post
Share on other sites
The Lua 5 interpreter is known to be pretty fast as far as interpreted languages go. The speed hit for running a roughly equivalent algorithm in Lua vs C is reportedly about 10-20X -which is quite favorable to the 20-40X hit for many popular interpreted languages (Python, Unreal Script, etc...). SmallC (aka 'Small') is smaller, simpler and less flexible than Lua. So I would expect it to be even faster.

Lua 5 incorporates many key designs that are necessary for fast interpretation:
1) Always compile to bytecode before execution to avoid continous parsing
2) Register-based VM avoids the bloat of stack manipulation between each operation
3) Lightweight native function interface makes transitioning between C and script functions reasonably cheap
4) Simple, small interpreter stays in the CPU's instruction cache

Given a common 90:10 performance ratio (90% of the time spent in 10% of the code) you could theoretically replace the other 90% of your code with Lua and only suffer a 50% speed hit.

It is even possible to get a speed increase over C using a scripting language in some situations. If your language is highly tailored to a specific problem it can be designed to make it easy for the programmer to use efficient algorithms that are difficult to express in C. An example would be Mathmatica. Under the hood, the scripts written in Mathematica call C functions that are highly optimized. The scripting interface makes it very easy for the script writer to call these highly optimized routines and the end result is code that runs faster in practice because it so easy to do so. Even though in theory it would be possible to run slightly faster using only pure C, in practice that would likely result in slower code because it would be so much harder to use the C interfaces optimally that they would frequently be used non-optimally.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!