From: Austin Ziegler Date: 2005-08-13T08:11:29+09:00 Subject: Re: Performance Ruby On 8/12/05, Brian Wisti wrote: > On 8/12/05, Austin Ziegler wrote: >> On 8/11/05, mathew wrote: >>> Goel wrote: >>>> Is there any benchmark of the performance of Ruby vs. C, C++, Java >>>> etc? >>>> I couln't find it on the ruby website. >>> There's the Great Computer Language Shootout. >>> >> Which, as I keep reminding people, isn't worth the paper it isn't >> printed on. It's a waste of time, effort, and credibility to keep >> promoting it as if the people who created it know what they're doing. >> >> Not all benchmarks are bad, but the GCLS is the least useful. > I always had the impression that the GCLS was presented as "purely for > entertainment purposes only," and people who take them too seriously > were to be scoffed at by sane people everywhere as well as the > founders of the project. > > That's just my perception, but this is one of the few cases where I > don't really care whether or my perception is correct. Okay, to be completely fair: yes, the GCLS is presented as "purely for entertainment purposes only." At least that's what is said on the GCLS website, which makes it the operating theory, at least. In practice, though, the Alioth shootout is heavily promoted by the people what run it and others, and there are comparisons between different languages and little is done to make sure that the various languages don't cheat (I found a cheat in the Perl implementation of the Ackermann and a sort-of-cheat in the Python implementation). There's a whole veneer of respectability about this particular set of tests, complete with the encouragement to "make your language perform better." In other words, for something that's "for entertainment purposes only," there's a lot of time spent making it look "legitimate." When the people who run it are confronted with this, they fall back on the "it's not serious" line ... while very shortly after doing something that suggests that it is, indeed, serious. The Alioth shootout is dishonest in its presentation and purpose. It does *more* than place "performance" numbers on the screen; it offers an interpretation of those numbers ... all the while pretending not to offer said interpretation. Real world performance numbers are more useful, and when Ara Howard tells me that Ruby performs fast enough for his image crunching, or Rich Kilmer tells me that Ruby made Cougaar possible and fast, then I believe them. These people (and others) are pushing Ruby further than anyone else, including people who use Ruby on Rails. And yet, I also believe DHH when he says that Rails scalability isn't a big issue, in that it scales the same way that web applications have scaled for a while, and the same way that Kuro5hin and Slashdot scaled -- more machines with load balancing and separating the database server from the application server. If you want to see an *intense* Ruby application, look at my own PDF::Writer. The layout engine is about as computationally intensive as one will get in pure Ruby, and would merit dropping to C in some places (except that I have deliberately made it a goal to keep the code pure Ruby). On my VERY SLOW LAPTOP, it takes no more than ten minutes to generate the 90+ page manual. It takes a matter of seconds to generate each demo (and most of *that* is in the startup). On my 3Ghz work machine, it's about 2 1/2 - 3 minutes to do the same manual. I suspect that with the report generator that's being talked about, there will be some time involved with the PDF generation for output, but it will still be fast enough to be usable from Rails. I'm getting ready to add SVG support to PDF::Writer, and my current code is whipping through complex SVGs pretty quickly. For some things, it takes enough processing time that I'll recommend people do partial rendering beforehand -- which is a good idea in any case for many things and not just for performance reasons. I'll be documenting the technique, too. I'm not saying anything new here, not really. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca