Slashdot Mirror
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."
Why MacRuby Matters (Present & Future)?
Apparently because an experimental incomplete version of Ruby is fast. Colour me unimpressed.
"LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time"
Amazing, truly unique ideas. If only someone had thought of doing this 30 years ago... oh wait...
Every time a story is posted about Ruby performance improvements, someone will post something along the lines of "x times faster than super ultra duper slow is still slow". Even if Ruby is 1000 times faster, there will still be people complaining. My guess is that none of these people actually use Ruby in production to be able to tell how much interpreter performance actually matters in the grand scheme of things.
Er, way to troll? If you'd like to do your ridiculous hello world you can stick to:
puts "i like beans"
And it's really unclear what "it" you're referring to. Because Ruby, for me, is a good blend of the things i wanted from Perl and Lisp with a side of Object Orientation. I get all the laziness and conveniences of Perl, and i can do all the crazy stuff i'd want to do with Lisp. So imo, you're way off base.
There are lives at stake here!
Any sort of layering is a major cause of bugs/slowdown? Quick, throw out TCP/IP. Everyone start using Ethernet frames directly from their apps, even if what you really want to use is SOAP over HTTP over SSL over TCP over IP... I'm not sure how you will get your Ethernet frames past the first router, but I'm sure you will think of something. Damn layering just gets in the way!
These days I'm writing exclusively in Ruby and it is "fast enough" (even with 1.8.X).
I suspect that's because your website doesn't receive thousands of dynamic requests per second.
So, GCC is making what should be technical decisions on a political basis?
Good to know. That's one more reason to be glad when GCC fades away.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
... for them to get further along in completing it... it'll slow down.
The main effect of GCC for the last 20 years has been to suck all of the air out of the room for anyone else who wanted to develop compilers.
That is one of the most retarded statements I've ever read.
No. What the poster said is true. Also unfair, because GCC is a very useful tool, but it still had a bad influence as well. GCC is extremely useful and produces decent code as well, but it has effectively stifled a lot of C/C++ compiler research. And it seems to become slower with each release. I have a lot of code that was faster with 2.95 than with any 3.x release, and with 4.x it is even slower.
Now, LLVM is still a mixed bag, sometimes code is much faster, sometimes a bit slower, and does not compile everything I throw at it, but it is impressive technology. It has a more modern infrastructure, and finally allows things like compiling to bytecode and dynamic run-time optimisation with C. It may even allow for CPU-independent operating systems in the future, where you have LLVM bytecode in the binaries that will run like natively-compiled code once loaded.
I compiled some C programs _to_ LLVM bytecode and then ran them on my mac.
Their performance was comparable, oftentimes better, than that of the same programs compiled with a recent GCC. And I can still add inline assembler, which then is used only on the right architecture, if I provide C alternatives.
Think about this. This has the potential of *finally* freeing us from dependence on a CPU ISA. It may be an Apple-sponsored project, but we all should be grateful to them that they are actually pushing it.
Roberto