🔒 Locked

JITed Scripting

Started by Catafriggm Oct 9, 2005 at 3:59 PM 3 replies 700+ views

Original Post

Oct 9, 2005 at 3:59 PM

So, I'm interested in adding generic scripting support to my personal class library to potentially be used in just about anything. My main priorities are speed, ease of use/integration, power/versatility of the scripting language, portability, and popularity of the language. Based on these factors, the two best candidates to me sound like Java and C#. Both are JITed languages, and so are extremely fast (when I benchmarked them a year or two ago, C# was 2/3 as fast as native code, and Java 1/2 as fast, both which are absolutely uncomparable to the performance of interpreted languages). Both are also well known languages, as well as being powerful. It's not difficult to write code in either language that's portable just about anywhere (if perhaps using a limited set of the RTL functions), especially in the application of a scripting language. What I'm less familiar with is interfacing the languages with native code (both calling C#/Java code from native code, and the reverse), and the portability/ease of use of the compilers. For a scripting language, the compiler/JIT would have to run on the host machine, compiling the scripts on startup (and perhaps caching them between executions) programmatically. Since I'm writing a very generic class library (intented to run on Windows 9x, NT, and POSIX), I need the compiler to be just as versatile. One key question is whether the C# compiler in included in Rotor (the shared source implementation) or Mono. Another question is whether there's a programmatic interface to the compilers of either language. Also, I need to know how easy (and fast) it is to interface native and JITed code, as well as provide a custom RTL which contains both a limited set of the usual RTL and any functions the scripting host may want to provide. Does anyone have the answers to these or related questions on the topic? I could do the research myself, but it's always easier to ask somebody who already knows (if such a person exists) :P

Catafriggm

Author

Catafriggm

Oct 10, 2005 at 2:09 PM

Also, does anyone know if there is any way to programmatically access Sun's Java compiler (not the VM)? I know you can with C#, but I don't see how with Java.

ZQJ

Oct 10, 2005 at 2:13 PM

The Java-C interface is called JNI. I seem to remember the interface itself isn't very quick though, but that shouldn't be a problem unless you're doing a lot of switching into/out of Java.

As for your C# is 2/3 as fast and Java 1/2 as fast comments, a lot of people will tell you they're both faster than C. I don't believe 'em yet (although I do believe it depends what you're doing, and what you mean by fast).

Catafriggm

Author

Catafriggm

Oct 10, 2005 at 2:22 PM

Since I made the original post, I did some research on Java (as nobody else knew the answer...) and I benchmarked calls from Java to native code as taking 450 cycles, and calls from native code to Java as taking 3200 cycles. Both of those had no parameters to marshall, so there wasn't any time consumed by that.

Those benchmarks I mentioned consisted of compressing a large file (like 10 megs) with ZLib. The native code version was the version off the ZLib home page; the .NET version was the exact same code compiled as managed; and the Java version was a Java port of ZLib somebody did (was linked from the ZLib home page).

Name_Unknown

Oct 10, 2005 at 6:04 PM

Quote:
Original post by Catafriggm
Since I made the original post, I did some research on Java (as nobody else knew the answer...) and I benchmarked calls from Java to native code as taking 450 cycles, and calls from native code to Java as taking 3200 cycles. Both of those had no parameters to marshall, so there wasn't any time consumed by that.

Those benchmarks I mentioned consisted of compressing a large file (like 10 megs) with ZLib. The native code version was the version off the ZLib home page; the .NET version was the exact same code compiled as managed; and the Java version was a Java port of ZLib somebody did (was linked from the ZLib home page).

I wouldn't get too hung up on the cycles bit really. If you are using graphics (opengl, direct3d) most of your cycles get burned anyways in the cruddy device drivers anyways as I have seen. If you are doing network oriented code, most of your time is spend waiting anyways. Java and C# are really fast enough for almost everything on modern machines. Most machines these days are very fast and very few gamers will be trying to play Quake 4 on a pentium 200...

I don't find it really useful most of the time to worry about optimizations except in the core math kernels and a few things here and there which get called very often. Most of the optimizations I do find useful are common sense things and exploiting the cache effectively on a higher level ( and memory layout ). A good memory manager goes a long way too.

Topic Locked

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