Relative speed of Ruby vs Java for a large compiled app like Freenet

ruby-talk
21

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 <igouy@yahoo.com> 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

22

Austin Ziegler wrote:

···

On 9/25/05, Isaac Gouy <igouy@yahoo.com> 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.

23

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 <igouy@yahoo.com> wrote:

Have you even looked at the website in the last 6 months?

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

24

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

···

On 9/26/05, Isaac Gouy <igouy@yahoo.com> 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

25

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 <igouy@yahoo.com> wrote:

> On 9/26/05, Isaac Gouy <igouy@yahoo.com> wrote:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

26

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

27

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

28

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" <igouy@yahoo.com>

29

Devin Mullins wrote:

(namely, heap size)

Err... did I say heap size? 'Cause I meant stack size. Yeah, that's the ticket...

Devin

30

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

31

Bill Kelly wrote:

From: "Isaac Gouy" <igouy@yahoo.com>

> 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

32

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"?

33

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.

> > 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 <igouy@yahoo.com> wrote:
> > On 9/26/05, Isaac Gouy <igouy@yahoo.com> wrote:

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

34

In article <019301c5c2f2$c9431ca0$6442a8c0@musicbox>,
  "Bill Kelly" <billk@cts.com> 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

35

The amazing thing is that the shootout says it is using version 1.9 of Ruby.

Warren Seltzer

36

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 <igouy@yahoo.com> 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

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

37

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?

38

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

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 <igouy@yahoo.com> wrote:

On 9/26/05, Isaac Gouy <igouy@yahoo.com> wrote:

On 9/26/05, Isaac Gouy <igouy@yahoo.com> wrote:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

39

In article <019301c5c2f2$c9431ca0$6442a8c0@musicbox>,
  "Bill Kelly" <billk@cts.com> 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" <akr@m17n.org>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/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 I thought
my code should work?

Thanks,

Regards,

Bill

40

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 :frowning: