From: Isaac Gouy Date: 2005-09-27T11:01:45+09:00 Subject: Re: Relative speed of Ruby vs Java for a large compiled app like Freenet Austin Ziegler wrote: > On 9/26/05, Isaac Gouy wrote: > > Martin, perhaps you could collect this stuff and put it into your wiki > > page for future use? > > > > Austin Ziegler wrote: > > > On 9/26/05, Isaac Gouy wrote: > > > > Have you even looked at the website in the last 6 months? > > > > > > Yes. The text that makes a lie of everything you claim about the site > > > is still there on the front page, as of 26 September 2005 15.55 EDT. > > > > And that text would be? > > Assuming that you actually care, look it up on the archives. The text > has not improved since the last time we talked about the alioth > shootout. Martin DeMello suggested collecting complaints on a wiki page, so every 3 weeks when someone asks about Ruby performance on the shootout, they can simply be directed to all the complaints you've already made. If for some reason you don't feel able to mention the "text that makes a lie of everything you claim about the site" here - just savage it on the wiki page. http://rubygarden.org/ruby?BenchMarks > > > > Further, the incorrect Ackermann result for Ruby (e.g., "error") is > > > still there (I've shown you at least four times how to fix that > > > problem -- and yet you still don't fix it -- and it has nothing to do > > > with the correctly implemented program, it has everything to do with > > > the test script). The default Perl program is still improper (Perl #4 > > > is the only one that should be on the default list), Perl, Perl#2, and > > > Perl#3 all belong on the "interesting alternative implementations" > > > only. Indeed, the Python one still has a line of code that modifies > > > the same stuff as what Ruby requires you modify outside of the program > > > (where this properly belongs!). Without this line, *none* of the > > > Python runs works. > > Complaining that it's wrong for Python to provide functionality that > > allows the program to run is simply bizarre. The problem is that Ruby > > doesn't provide that functionality. > > No, the problem is that you don't *run* the Ruby program with an > expanded stack size. Matz has chosen to not make this available within > Ruby. This is *not* a flaw. The problem is your test script, not the > Ruby script. You've been told this for nine months now. > > > Perl#2 and Perl#3 are in alternatives - you're welcome to your opinion > > about the other Perl program. > > Perl#4 is the only one that actually implements the function in a > readable and usable way. Perl (unlabeled) implements it in a way that > acknowledges that it's a cheat nearly as much as the two alternatives > (#2 and #3). > > > > I pick on Ackermann, but the same flaws I pointed out in January ... > > > are still there. > > And the same limitations in Ruby's support for recursion are still > > there - as others on this list pointed out months ago. > > Incorrect. With a *single* shell command, I can make the Ruby > Ackermann run perfectly (and, IIRC, better than the Python equivalent, > or at least to deeper recursion depths even with the Python language > "cheat"). This isn't undocumented; this has been mentioned to you > since January. It has *nothing* to do with the implementation of the > Ruby Ackermann, but the default stack size allocated to the Ruby > process. It's more restrictive under Windows, and that is probably a > compile-time option, but again -- it's *not* a Ruby problem. It's a > problem in your methodology and your assumptions. If you've screwed up > there, where *else* have you screwed up? More abuse? So much for Martin Fowler's Ruby People meme. Is there seem reason the approaches suggested by Bill Kelly and Florian Franks are unacceptable? > > -austin > -- > Austin Ziegler * halostatue@gmail.com > * Alternate: austin@halostatue.ca