Experimental MacRuby Branch Is 3x Faster

An anonymous reader writes "Zen and the Art of Programming published an article about MacRuby's new experimental 0.5 branch (project blog entry here). According to the included benchmarks, Apple's version of Ruby could already, at this early stage of its development, be about three times as fast as the fastest Ruby implementation available elsewhere."

Comments

LLVM strikes again.

[jcr]

This is great news. The work that Apple's doing on LLVM is a renaissance in compilers.

-jcr

Re:LLVM strikes again.

[samkass]

Of course, the results don't exactly show a "3x speedup"... they show between a 0.08x speedup and a 7.8x speedup, with a high variability. Which is really great for such an early build, but it's not an instant panacea for everything.

Re:LLVM strikes again.

[TheRealMindChild]

You know. It was bad enough when we had multitudes of acronym collisions with 3-letter acronyms... but did anyone else associate LLVM with Linux Logical Volume Manager?

*sigh*

Nitro AKA Squirrelfish

[stefaanh]

I wonder if this has any connection to what they learned creating the optimized javascript "interpreter" they made for their next generation rendering engine Webkit.

Re:The questions remains...

[wrook]

I agree with this totally. These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X). In fact, this speed issue is such a big red herring for me. I hardly ever have any issues with speed. Instead I spend most of my optimization time trying to cut down on memory usage.

For me, even an order of magnitude difference in speed (i.e., 10X) isn't going to mean too much. There are certainly places where I'd like my code to be faster, but they are very, very small places. I can easily code them in C if I have to (C/Ruby bindings are *very* easy to write). But honestly, I've never gotten to the point where a speed improvement is more important than a functionality improvement. Every program is different, of course. So not every problem is suited to Ruby.

Re:true, but seems unnecessary

[Cyberax]

LISP compilers are not magical. They just try to:
1) Infere types and then compile typed code.
2) Do inlined threaded interpreter for everything else.

I.e. if you want fast LISP code - you have to write it like you would write it in C/Java/C++/another_static_language.

Re:true, but seems unnecessary

[Trepidity]

It scores pretty well even if you don't turn them off, because the good compilers (mainly CMUCL/SBCL) have type inference that can determine at compile time a large subset of the cases where it's safe to elide the runtime checks.

GCC avoids high level interprocedural optimization

[Pinky's Brain]

Because they don't want to expose high level intermediary code (too easy to hijack part of the compiler into a closed source project). Or at least that was one of the reasons LLVM was rejected for next generation GCC at the time.

They might have changed their mind now LLVM is bearing down on them ...

Re:Yeah , a true renaissance

[bonch]

The greatness of LLVM and Clang is that they replace the slow, rigid, crumbling GCC codebase. When the BSD-licensed Clang hits ready status, expect a massive switchover.

Re:Apple's work on LLVM

[jcr]

You may not want to believe it, but when GCC came out there was a pretty healthy competition going with plenty of vendors offering C compilers, and driving each other to improve their products. RMS decided to put them out of business, and the upshot was that commercial compiler development came to a screeching halt, with a few exceptions like IBM and Motorola working on their optimizers. There were a few scattered academic projects going on, but GCC wiped out everyone in the compiler business besides microsoft and metrowerks.

Fortunately, one of those academic projects came to Apple's attention, and it's about to bring the dark ages to an end.

-jcr