Macruby versus MRI 1.9

ruby-talk
1

I was wondering what the differences between these two releases are. I was
looking over the code and it does seem that macruby is sort of a fork of the
MRI 1.9 release. Is this correct?

Regards,

Carter.

2

I was wondering what the differences between these two releases are. I was
looking over the code and it does seem that macruby is sort of a fork of the
MRI 1.9 release. Is this correct?

The MacRuby homepage ( http://www.macruby.org/ ) explains it pretty well imho. In essence it lets Ruby run on the Mac OSX Objective C runtime (GC, etc) and lets it access the various frameworks it exposes (Cocoa). In essence you can use it to write OSX apps without resorting to cross platform gui solutions like QT or wxWindows. Theoretically you could probably do it using MRI and C extensions but that's kind of painful.

- Chris
Twitter @cwgem

3

Thank Chris. I was actually more interested in this from an internals
perspective. I was wondering how effective LLVM is as a JIT system and
whether there are/were any large source changes.

···

On Sun, Oct 23, 2011 at 1:18 AM, Chris White <cwprogram@live.com> wrote:

> I was wondering what the differences between these two releases are. I
was
> looking over the code and it does seem that macruby is sort of a fork of
the
> MRI 1.9 release. Is this correct?

The MacRuby homepage ( http://www.macruby.org/ ) explains it pretty well
imho. In essence it lets Ruby run on the Mac OSX Objective C runtime (GC,
etc) and lets it access the various frameworks it exposes (Cocoa). In
essence you can use it to write OSX apps without resorting to cross platform
gui solutions like QT or wxWindows. Theoretically you could probably do it
using MRI and C extensions but that's kind of painful.

- Chris
Twitter @cwgem

4

Thank Chris. I was actually more interested in this from an internals
perspective. I was wondering how effective LLVM is as a JIT system and
whether there are/were any large source changes.

Ah, then I would recommend checking with the macruby-devel mailing list instead ( http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ). I'm not sure how many macruby folks hang out on ruby-talk (maybe ruby-core if anything).

- Chris ( @cwgem )

5

You should talk to the Rubinius people too, as they're also llvm +
jit. It's entirely re-written, no MRI code (unless you consider the
standard library MRI)

6

Thanks Chris. I figure I would just run some diffs- I am looking for some
detailed performance comparisons- though I probably should sign up for the
list as well :-).

···

On Mon, Oct 24, 2011 at 5:19 AM, Chris White <cwprogram@live.com> wrote:

> Thank Chris. I was actually more interested in this from an internals
> perspective. I was wondering how effective LLVM is as a JIT system and
> whether there are/were any large source changes.

Ah, then I would recommend checking with the macruby-devel mailing list
instead ( http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel\). I'm not sure how many macruby folks hang out on ruby-talk (maybe
ruby-core if anything).

- Chris ( @cwgem )

7

I guess the question for me stems from two sources-

1) how effective is MRI performance wise compared to MacRuby and Rubinius or
JRuby etc?

2) if there are any performance "benefits" how much does the JIT system
contribute?

3) How effective is LLVM as this JIT?

For example I did read some posts and had similar ideas along the lines of
how Chamber's Self thesis or more recent techniques trace trees (which
aren't really that recent since dynamic compilation in Dynamo has been
around for some time and there are probably other variants too try in this
area) could be applied to make Ruby "faster". I don't think either rbx or
macruby employ these techniques at present. Or variants thereof.

···

On Mon, Oct 24, 2011 at 6:16 AM, Steve Klabnik <steve@steveklabnik.com>wrote:

You should talk to the Rubinius people too, as they're also llvm +
jit. It's entirely re-written, no MRI code (unless you consider the
standard library MRI)