From: Wayne Kelly Date: 2006-06-21T10:38:06+09:00 Subject: Re: Announcing Beta Release of GP Ruby.NET Compiler At 01:08 AM 21/06/2006, you wrote:

On Tue, 2006-06-20 at 14:08 +0900, Wayne Kelly wrote:
> Complete source code of our system can be downloaded from:
> http://plas.fit.qut.edu.au/Ruby.NET

The download page gives an ASP error message.

And what error is that? (I don't get any errors)

> Please note, that we have so far made no attempt to optimize the performance
> of our system or to provide any support for interoperability with .NET
> programs written in other languages. We have chosen instead to initially
> focus on the challenging task of achieving complete semantic compatibility
> with the standard Ruby interpreter. Once this is achieved we will move on to
> those other challenges.

Even though you have said that, I am salivating a little. Okay, really,
a lot. If I understand your project page description of your approach
correctly, in theory, your approach would out-perform YARV by quite a
bit in most test cases because it's compiled. Can you tell us how much
overhead is added by having to send all method calls through your custom
call dispatcher?

It does basically what the Ruby interpreter does ...
It needs to work out the Ruby class of the receiver object and search
for the method (by ID) in the method table of that class. If it can't
find it there it needs to search in sub-classes (and mix-ins).
The Ruby interpreter optimises this slightly by caching the methods
that have been called previously, but it still needs to do at least this
one cache lookup. We haven't yet implemented such a caching mechanism
but we will do so.
On locating the method it needs to check if it can be legally accessed
(public, private or protected).

If it's not much then the benchmarks should come out a
little slower than C# execution speeds ... which would just be amazing.

I wouldn't be so confident.

Obviously, the load-compile-run is going to be slower than in Ruby 1.8,

Not necessarily, once the load-compile step is out of the way,
we are executing native JIT compiled code rather than the interpreting
that Ruby 1.8 is doing.

I know you haven't focused on performance yet but if you could just
comment on what you believe the performance "ceiling" is ...

I suspect some programs will run faster compiled to Managed .NET code
and some will run faster interpreted with the native C interpreter.

I noticed, also, that you are funded by Microsoft and, as such, I'm sure
you're not very keen on Mono, but, I am curious, have you tried
compiling this on Mono's GMCS (their DotNet 2.0 compiler)?

We don't have any issues with Mono. I haven't had the chance to try
our compiler on Mono but I'd be really interested to know if it works.
And if not, if there's anything we need to change. We're more than
happy to cooperate with any such efforts.

Cheers, Wayne.

Dr Wayne Kelly                    Senior Lecturer
Email: w.kelly@qut.edu.au                 School of Software Engineering and DC
Phone: +61 7 3864 9336           Faculty of Information Technology
Fax: +61 7 3864 9390             Queensland University of Technology