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

[Devin Mullins]

(namely, heap size)

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

Devin

 

[Florian Frank]

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?

 

[Bill Kelly]

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

 

[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.

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?

Here's how to contribute your program
http://shootout.alioth.debian.org/faq.php?sort=fullcpu#contribute

 

[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

 

[Austin Ziegler]

Here's how to contribute your program
http://shootout.alioth.debian.org/faq.php?sort=3Dfullcpu#contribute

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

 

[Isaac Gouy]

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

 

[Isaac Gouy]

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, 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#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).


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?

 

[Isaac Gouy]

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

I implicitly trust Ruby programmers - it's simply unthinkable that any
of them would contribute a program which intentionally cheated. (And it
would give the Perl guys something to complain about.)

 

[Devin Mullins]

Devin Mullins wrote:


Seems like Billy Kelly and Florian Frank think Ruby has the same
functionality as Python - which "many would consider it a flaw"?

So?

 

[Austin Ziegler]

I implicitly trust Ruby programmers - it's simply unthinkable that any
of them would contribute a program which intentionally cheated. (And
it would give the Perl guys something to complain about.)

No humour, either. I don't think that it's just me, but I strongly
suspect that Florian's and Bill's submissions were very tongue in cheek.
Neither one of them is currently cross-platform, as they depend on the
shell command "ulimit". Bill's suggests something that Ruby could
probably do to add ulimit support directly to the language, but so far,
Matz hasn't seen fit to add such. I *do* believe that it was determined
to be something that the environment, not the program, was responsible
for.

-austin

 

[Austin Ziegler]

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.

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

 

[Tanaka Akira]

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.

 

[Bill Kelly]

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/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

 

[Bill Kelly]

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

I forgot to mention, this is:

ruby 1.8.2 (2004-11-06) [i686-linux]


Regards,

Bill

 

[William Morgan]

Excerpts from Robert Klemme's mail of 25 Sep 2005 (CDT):

And C doesn't rot your brain? C'mon...

This has already reached the point of religious debate, but... no, I
don't think it does. At least, in my experience, writing C code may
be irritating because you have to keep track of all the details like who
frees strings and whatnot, but it doesn't actively encourage cutting and
pasting like Java does.

Like I said, just my experience.

 

[William Morgan]

Excerpts from Patrick Hurley's mail of 26 Sep 2005 (CDT):

Write the whole thing in Ruby (or whatever language you find most
productive). Test it (and write test cases), verify its correctness.
Then _if_ it is too slow profile it, locating the bottlenecks. Last
step is then to speed up that small portion of critical path code
(located by profiling, not guessing) and optimize the algorithm and/or
the implementation (possibly rewriting a portion in C).

Yeah, this is probably the best idea for from-scratch applications. I
was thinking library because I figured either there was a Freenet
library out there, or there should be. A good linkable library would be
useful to everyone.

 

[Bill Kelly]

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

Sorry for the noise, but I'm going to re-post this question
in its own thread... It occurred to me many people may have
killfiled this flame-war topic... ;-/


Regards,

Bill

 

[Warren Seltzer]

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

Warren Seltzer

 

[Isaac Gouy]

No, Isaac, I'm not going to do your homework for you anymore.

This mystery text didn't seem to exist in August either
http://groups.google.com/group/comp.lang.ruby/msg/9716aeda66f54a17?hl=en&
http://groups.google.com/group/comp.lang.ruby/msg/696a3b04c450815c?hl=en&