Not so long ago Richard Dale announced Korundum, a RAD environment for KDE. And we should not forgetting Kommander and the official Qt Designer. It seems that KDE/Qt have more than enough RAD tools around. Now another KDE developer has announced Rubydiam, his efforts to bring JIT optimization to Ruby. The results could well be a competing runtime for Free Software development.
Rubydiam JIT in Development
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
24 Comments
2004-09-29 6:33 pm
He might as well write a RubyToIL compiler while he’s at it…if it hasn’t been done yet.
I dunno. .NET is not a great platform for dynamic languages. In particular, I don’t see how you’d do dynamic type inference within the CLR framework. I know about IronPython, but apprently, it’s only twice as fast as regular Python, which isn’t very impressive. In contrast, the virtual machine for the Self language (which has even more flexible semantics than Ruby) can get to 50% the performance of C.
Oh well..
…KRAD
I dunno. .NET is not a great platform for dynamic languages. In particular, I don’t see how you’d do dynamic type inference within the CLR framework.
Yes, ruby’s closures and continuations are too dynamic to implement in the current CLR. Hopefully the Iron Python guy will be able to help ‘iron out’ (tee hee) that sort of problem.
Uhmm, .NET will typically run much better than 50% of C. Look at the axiomengine.sourceforge.net(written in C#) forums for benchmarks comparing it to the ogre3d.org engine which is written in C++ Axiom is the C# port of Ogre. Also, look at the benchmarks of QuakeII to IL. It has very good benchmarks too.
The IronPython guy has been hired by Microsoft and CLR version 2.0 and later versions should address some of these issues of dynamic languages. Why limit yourself to a limited virtual machine that runs Self, when there are IL compilers for C/C++, Python, VB, C#, Java, etc…and will run great on Windows, Linux, Mac, BSD, etc..
If IronPython is already running twice as fast as regular Python then that is a great start considering that it was a one-man show doing IronPython and now he’s been hired by Microsoft, has all those resources behind him, and actually make concrete contributions to the CLR that address those needs.
…KRAD
That’s too close to Krud for me
Uhmm, .NET will typically run much better than 50% of C.
Yes, but that’s because the language the benchmarks were done in would have been just as fast as C anyway, with a native compiler. C# and Java don’t really add anything that would prevent them from being every bit as fast as C or C++.
This is not true, however, of highly dynamic languages like Ruby and Smalltalk. In order to get full performance out of them, you need some very advanced optimizations that you don’t need for static languages like Java and C#. In particular, stuff like closure elimination (for Ruby blocks), type inference, partial dispatch, partial specialization, etc. Even optimizations that could help C# and Java (eg: heap analysis), aren’t usually done in C# and Java, because those languages don’t allocate as much memory under the hood.
Don’t jump the gun on languages running on .Net faster. They usually aren’t 100% compatible with the native language. And that means that the libraries won’t be guaranteed to run flawlessly on an untested environment. I’m yet to see a successful implementation which is going to make people switch over from the native implementation.
Yes, those dynamic languages are going to be slower because of more runtime decisions, etc…but I don’t see why IronPython couldn’t be at least 80% of C# eventually. Hey, you’re the one always saying how fast Lisp is these days.
To me its all about the runtime. Of course there are tradeoffs in having a more generic runtime to handle a diverse set of languages, but with Microsoft’s resources, there track record with .NET so far and with Mono going at full speed I don’t doubt that CLR 2.0 and beyond will be about as close we get to the ideal, universal virtual machine.
Feel free to post some links to other promising virtual machines. I know about Parrot and its future isn’t looking so bright at the moment and Java’s virtual machine is much more limiting than .NET’s.
but I don’t see why IronPython couldn’t be at least 80% of C# eventually.
They could, but I think it would require substantial changes to the CLR. It is kinda hard to optimize the performance of a dynamic language when the underlying JIT has no idea of dynamic typing…
Hey, you’re the one always saying how fast Lisp is these days.
The fast Lisp compilers don’t use a JIT, but rather are native-code compilers. And they do a boat-load of compiler tricks that the CLR doesn’t do, because C# doesn’t need them.
I know about Parrot and its future isn’t looking so bright at the moment and Java’s virtual machine is much more limiting than .NET’s.
I haven’t heard of any problems about the future of Parrot. Ruby doesn’t use a virtual machine at present, it evaluates the Abstract Syntax Tree at runtime. The idea of Alex’s Rubydium JIT is to speed that up, so we don’t need a VM. Also the CLR is very batch oriented – you take a source file, compile it to VM instructions, put it somewhere complicated (the GAC), and then run it. Well, that really slows down development – it is so much nicer to just make a change to the ruby source and run it immediately. And then interact with it, and change it at runtime with the irb (Interactive Ruby) utility.
I’ve wondered for a while: what are the advantages of evaluating ASTs as opposed to VM bytecode? Are there downfalls too?
This is probably the first JIT built with libjit for a real language (everyone knows the dpas thing was for testing). Interestingly it is NOT for Portable.net
I’ll have a look at running it with libjit’s full JIT mode and see where it is breaking (if it does indeed).
Btw, ASTs and ByteCodes are different representations of the same thing. A JIT is a further simplification of the original . But of course a well done interpreter can be faster than a poorly done JIT (especially on platforms like IA-64 where parallelization makes good JITs very hard to write).
I didn’t know ruby evaluated an AST until Alex the Rubydium author, and QtRuby/Korundum co-author, told me, I’ve never even looked at the ruby runtime code. t3rmin4t0r looks like he knows more than I do – interesting that the same libjit is being used for Portable.net. BTW, the KDE kjs ECMAScript intepreter also evaluates an AST at runtime.
While on the subject, KDevelop’s code completion languages all involve evaluating an AST at runtime
… as I’m sure most code completion tools do.
Gopal, how far along is libjit when it comes to working on the CIL bytecode?
BTW, it is a misnomer to think of libjit in any way as a CLR runtime. It is an abstraction one pace higher than that. That is why it can be used to run other bytecode based (or AST at runtime based) languages.
Just a question. IronPython is reported to be “up to 1.7x faster than Python-2.3 on the standard pystone benchmark”. This is surely impressive relative to Jython. However, if I understand correctly, psycho gets a 4.9x improvement in the same benchmark, relative to Python-2.3.3 (see
http://psyco.sourceforge.net/psyco-pepm-l.ps.gz
for further details and other interesting benchmarks).
This is, in a sense, to be expected: IronPython “JIT”s Python to CIL, which is then JITted to x86 code (right?). Psycho JITs Python to x86 directly, and does a number of other clever things.
So I guess the question is why Jython seems to do worse than IronPython, but there is no issue that “going native” is still better than going CIL…
…or is this making any sense at all???
The Kino developers have been making v2.0 experiments and prototypes in Ruby with the GTK bindings. We love it! Glade and libglade with Ruby is quite RAD even if Glade can not represent your derived widgets. I like the Ruby signal connection in the GTK bindings better than I do in Qt, but that’s a rather minor point. I have played with a really neat visual IDE called Fox-Tool on Ruby for Windows. As you may have guessed, it uses the Fox toolkit. The cool thing about it is that there is no separate edit-execute dev cycle; you edit it while it is running! The editor runs in one window while the app runs in another. FreeRIDE and SciTE are Ruby IDEs with no visual designer. However, all of these environments as well as Kommander lack the killer feature of code completion aka Intellisense.
I’ve wondered for a while: what are the advantages of evaluating ASTs as opposed to VM bytecode? Are there downfalls too?
The upside of AST is that they are a direct result from the compilation, which makes for an easy compiler, and they also retain a lot of information about the program structure which can be used for JIT compilations or optimization.
The downside of ASTs are that the structures are scattered all over the place, so that the processor uses a lot of time just to find the next statement to execute. Also, the compact bytecode representation makes it easier to store the compiled program on disk to avoid recompilations.
actually, there is a guy wich wrote a proof of concept ruby2MSIL compiler , see here:
http://www.pronovomundo.com/htu/theses2004/
I like the Ruby signal connection in the GTK bindings better than I do in Qt, but that’s a rather minor point.
Yes it’s good able to connect a signal to a block. So it would be nice for a future QtRuby release to add that, and also I’d like to be able to not use C++ types in the slot declarations too and have Ruby types. The problem is that a ruby String could be either a C++ ‘char *’ or QString or QCString, and you need to be able to resolve that sort of ambiguity.
I have played with a really neat visual IDE called Fox-Tool on Ruby for Windows. As you may have guessed, it uses the Fox toolkit. The cool thing about it is that there is no separate edit-execute dev cycle; you edit it while it is running! The editor runs in one window while the app runs in another
QtRuby comes with a shell that allows you to create guis interactively. It’s a bit basic, but it would be a good starting point for something similar. I was very excited when Alex first translated the PerlQt version to ruby because it interprets the code line by line, and you just can’t do that sort of thing in a Qt C++ environment.
KDevelop has ruby syntax highlighting, ruby class parser and a basic Qt project template, but no ruby code completion. Perhaps the C++ code completion could be given a ‘ruby front end’. It has integrated Qt Designer support, but doesn’t invoke the rbuic tool to generate ruby code automatically, but I wouldn’t have thought that would be too difficult to implement – just a simple makefile to do that for a ruby project.
> Gopal, how far along is libjit when it comes to working on the CIL bytecode?
Fairly complete – we are having a few problems with the struct returns and monitor (lock/unlock) and a few stability issues.
The ILJITCoder is not in CVS yet, but almost all the peices needed are there – after all a JIT is an all or nothing game.
actually, there is a guy wich wrote a proof of concept ruby2MSIL compiler , see here: