# Relative speed of Ruby vs Java for a large compiled app like Freenet **URL:** \ **Category:** ruby-talk\ **Created:** [25 September 2005 14:21 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081 "2005-09-25T14:21:48Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Austin\_Ziegler5](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/austin_ziegler5/32/1985_2.png) [@Austin\_Ziegler5](https://rubytalk.org/u/Austin_Ziegler5)\ **Post date:** [26 September 2005 15:20 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/21 "2005-09-26T15:20:32Z")
Having to point out that you are running a dishonest "shootout" with dishonest verbiage and aims is worse. I've told you how you can make your little garbage site honest and shut me up. Have you done it, yet, or do you want to keep being called on it? If you're considering my pointing out that your shootout is garbage and dishonest "abuse", then I must consider that the truth must really hurt. Because it's the absolute truth. -austin > **···** > > On 9/25/05, Isaac Gouy \ wrote: > > > Having to say over and over that Ruby currently has an obviously slow > > interpreter and that doesn't matter as-long-as your program doesn't > > spend much time in the interpreter grows old. > > > > (Also Mr Ziegler's abuse has become stale.) > > -- > Austin Ziegler \* halostatue@gmail.com >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [26 September 2005 19:51 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/22 "2005-09-26T19:51:42Z")
Austin Ziegler wrote: > **···** > > > On 9/25/05, Isaac Gouy \ wrote: > > \> Having to say over and over that Ruby currently has an obviously slow > > \> interpreter and that doesn't matter as-long-as your program doesn't > > \> spend much time in the interpreter grows old. > > \> > > \> (Also Mr Ziegler's abuse has become stale.) > > > > Having to point out that you are running a dishonest "shootout" with > > dishonest verbiage and aims is worse. I've told you how you can make > > your little garbage site honest and shut me up. Have you done it, yet, > > or do you want to keep being called on it? > > > > If you're considering my pointing out that your shootout is garbage > > and dishonest "abuse", then I must consider that the truth must really > > hurt. Because it's the absolute truth. > > > > -austin > > -- > > Austin Ziegler \* halostatue@gmail.com > >                \* Alternate: austin@halostatue.ca > > Have you even looked at the website in the last 6 months? > > Austin, I have no desire to shut you up - make as many abusive personal > comments as you like - abuse is not an argument. > > You are completely free to regard /your opinion/ as The Truth - others > may not share that confusion. ---
**Author:** ![Austin\_Ziegler5](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/austin_ziegler5/32/1985_2.png) [@Austin\_Ziegler5](https://rubytalk.org/u/Austin_Ziegler5)\ **Post date:** [26 September 2005 20:06 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/23 "2005-09-26T20:06:08Z")
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. 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. I pick on Ackermann, but the same flaws I pointed out in January ... are still there. Obviously, neither you nor anyone else running the Bogus Computer Language Shootout wants to fix any of this and therefore are demonstrably dishonest. At least as concerns this. -austin > **···** > > On 9/26/05, Isaac Gouy \ wrote: > > > Have you even looked at the website in the last 6 months? > > -- > Austin Ziegler \* halostatue@gmail.com >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [26 September 2005 22:21 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/24 "2005-09-26T22:21:42Z")
Martin, perhaps you could collect this stuff and put it into your wiki page for future use? Austin Ziegler 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? > 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. Perl#2 and Perl#3 are in alternatives - you're welcome to your opinion about the other Perl program. > 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. For variety you could pick on takfp and JavaScript [http://shootout.alioth.debian.org/sandbox/fulldata.php?test=takfp&p1=ruby-0&p2=python-0&p3=javascript-0&p4=php-0&sort=fullcpu](http://shootout.alioth.debian.org/sandbox/fulldata.php?test=takfp&p1=ruby-0&p2=python-0&p3=javascript-0&p4=php-0&sort=fullcpu) > **···** > > > On 9/26/05, Isaac Gouy \ wrote: > > > Obviously, neither you nor anyone else running the Bogus Computer > > Language Shootout wants to fix any of this and therefore are > > demonstrably dishonest. > > > > At least as concerns this. > > > > -austin > > -- > > Austin Ziegler \* halostatue@gmail.com > >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Austin\_Ziegler5](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/austin_ziegler5/32/1985_2.png) [@Austin\_Ziegler5](https://rubytalk.org/u/Austin_Ziegler5)\ **Post date:** [26 September 2005 22:32 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/25 "2005-09-26T22:32:57Z")
> Martin, perhaps you could collect this stuff and put it into your wiki > page for future use? > > Austin Ziegler 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. > \> 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? -austin > **···** > > On 9/26/05, Isaac Gouy \ wrote: > > > \> On 9/26/05, Isaac Gouy \ wrote: > > -- > Austin Ziegler \* halostatue@gmail.com >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Devin\_Mullins](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@Devin\_Mullins](https://rubytalk.org/u/Devin_Mullins)\ **Post date:** [26 September 2005 22:45 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/26 "2005-09-26T22:45:00Z")
Isaac Gouy wrote: > > ... Ackermann .... 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. I think his argument is grounded, here. (No presupposition on his other arguments; I don't particularly care, let alone know.) Many would consider it a flaw that Python allows programs to escape the parameters (namely, heap size) with which they were initiated. Ruby \_does\_ provide the functionality that allows it to run, but leaves it up to the launcher, and makes the matter unchangeable at runtime. Devin ---
**Author:** ![Florian\_Frank2](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@Florian\_Frank2](https://rubytalk.org/u/Florian_Frank2)\ **Post date:** [26 September 2005 23:11 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/27 "2005-09-26T23:11:37Z")
Isaac Gouy wrote: > 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. I just provided that functionality, see below: def ack(m, n)     if m == 0 then         n + 1     elsif n == 0 then         ack(m - 1, 1)     else         ack(m - 1, ack(m, n - 1))     end end if ARGV.size \< 2   require 'rbconfig'   include Config   system "ulimit -s 100000; #{File.join(CONFIG['bindir'], CONFIG['ruby\_install\_name'])} #$0 #{$\*[0]||9} foo" else   NUM = Integer(ARGV.shift)   print "Ack(3,", NUM, "): ", ack(3, NUM), "\n" end Will you complain now or change the Ruby script to use this functionality, that allows the program to run? > **···** > > -- > Florian Frank ---
**Author:** ![Bill\_Kelly](https://avatars.discourse-cdn.com/v4/letter/b/cc9497/32.png) [@Bill\_Kelly](https://rubytalk.org/u/Bill_Kelly)\ **Post date:** [26 September 2005 23:30 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/28 "2005-09-26T23:30:50Z")
> 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. Since the shootout purports to be about measuring performance, it seems a smidge over-picky to disallow a program on the basis of a non-performance-related environment configuration issue. If you're on a unix system, and you really wanted to, you could add this ugly line to the start of the script: ENV['FIXSTACK'] = "1" and exec(%{/bin/sh -c "ulimit -s unlimited ; exec ruby #$0 #{ARGV.join(' ')}"}) unless ENV['FIXSTACK'] It'll fix the environment problem and won't even change the process ID. Note that it should also be possible to call setrlimit() directly from ruby, using the built-in 'dl' library. The 'dl' library works on windows too, so the appropriate win32 routine should also be callable directly from ruby. In other words, it \_can\_ be solved directly from ruby. But it's an environment issue that, whether addressed in the shell prior to calling the ruby program, or handled in ruby itself via the kludge above, or in ruby via a system call using the 'dl' library, neither affects the program run-time nor memory usage in a significant way. Since it's not a performance- related issue, disqualifying a program based on an incorrectly configured environment seems peculiar. If you want to see the direct system call from ruby using the 'dl' module, let me know. I think it'd be three lines or so. Regards, Bill > **···** > > From: "Isaac Gouy" \ ---
**Author:** ![Devin\_Mullins](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@Devin\_Mullins](https://rubytalk.org/u/Devin_Mullins)\ **Post date:** [26 September 2005 22:46 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/29 "2005-09-26T22:46:38Z")
Devin Mullins wrote: > (namely, heap size) Err... did I say heap size? 'Cause I meant stack size. Yeah, that's the ticket... Devin ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [27 September 2005 01:36 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/30 "2005-09-27T01:36:42Z")
Florian Frank wrote: > Isaac Gouy wrote: > > \>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. > \> > \> > I just provided that functionality, see below: > > def ack(m, n) >     if m == 0 then >         n + 1 >     elsif n == 0 then >         ack(m - 1, 1) >     else >         ack(m - 1, ack(m, n - 1)) >     end > end > > if ARGV.size \< 2 >   require 'rbconfig' >   include Config >   system "ulimit -s 100000; #{File.join(CONFIG['bindir'], > CONFIG['ruby\_install\_name'])} #$0 #{$\*[0]||9} foo" > else >   NUM = Integer(ARGV.shift) >   print "Ack(3,", NUM, "): ", ack(3, NUM), "\n" > end > > Will you complain now or change the Ruby script to use this > functionality, that allows the program to run? > > -- > Florian Frank Here's how to contribute your program [http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute](http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute) ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [27 September 2005 01:41 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/31 "2005-09-27T01:41:43Z")
Bill Kelly wrote: > From: "Isaac Gouy" \ > > \> 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. > > Since the shootout purports to be about measuring performance, > it seems a smidge over-picky to disallow a program on the > basis of a non-performance-related environment configuration > issue. > > If you're on a unix system, and you really wanted to, you could > add this ugly line to the start of the script: > > ENV['FIXSTACK'] = "1" and exec(%{/bin/sh -c "ulimit -s unlimited ; exec ruby #$0 #{ARGV.join(' ')}"}) unless ENV['FIXSTACK'] > > It'll fix the environment problem and won't even change the > process ID. > > Note that it should also be possible to call setrlimit() > directly from ruby, using the built-in 'dl' library. > The 'dl' library works on windows too, so the appropriate > win32 routine should also be callable directly from ruby. > > In other words, it \_can\_ be solved directly from ruby. But > it's an environment issue that, whether addressed in the > shell prior to calling the ruby program, or handled in ruby > itself via the kludge above, or in ruby via a system call using > the 'dl' library, neither affects the program run-time nor memory > usage in a significant way. Since it's not a performance- > related issue, disqualifying a program based on an incorrectly > configured environment seems peculiar. > > If you want to see the direct system call from ruby using > the 'dl' module, let me know. I think it'd be three lines or > so. > > Regards, > > Bill Here's how to contribute your program [http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute](http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute) ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [27 September 2005 01:46 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/32 "2005-09-27T01:46:43Z")
Devin Mullins wrote: > Isaac Gouy wrote: > > \>\>... Ackermann .... 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. > \> > \> > I think his argument is grounded, here. (No presupposition on his other > arguments; I don't particularly care, let alone know.) Many would > consider it a flaw that Python allows programs to escape the parameters > (namely, heap size) with which they were initiated. Ruby \_does\_ provide > the functionality that allows it to run, but leaves it up to the > launcher, and makes the matter unchangeable at runtime. > > Devin Seems like Billy Kelly and Florian Frank think Ruby has the same functionality as Python - which "many would consider it a flaw"? ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [27 September 2005 02:01 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/33 "2005-09-27T02:01:45Z")
Austin Ziegler wrote: > \> Martin, perhaps you could collect this stuff and put it into your wiki > \> page for future use? > \> > \> Austin Ziegler 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. > **[WebMD - Better information. Better health.](https://www.webmd.com/?BenchMarks)** > > The leading source for trustworthy and timely health and medical news and information. Providing credible health information, supportive community, and educational services by blending award-winning expertise in content, community services, expert... > \> \> 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? > **···** > > > On 9/26/05, Isaac Gouy \ wrote: > > \> \> On 9/26/05, Isaac Gouy \ wrote: > > > -austin > > -- > > Austin Ziegler \* halostatue@gmail.com > >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Tanaka\_Akira1](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@Tanaka\_Akira1](https://rubytalk.org/u/Tanaka_Akira1)\ **Post date:** [27 September 2005 03:04 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/34 "2005-09-27T03:04:08Z")
In article \<019301c5c2f2$c9431ca0$6442a8c0@musicbox\>,   "Bill Kelly" \ writes: > Note that it should also be possible to call setrlimit() > directly from ruby, using the built-in 'dl' library. Also note that Ruby 1.9 has Process.setrlimit. > **···** > > -- > Tanaka Akira ---
**Author:** ![W11](https://avatars.discourse-cdn.com/v4/letter/w/8e7dd6/32.png) [@W11](https://rubytalk.org/u/W11)\ **Post date:** [27 September 2005 18:16 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/35 "2005-09-27T18:16:54Z")
The amazing thing is that the shootout says it is using version 1.9 of Ruby. Warren Seltzer ---
**Author:** ![Austin\_Ziegler5](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/austin_ziegler5/32/1985_2.png) [@Austin\_Ziegler5](https://rubytalk.org/u/Austin_Ziegler5)\ **Post date:** [27 September 2005 01:42 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/36 "2005-09-27T01:42:18Z")
Obviously, you didn't even read the program to see that it was an utter cheat to exec the program. The right solution -- as always -- for you to fix your damned run script. Fix that and you'll get results for the Ruby program AS IT STANDS. Don't fix it, and my assessment of the lack of honesty surrounding the Bogus Computer Language Shootout stands. -austin > **···** > > On 9/26/05, Isaac Gouy \ wrote: > > > \> Will you complain now or change the Ruby script to use this > > \> functionality, that allows the program to run? > > Here's how to contribute your program > > [http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute](http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute) > > -- > Austin Ziegler \* halostatue@gmail.com >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Devin\_Mullins](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@Devin\_Mullins](https://rubytalk.org/u/Devin_Mullins)\ **Post date:** [27 September 2005 02:12 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/37 "2005-09-27T02:12:11Z")
Isaac Gouy wrote: > Devin Mullins wrote: > > > I think his argument is grounded, here. (No presupposition on his other > > arguments; I don't particularly care, let alone know.) Many would > > consider it a flaw that Python allows programs to escape the parameters > > (namely, heap size) with which they were initiated. Ruby \_does\_ provide > > the functionality that allows it to run, but leaves it up to the > > launcher, and makes the matter unchangeable at runtime. > >     > > Seems like Billy Kelly and Florian Frank think Ruby has the same > functionality as Python - which "many would consider it a flaw"? So? ---
**Author:** ![Austin\_Ziegler5](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/austin_ziegler5/32/1985_2.png) [@Austin\_Ziegler5](https://rubytalk.org/u/Austin_Ziegler5)\ **Post date:** [27 September 2005 02:56 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/38 "2005-09-27T02:56:37Z")
> Austin Ziegler wrote: > > > > Martin, perhaps you could collect this stuff and put it into your wiki > > > page for future use? > > > > > > Austin Ziegler 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](http://rubygarden.org/ruby?BenchMarks) No, Isaac, I'm not going to do your homework for you anymore. > > 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? I'm a nice person, except to people who demonstrate themselves to be willfully dishonest, obstinate, and ignorant. The approaches suggested by Bill and Florian aren't acceptable because they run Ruby and then shell out to run the program again after making the necessary environment change. It runs, but it'd be better if you just fixed your run script. -austin > **···** > > On 9/26/05, Isaac Gouy \ wrote: > > > > On 9/26/05, Isaac Gouy \ wrote: > > > > > > > > On 9/26/05, Isaac Gouy \ wrote: > > -- > Austin Ziegler \* halostatue@gmail.com >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Bill\_Kelly](https://avatars.discourse-cdn.com/v4/letter/b/cc9497/32.png) [@Bill\_Kelly](https://rubytalk.org/u/Bill_Kelly)\ **Post date:** [27 September 2005 04:35 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/39 "2005-09-27T04:35:19Z")
> In article \<019301c5c2f2$c9431ca0$6442a8c0@musicbox\>, >   "Bill Kelly" \ writes: > > \> Note that it should also be possible to call setrlimit() > \> directly from ruby, using the built-in 'dl' library. > > Also note that Ruby 1.9 has Process.setrlimit. Sweet!! =D Incidentally, does anyone know what I'm doing wrong here? I tried to make the call with 'dl', but I'm getting an error: (eval):2:in `setrlimit': undefined method `' for nil:NilClass (NoMethodError)         from rlimit2.rb:16 > **···** > > From: "Tanaka Akira" \ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > #!/usr/bin/env ruby > > require 'dl/import' > > module LIBC >   extend DL::Importable >   dlload "libc.so" >   RLIMIT\_STACK = 3 >   RLIM\_INFINITY = -1 >   extern "int setrlimit(int, const void \*)" > end > > include LIBC > > rlimit = [RLIM\_INFINITY,RLIM\_INFINITY].pack('LL').to\_ptr > result = setrlimit(RLIMIT\_STACK, rlimit) # this is line 16 > > puts result > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > According to [http://www.jbrowse.com/text/rdl\_en.html](http://www.jbrowse.com/text/rdl_en.html) I thought > my code should work? > > Thanks, > > Regards, > > Bill ---
**Author:** ![Isaac\_Gouy1](https://avatars.discourse-cdn.com/v4/letter/i/4bbf92/32.png) [@Isaac\_Gouy1](https://rubytalk.org/u/Isaac_Gouy1)\ **Post date:** [27 September 2005 19:26 UTC](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081/40 "2005-09-27T19:26:46Z")
Warren Seltzer wrote: > The amazing thing is that the shootout says it is using version 1.9 of Ruby. > > Warren Seltzer I presume Brent pulled the latest Debian. That is also why so many language installs are broken at the moment ☹ [Previous page](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081.md?page=1) [Next page](https://rubytalk.org/t/relative-speed-of-ruby-vs-java-for-a-large-compiled-app-like-freenet/21081.md?page=3)