Experimental MacRuby Branch Is 3x Faster 191
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."
That's because it's spiked with assembly (Score:5, Funny)
I heard it made a guy in Michigan's head explode! That's why I stay away from the experimental stuff, man.
Painted red (Score:3, Funny)
Why MacRuby Matters? (Score:4, Insightful)
Why MacRuby Matters (Present & Future)?
Apparently because an experimental incomplete version of Ruby is fast. Colour me unimpressed.
Re:Why MacRuby Matters? (Score:4, Insightful)
MacRuby's potential for Cocoa integration is fantastic and great, and something i very very much want to see.
It's not clear however what relationship benchmarks at this stage (with an incomplete implementation) will actually correspond to in the future. They are a total red herring for discussion.
Look at MacRuby on the merits! not the benchmarks!
Re:Why MacRuby Matters? (Score:5, Funny)
Whenever I read posts like these I start to wonder if I accidentally walked into a Starbucks.
Re: (Score:2, Insightful)
Whenever I read posts like these I start to wonder if I accidentally walked into a Starbucks.
Yea, these Mac snobs need to get with the program. If they put half the effort they put into MacRuby into CocoOnPunchCards, perhaps the rest of us might take them a little more seriously.
Re: (Score:2, Funny)
This is slashdot. Benchmarks are all that matters.
Re: (Score:2)
Re:Why MacRuby Matters? (Score:4, Insightful)
I don't care much for Ruby myself. I'm a Python guy, but I don't give a frack what language people use.
"Least used scripting language"? Right, because nobody develops on Rails (like it or hate it).
Ever check the stats on Developers who use Macs (vs. the general populace)? Didn't think so.
And finally: that which makes MacRuby very very fast can also make Ruby on *nix very very fast.
The problem with Ruby is not the language. It is the VM. Improve the VM, and more people will look at other uses where Ruby is a great fit but for its speed.
Re: (Score:2)
In all seriousness, Ruby is probably used less than Python and PHP.
Re: (Score:2)
In all seriousness, Ruby is probably used less than Python and PHP.
But growing faster.
Re: (Score:2)
Well, if you ask me, I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C. I think Apple likes Ruby and its aesthetic. A lot of the Rails devs are Mac developers, and I think that's where it sparked.
Re:Why MacRuby Matters? (Score:4, Funny)
I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C.
Wouldn't that require Ruby being a first-class development language in the first place? ;)
Yeah, yeah, go on and mod me troll, I can handle it.
Re:Why MacRuby Matters? (Score:5, Funny)
Yeah, yeah, go on and mod me troll, I can handle it.
Alright then!
Wait a minute...
Shit.
Re:Why MacRuby Matters? (Score:5, Insightful)
Well, if you ask me, I suspect that someday in a future version of the Mac OS, Ruby will be a first-class language for application development alongside or perhaps replacing Objective-C. I think Apple likes Ruby and its aesthetic. A lot of the Rails devs are Mac developers, and I think that's where it sparked.
First Class, maybe. Replacing ObjC? You're prediction makes LSD trips seem dull.
Re: (Score:2)
Re:Why MacRuby Matters? (Score:4, Funny)
Re: (Score:2)
The latest Mac OS already has Ruby bindings for Cocoa, and Ruby-Cocoa templates in XCode. I haven't used this yet, so I've no idea how well it works, but it seems like it might have potential.
Re: (Score:2, Troll)
Re: (Score:2)
I agree unless they will let me write iPhone apps in Ruby. I'm not a Ruby fanboi by any stretch of the imagination but Objective C sucks balls. I passionately despise it and their IDE for it is even worse than the language. Using a language that other people use opens the possibility of using non-Apple tools (which lets face it, suck). For all of Apple's efforts to make nice consumer devices, they don't give a rat fuck about developers and their tools. Xcode is lightyears behind the equivalent tools fo
Re: (Score:2)
Because it allows people to show how rich they are [wrongdistance.com].
And... (Score:2, Informative)
Of course, Slashdot is a dime short and days late on the real news.
JavaScript 3-10x Faster On iPhone OS 3.0 [theappleblog.com]
Well, for a better, no BS news aggregator, try The Hacker News [ycombinator.com]. Then after seeing it there for a few days, come to slashdot to see a regurgitated discussion.
Your sig (Score:2)
Re: (Score:3, Informative)
Thanks ;)
You'd be surprised of the multitudes of comments I get on me and my bastardly signature... Well, you could always look at my freaks list to get an inking.
I thought it was rather dryly funny.
Re: (Score:2)
Well, you could always look at my freaks list to get an inking.
I'd rather not get inked, but I might want to get a ballpark feel for how unpopular it is. And maybe get an 'l' ;-)
Re: (Score:3)
Re: (Score:2, Interesting)
Yeah , a true renaissance (Score:5, Insightful)
"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...
Re: (Score:2)
``"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...''
Well? That doesn't make it any less of a renaissance. If anything, it makes it more like the renaissance. After all, that also started with the idea of "hey, let's go do something with all this great stuff we had a long time ago".
Re: (Score:2)
Well what? They've been standard compiler techniques for as long as I can remember. Isn't a renaissance supposed to be forgotten ideas coming back to life?
GCC avoids high level interprocedural optimization (Score:3, Interesting)
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 ...
Please don't start you sentences in the subject... (Score:3, Informative)
Comment removed (Score:4, Insightful)
Re: (Score:2)
So, GCC is making what should be technical decisions on a political basis?
GCC is making decisions to protect their intellectual property.
So now suddenly there is such a thing as IP?
Re: (Score:2)
Re: (Score:2, Troll)
Apple fan flaming OSS??? (Score:2)
I'm not sure if you were flaming OSS there, but you do realise that Apple owes a great deal to OSS and that much of what is OSX would be next to impossible without it, given that the BSD part of OSX is, in fact, OSS.
Re: (Score:3, Insightful)
While that's certainly true, OSS also benefits a lot from Apple. Without Mac OS X, BSD would have 25 million fewer users exercising its code.
Apple also owns CUPS and finances LLVM and WebKit and initiated Darwin Calendar Server and lots of other projects. Had the world not rejected NeXT and Unix to race after Microsoft's vaporware in the 90s, all the effort at reinventing BSD as Linux could have been united into a single OSS effort. So Apple has been working against the tide to return the world back to ope
Re: (Score:3, Interesting)
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: (Score:2)
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.
Precisely.
Re:LLVM strikes again. (Score:5, Interesting)
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: (Score:3, Interesting)
*sigh*
Re: (Score:2)
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*
No.
Re: (Score:2)
Re: (Score:2)
See also the Unladen swallow [google.com] project, which is using LLVM to speed up Python. They're still in the very early stages, but it looks promising.
Apple is not Microsoft ... (Score:3, Insightful)
They don't have any particular antipathy to the GPL ... Chriss Lattner proposed LLVM as a GCC successor after starting work at Apple. The FSF kicked him to the curb. I don't know if they underestimated his and Apple's commitment into turning the compiler into a true competitor or if they are simply stupid.
As LLVM gets better GCC will lose developers, this is unavoidable, it's EGCS all over again ... but this time a merge doesn't seem on the cards. It wasn't LLVM but the FSF themselves who torpedoed one of t
Re: (Score:2)
They don't have any particular antipathy to the GPL ... Chriss Lattner proposed LLVM as a GCC successor after starting work at Apple. The FSF kicked him to the curb. I don't know if they underestimated his and Apple's commitment into turning the compiler into a true competitor or if they are simply stupid.
As LLVM gets better GCC will lose developers, this is unavoidable, it's EGCS all over again ... but this time a merge doesn't seem on the cards. It wasn't LLVM but the FSF themselves who torpedoed one of the GPL flagships ... and for very very poor reasons.
They kicked him proposal to the curb because certain devs in GCC, like all businesses [for profit or otherwise] don't like to lose the power of control.
It shows how truly dense the GCC group always was of NeXT and now of Apple Engineering.
Re: (Score:2)
Re: (Score:2)
So I take it you never heard of Intel C++ compiler, Microsoft's Visual C++ compiler, Comeau C/C++, Digital Mars C++, Open64, etc... They must be figments or our collective imagination.
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
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 comp
Re: (Score:2)
Re: (Score:2)
Not really, it's neat but hardly new. You want to see a renaissance in compilers, look at TraceMonkey, LuaJIT, V8 and whatever the WebKit engine is called this week.
What the hell do you think WebKit will use to be built? LLVM.
Qt 4.5 already builds with LLVM. Same for the FreeBSD kernel.
Re: (Score:2)
Err, what? WebKit is compiled with GCC on Mac OS X (4.0 on Tiger, 4.2 on Leopard), and Visual C++ on Windows. Compiling WebKit with llvm-gcc is possible, but I'd only recommend it if you want something that's slower and takes longer to compile.
It's likely that the grandparent is referring to the SquirrelFish Extreme (AKA Nitro) JavaScript engine developed by Apple for WebKit.
Nitro AKA Squirrelfish (Score:4, Interesting)
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.
How they did it (Score:5, Funny)
Sleep(30); /* used to be 90 */
The Future (Score:2)
Re: (Score:2)
Do you know what a benchmark is and how it's made?
This sounds great! (Score:2, Funny)
just you wait... (Score:4, Insightful)
... for them to get further along in completing it... it'll slow down.
Re: (Score:2)
All dynamic scripting languages are "uber ultra slow" then, by your measure. Ruby 1.9 betters or equals the performance PHP, Perl and Python 3 in the latest Alioth Shootout.
true, but seems unnecessary (Score:3, Informative)
Common Lisp is ultra-dynamic and whatnot and still compiles to machine code, which in some implementations (SBCL/CMUCL) is quite respectable in performance. Is there something inherently less-compilable about Python, Ruby, Perl, etc., or have they just not had the same engineering work put into them?
Re: (Score:3, Informative)
Common Lisp scores really well on benchmarks because they turn off all the safety protections that are most of the reason to use a dynamic language in the first place.
All scripting/dynamic languages are slow, and they always will be because nobody wants a really high level language that crashes.
Re: (Score:3, Interesting)
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.
Re: (Score:3, Interesting)
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: (Score:2)
They're still orders of magnitude faster for generic code, though. You don't get C-like speed, but you get 10x+ better speed than you get in Python, especially on loop-heavy code.
Re: (Score:2)
Python has some brain-dead design issues in its interpreter, so it's not that great a feat.
"Unladen Swallow" will probably fix a lot of these issues (and maybe, just maybe, we'll get rid of GIL in Python).
CMU and SBCL are nice, but if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.
Re: (Score:2, Flamebait)
if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.
Yeah, but then you run into the problem where you have to write in Java, and let's be honest -- fuck that.
If you're going to write in something as butt-ugly as Java, you might as well write in C++, and really, if you're going to write in something as nasty as C++ for performance reasons, you might as well just go all the way and write in asm.
Then again, there is always D to consider, if you don't want to go dow
Re: (Score:2)
The JVM seems to have advanced to the point where other languages besides Java are targeting it as well. Two of the more popular seem to be Clojure [clojure.org] and Jython [jython.org]. I suspect more will start appearing if JRE 7 adds better built-in support for compiling dynamic languages, as has been long discussed.
Re: (Score:3, Informative)
Cyberax was talking about running languages such as Python [jython.org], Ruby [codehaus.org] or Lisp [clojure.org] on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM [java.net].
Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark [classpath.org].
Re: (Score:2)
>>if you want the current state-of-the-art in virtual machine development, you should check Sun JVM.
>Yeah, but then you run into the problem where you have to write in Java, and let's be honest -- fuck that.
What about Scala?
It seems to be a really nice language: I would say that Scala's syntax is better than D's syntax.
Re:true, but seems unnecessary (Score:5, Funny)
PS: Do you want me to punch you in face? You see, C++ is one of my favorite languages :)
I don't like the feeling of being punched in the face, which is one of the big reasons I don't code in C++ or Java. But if that's your thing, you should keep at it! :)
Re: (Score:2)
What are the brain-dead design issues? I've not really looked into interpreter/VM design, so I'm just curious about what constitutes bad design (if it's easy to explain to a noob).
Re: (Score:2)
The worst design issue is GIL (Global Interpreter Lock) - it prevents Python from using threads.
The second design issue is the usage of refcounters instead of real GC.
And finally, Python's bytecode and internal representation is far from optimal. Any Forth programmer can tell you that :)
Re: (Score:2)
Ahem, it doesn't prevent Python from using threads, merely preventing it from executing *Python code* in parallel. There's nothing preventing you from creating 20 threads to handle I/O: this is one of the most common uses of threads, anyway.
Besides, if you are attempting to get maximal performance out of Python by threading your computationally-heavy code, well, you are probably better off writing parallelized C or something, as the speedup from that move will far exceed any improvement you can get from usi
Re: (Score:2)
JVM is going to get invokedynamic instruction soon - http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html [headius.com]
Even without 'invkoedynamic', JRuby is one of the best-performing Ruby interpreters.
Re: (Score:2)
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.
Like Haskell/ML/Ocaml where I don't write the types myself?
no I'm not (Score:2)
Common Lisp is every bit as dynamic as Scheme, and yes it has fully dynamic runtime typing. It also has optional declarations, but you need not use them, and idiomatic Lisp style doesn't, except when attempting to optimize performance-critical code. Indeed Common Lisp is so dynamic that function calls can't even be resolved at compile time, because functions can redefine other functions (or themselves) at runtime.
Scheme is also not generally interpreted; there are both compilers and interpreters available.
Re: (Score:2)
That's a JIT (Just-In-Time) compiler: these are quite common; for example, Java on supported hardware has a JIT (HotSpot is the name, I think).
This differs from native code compilation, where you take a source file (in the scripting language) and generate (and store) the machine code corresponding to that source code. In principle, you can think of a JIT like a compiler which is running while the source code is being executed: as the code runs, the JIT compiles parts of it to native code to speedup executio
Re:The questions remains... (Score:5, Insightful)
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.
Re:The questions remains... (Score:5, Interesting)
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.
Code signing requirements that vary per language (Score:2)
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).
Until you try to execute your code on someone else's computer, and your Ruby code works but the C code fails to start because unlike the Ruby interpreter, your code hasn't been digitally signed by the platform maintainer. This is already the case for JavaScript: Windows allows parts of a JScript program to be coded in C as "ActiveX" objects, but they have to be signed with a valid Authenticode certificate issued by a trusted CA first.
Re: (Score:2)
What are you talking about? This is about server-side software, not executable applets in clients' browsers.
Re:The questions remains... (Score:5, Insightful)
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.
Re: (Score:3, Informative)
Tell that to MTV and New York Times. [google.com] Yes, they run Rails. Not on the front page, but nevertheless, they use it on very busy parts of their sites.
And heck, do I even need to mention 37signals? Those guys receive tons and tons of requests per second.
Re:The questions remains... (Score:4, Informative)
"Thanks, Captain Anecdote, but you've left out even the anecdotal evidence. What's all this exclusive writing you're doing with Ruby? I've been doing all my grocery list work in Ruby too, and it's *totally* fast enough."
I'm not the GP, but New York Times, MTV, Aboutus.com (high-ranking Alexa site), Yellow Pages, are all running Ruby. I'd love to give you even more examples but I've signed NDAs.
"I think Ruby is a fantastic language, but then I see comments like this modded up to 5 that are completely nonsensical. This makes Ruby fandom seem more like Java 1999, which makes me think twice about my positive opinion of it."
I can say the same thing about comments that complain about Ruby's speed without providing any kind evidence that the interpreter's speed is the bottleneck in their application. This makes it seem like bashing Ruby is just the latest fad, which makes it very hard for me to take any of these complaints seriously. If you cry wolf several times then nobody will listen to you anymore.
Re:The questions remains... (Score:4, Informative)
Re:Ruby? (Score:5, Insightful)
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.
Re: (Score:2)
Because binary is incredibly boring and tedious.
Same reason why all of our spoken/written languages aren't just sequences of "Yes" and "No". The same reasons why we no longer live in caves, is the same reason why programming languages will continue to evolve, and become more abstract. There are numerous variables, but the main one being that the original version is never all-encompassing and generally flawed, wood rollers are quicker to make than rubber on metal rims, but the latter is far more adaptable.
Bi
Re: (Score:3, Insightful)
Because puts { "I like beans" } is 9000% better than just typing I like beans.
What a terrible example
1. It's not functioning Ruby (try puts "I like beans", like most languages in fact)
2. It has nothing to do with the strengths or failings of Ruby as a language.
Do you know anything about Ruby? Do your empty platitudes about 'layers upon layers of complexity' actually have any basis in reality? From your comment, I suspect not.
There are some not so nice corners of Ruby, but an attempt to oversimplify is not one of them.
Re: (Score:2)
Ruby is a language that attempts to simplify something that is already perfectly simple, and in the process of trying it really does not introduce much of anything useful.
Ruby is a language that simplifies something that is bloody hard in Java. Ever heard of AOP? Trivial in Ruby.
Re: (Score:2, Insightful)
So you're suggesting that instead of creating languages like Ruby, we should create libraries to more complex environments like Java to make them faster to develop with? Variety is the spice of programming :). Personally, I'm glad languages like Python and Ruby exist and they are not only great and productive languages, they have both made me rethink the way I write software. I'm not sure just adding on top of Java would have achieved the same thing.
Re: (Score:2)
I can't understand your argument. Ruby wasn't created as a response to Java, it predates it.
True. It's programmers migrating to Ruby that's a response to Java.
Re: (Score:3, Insightful)
Re: (Score:2)
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!
Absolutely hilarious that you brought up TCP/IP/Ethernet.
Are you familiar with Fibre Channel? I'm guessing no. Look it up, compare with Ethernet & IP & TCP, SCSI, etc.
Do you know what Data Center/Converged Ethernet is? Yup, a COMPLETELY reengineered Ethernet with features of most upper layers (like in order delivery, retransmission, etc) built in to support FCoE. Essentially, it's Ethernet adapted to Fibre Channel, not FC adapted to Ethernet. I'm not really sure what this will do to IP/TCP, b
Re: (Score:2)
And how many people use Fibre Channel for it to matter?
Re: (Score:2)
What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.
GNUstep? (Score:2)
What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.
Would a Linux port be possible using GNUstep, the Free implementation of the same API that Cocoa is based on?
Re: (Score:2)
OK, more like 15 minutes. But it's a 3 year old XP install; 15 minutes is pretty good. The secret is: try not to install anything, and carefully rip out the shareware crap preinstalled by the OEM.
Re: (Score:3, Informative)
Care to bet on that? I've seen 5 minute boot times for XP on end-of-life hardware, primarily due to massive delays in indexing large disk drives. And no, it's not "booted" until it gives you a usable mouse and keyboard. Printing up the Windows boot screen and ignoring you for another few minutes does not count as "booted". Vista is noticeably worse on the same hardware due to the larger memory footprint: Win9x used to be OK on the hardware.