Ruby Performance
Bradley Kite
I'm a relatively new Ruby programmer, I am curious as to what Ruby is
trying to achieve that other scripting languages do not already offer (Apart
from the syntactic differences of yet another scripting language, that is).
The reason I ask is that it must offer something that is worth a lot considering
it runs twice as slowly as Perl (see below).
I was also interested in comparing the performance of Ruby against something
like Perl, and (although this test is VERY simple) thought that I'd benchmark
a simple counter in both Ruby and Perl. The number that it counts to
is arbitrary,
I started with 4294967296 and kept reducing it because I got bored of waiting).
Code is provided below.
Any way, on a 3Ghz P4 CPU, I got the following results:
Perl:
real 0m24.569s
user 0m24.499s
sys 0m0.068s
Ruby:
real 0m57.218s
user 0m57.108s
sys 0m0.109s
(Just out of interest I did it in C as well):
(Average Run, non-optimised)
real 0m0.142s
user 0m0.136s
sys 0m0.005s
(Average Run, -O3 optimisations):
real 0m0.074s
user 0m0.070s
sys 0m0.004s
##################################
#!/usr/bin/perl
my $num = 0;
while ($num < 94967295)
{
$num += 1;
}
###############
#!/usr/bin/ruby
num = 0
while num < 94967295 do
num += 1
end
###############
int main()
{
int counter = 0;
while (counter < 94967295)
{
counter += 1;
}
}
Julian Leviston
It's faster, easier and more enjoyable to write better, cleaner,
easier-to-understand code. ;-)
Julian.
Thomas E Enebo
>
> Hi all,
>
> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
> trying to achieve that other scripting languages do not already offer (Apart
> from the syntactic differences of yet another scripting language, that is).
> The reason I ask is that it must offer something that is worth a lot
> considering it runs twice as slowly as Perl (see below).
(I apologize in advance to any other Perl fans in advance)
If you think that Ruby's language does not offer A LOT over Perl's
syntax, then you may want to go back to Perl. I came from the Perl
camp and I have not looked back (other than reading the crazy Exegesis
writings -- which makes me even happier to be using Ruby). I loved
Perl and used it for over a decade. I used to read people asking the
same performance questions you are asking now to the perl lists, but it
was about why you would use a scripting language over a real one(tm) :)
I think performance is largely a red herring. Most scripts I have
written have not even had a performance attribute. If it took 2 or 3
times longer it would not have mattered. Usually, anytime performance
did matter it was a matter of an external force...Like accessing a database.
I think few times I have written scripts which took 8+ hours to process
data. In all cases this was one time conversion and a 16 hour run time
would not have mattered.
It sounds like Ruby's performance will get better with Rite (Ruby 2). Even
if it didn't I am more than happy with how it performs now. In other words
it does not seem slow when I work with it.
> [micro-benchmark removed for brevity]
--
+ http://www.tc.umn.edu/~enebo +---- mailto:en...@acm.org ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |
Robert Klemme
Just out of curiosity: did you also benchmark these Ruby idioms (which I
regard more typical):
94967295.times do
end
for i in 0..94967295 do
end
0.upto 94967295 do
end
Kind regards
robert
Bradley Kite
In perl, its 11 seconds to do this:
for (0..94967295)
{
}
The question is not so much about the run-time of a particular action,
but (in a web-based environment, for example) its more to do with
the number of concurrent users you can have without having to buy
more hardware.
--
Brad.
Lothar Scholz
BK> Hi all,
BK> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
BK> trying to achieve that other scripting languages do not already offer (Apart
BK> from the syntactic differences of yet another scripting language, that is).
Why ?
Python <-> Ruby:
Better consistent object modell, no indentation based language, but
Python is without doubt the hardest competitor. And its more or less
the same decision you must do when buying ice cream: Vanilla or
Chocolat ? Just a different flavour.
Perl <-> Ruby:
Perl is so ugly and difficult i don't want to compare it with ruby.
I doubt that it is possible to develop huge Perl programs where you
have a changing team of different programmers working on the same
code.
PHP <-> Ruby:
PHP is only a valid alternative for web development. And it is ugly
and unorthogonal.
TCL <-> Ruby:
Tcl is perfect for embedding it in apps and has a good infrastructure
(libraries, implementation) but the language is terrible unconvenient
for writing larger pure TCL programs.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Julian Leviston
Read the ruby on rails book - and then you'll get some real-world-
applications... take a look at basecamp - that's running with
THOUSANDS of users... not sure how many concurrent... and it's all of
one to two machines...
Julian.
Adrian Howard
> Hi all,
>
> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
> trying to achieve that other scripting languages do not already
> offer (Apart
> from the syntactic differences of yet another scripting language,
> that is).
> The reason I ask is that it must offer something that is worth a
> lot considering
> it runs twice as slowly as Perl (see below).
Well, non-idiomatic integer arithmatic might run twice as slowly :-)
Who cares? I certainly don't since the vast majority of my cycles are
not spent in tight loops doing integer arithmetic. If it was I
wouldn't be using Perl or Ruby (I'd probably be using Lisp :-)
The only performance figures that are important are whether tasks are
fast enough in a particular context. Otherwise we'd all be writing
assembler.
My pitch for Ruby to a Perl programmer would be:
- Perl 6 now! Many useful things that Perl 5 lacks and that Perl
6 will give you like a decent built in OO system, classes as proper
objects, coroutines, simple block passing, etc. Ruby does now.
- Ruby has a simple threading system that actually works
- Ruby has the same TIMTOWTDI attitude as Perl so you'll feel at
home, but has some better ways of doing some things that can make
your code considerably less ugly.
- A more concise clearer syntax for many operations, which means
you type less and your code is easier to maintain.
Cheers,
Adrian
Bradley Kite
Adrian Howard
[snip]
> Perl <-> Ruby:
> Perl is so ugly and difficult i don't want to compare it with ruby.
> I doubt that it is possible to develop huge Perl programs where you
> have a changing team of different programmers working on the same
> code.
As somebody who does this on a regular basis I'd have to disagree :-)
Adrian
Adrian Howard
> Compared with - say - slashdot?
[snip]
I'm sure with sufficient effort somebody could run Amazon with a
large parallel group of highly trained stoats. Who cares :-)
There are large web sites built with Java, Perl, Ruby, C++, Lisp, C#,
PHP and god knows how many other languages. PHP and Perl didn't build
their market share because they were /faster/ - they built it because
they were /better/ (for certain definitions of "better").
Perl's big advantage is that it's a nice flexible language that
enable you to build applications quickly and reliably (despite what
some people say :)
Ruby's advantage over Perl 5 is that it does some stuff that Perl 5
can't do, and makes much of the stuff it can do easier (in certain
areas anyway).
Compare the simplicity of overriding some_method= with messing with
lvalue subs and tied variables to get the same affect in Perl 5. Some
things are simpler and, when it comes to writing and maintaining
code, simpler is better.
Adrian
Brock Weaver
This Is My T... O... Way To Do It?
Help a brother out :-)
Also, somebody mentioned slashdot -- does this mean we should bring up Nazis
too so we can kill the thread?
I'm sorry, I'm a little caffiened up today.
I do have a valid comment though: I was running ruby from a USB stick, and
it was horribly slow (2-3 minutes to run "ruby -v"). Installing onto my 2nd
logical partition (D:) helped, but it was still about 30 seconds to do the
same version check. Installing onto C: -- same physical drive as D: -- made
"ruby -v" practically instantaneous.
Unfortunately, yes I have Windows, so I'm sure that makes a difference.
--
Brock Weaver
http://www.circaware.com
jm
Brian Schröder
> On 12 Aug 2005, at 16:39, Bradley Kite wrote:
>
> > Compared with - say - slashdot?
> [snip]
>
> I'm sure with sufficient effort somebody could run Amazon with a
> large parallel group of highly trained stoats. Who cares :-)
That reminds me of the pc technologie:
http://www.google.com/technology/pigeonrank.html
regards,
Brian
>
> There are large web sites built with Java, Perl, Ruby, C++, Lisp, C#,
> PHP and god knows how many other languages. PHP and Perl didn't build
> their market share because they were /faster/ - they built it because
> they were /better/ (for certain definitions of "better").
>
> Perl's big advantage is that it's a nice flexible language that
> enable you to build applications quickly and reliably (despite what
> some people say :)
>
> Ruby's advantage over Perl 5 is that it does some stuff that Perl 5
> can't do, and makes much of the stuff it can do easier (in certain
> areas anyway).
>
> Compare the simplicity of overriding some_method= with messing with
> lvalue subs and tied variables to get the same affect in Perl 5. Some
> things are simpler and, when it comes to writing and maintaining
> code, simpler is better.
>
> Adrian
>
>
--
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
tony summerfelt
> TCL <-> Ruby:
> Tcl is perfect for embedding it in apps and has a good infrastructure
> (libraries, implementation) but the language is terrible unconvenient
> for writing larger pure TCL programs.
what do you mean by 'larger' (ie. # of lines of code)
i think one thing tcl has over the rest is tk. even for 'larger' programs.
i do all my gui prototyping in tcl/tk strictly for look and feel. then
i try to get the same result in ruby and invariably one gui api or
another problem shows up...
--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Lothar Scholz
AH> On 12 Aug 2005, at 15:27, Bradley Kite wrote:
>> Hi all,
>>
>> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
>> trying to achieve that other scripting languages do not already
>> offer (Apart
>> from the syntactic differences of yet another scripting language,
>> that is).
>> The reason I ask is that it must offer something that is worth a
>> lot considering
>> it runs twice as slowly as Perl (see below).
AH> Well, non-idiomatic integer arithmatic might run twice as slowly :-)
AH> Who cares? I certainly don't since the vast majority of my cycles are
AH> not spent in tight loops doing integer arithmetic. If it was I
AH> wouldn't be using Perl or Ruby (I'd probably be using Lisp :-)
AH> The only performance figures that are important are whether tasks are
AH> fast enough in a particular context. Otherwise we'd all be writing
AH> assembler.
AH> My pitch for Ruby to a Perl programmer would be:
AH> - Perl 6 now! Many useful things that Perl 5 lacks and that Perl
AH> 6 will give you like a decent built in OO system, classes as proper
AH> objects, coroutines, simple block passing, etc. Ruby does now.
Yes thats also going to piss me off. I thought they got a few paid
full time worker on the language (at least one or two from
activestate). But i see almost no progress in Perl 6.
Maybe they did a huge mistake when they dicided that all features and
programming paradigms currently known in the software world should be
supported by Perl6.
Sometimes less is more. Especially in language design.
Lothar Scholz
AH> On 12 Aug 2005, at 16:23, Lothar Scholz wrote:
AH> [snip]
>> Perl <-> Ruby:
>> Perl is so ugly and difficult i don't want to compare it with ruby.
>> I doubt that it is possible to develop huge Perl programs where you
>> have a changing team of different programmers working on the same
>> code.
AH> [snip]
AH> As somebody who does this on a regular basis I'd have to disagree :-)
Maybe your collegues are maybe better motivated, better paid and
better educated, then the onces i had to work with in the past
(on a very small project - in terms of LOC not of importance for the company).
Lothar Scholz
AH> Perl's big advantage is that it's a nice flexible language that
AH> enable you to build applications quickly and reliably (despite what
AH> some people say :)
I think it's biggest advantage is that is is so long out there, that
it just has its market share. And it won that market share via the
sysadmins - for which is was always designed from the beginning.
Chris Martin
> large parallel group of highly trained stoats. Who cares :-)
>
> There are large web sites built with Java, Perl, Ruby, C++, Lisp, C#,
> PHP and god knows how many other languages. PHP and Perl didn't build
> their market share because they were /faster/ - they built it because
> they were /better/ (for certain definitions of "better").
Very true.
Those definitions of better can vary greatly depending on what you're
coding too.
Thanks to Rails, I think we'll see Ruby's market share (on the web)
increase drastically in time to come.
IMO Ruby (on rails) offers much faster development, and near instant
productivity. That is a great achievement that no other
language/framework can come close to.
As always, it's a matter of "the right tool for the job".
Like perl, ruby can do many jobs.
Also (IMO) ruby offers a nice bridge to all forms of programming (cli,
gui, web), and as many have said before.... it's just a joy to work
in! :)
--
Chris Martin
Web Developer
Open Source & Web Standards Advocate
http://www.chriscodes.com/
Lothar Scholz
ts> Lothar Scholz wrote on 8/12/2005 11:23 AM:
>> TCL <-> Ruby:
>> Tcl is perfect for embedding it in apps and has a good infrastructure
>> (libraries, implementation) but the language is terrible unconvenient
>> for writing larger pure TCL programs.
ts> what do you mean by 'larger' (ie. # of lines of code)
I mean complexer algorithms, more options and influces from the outside
world, more tighter connected modules.
Things where the OO and abstraction facilities of "real languages"
start shining. So instead large i should have written more complex.
ts> i think one thing tcl has over the rest is tk. even for 'larger' programs.
ts> i do all my gui prototyping in tcl/tk strictly for look and feel. then
ts> i try to get the same result in ruby and invariably one gui api or
ts> another problem shows up...
Yes, i loved TK and did a lot of TK/TCL programming in the past (as
you can find out when searching for my name in the comp.lang.tcl
newsgroup). And it is such a pitty that the TK evolution came to a
standstill for amost 10 years, with complete ignorance of changing
requirements, as i think technically TK is still the best toolkit out
there (binding events, matrix layout manager, canvas and text
widgets).
And this teached me a lession what can happen if too many people are
just saying: Its good enough for me. Sometimes when they realize that
this is not so anymore then it's too late to get back lost ground.
Adrian Howard
[snip]
> AH> - Perl 6 now! Many useful things that Perl 5 lacks and that
> Perl
> AH> 6 will give you like a decent built in OO system, classes as
> proper
> AH> objects, coroutines, simple block passing, etc. Ruby does now.
>
> Yes thats also going to piss me off. I thought they got a few paid
> full time worker on the language (at least one or two from
> activestate). But i see almost no progress in Perl 6.
I do. Parrot is an interesting platform for dynamic languages that's
just getting to a reasonable state, and Pugs is just /storming/
along. You can play with large chunks of Perl 6 now.
Cheers,
Adrian
Adrian Howard
On 12 Aug 2005, at 17:38, Lothar Scholz wrote:
[snip]
> Maybe your collegues are maybe better motivated, better paid and
> better educated, then the onces i had to work with in the past
> (on a very small project - in terms of LOC not of importance for
> the company).
I'd say a group of poorly motivated, poorly paid and badly educated
developers working on a project of no importance to the company is
doomed whatever language they're working in :-)
Adrian
Adrian Howard
[snip]
> AH> Perl's big advantage is that it's a nice flexible language that
> AH> enable you to build applications quickly and reliably (despite
> what
> AH> some people say :)
>
> I think it's biggest advantage is that is is so long out there, that
> it just has its market share. And it won that market share via the
> sysadmins - for which is was always designed from the beginning.
There are certainly bits of Perl I dislike, and there is much that is
harder than it should be, but given a choice between Java, Perl and
PHP I'd pick Perl almost every time.
Now if you added Ruby or Lisp to the mix I might have to think hard :-)
Adrian
Ara.T.Howard
i dunno - works for us ;-)
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
tony summerfelt
> AH> Perl's big advantage is that it's a nice flexible language that
> I think it's biggest advantage is that is is so long out there,
i think python has been out there as long as perl has? seems to me i
read that somewhere...
one of the things i really like about ruby is some of the perlisms i
can use like 'if' after another statement:
mylog.trim if mylog.size > 1000
ruby has a pretty good level of tim toadie as we can see with the
cartesian product thread.
i never felt comfortable with python code because i was told the way i
was doing it was always wrong. with ruby i can ease into more consise
ruby code, but still have others ok with my code as it currently stands.
Kirk Haines
> Compared with - say - slashdot?
>
> On 12/08/05, Julian Leviston <jul...@coretech.net.au> wrote:
> > The bottleneck is usually the database, tho... no? :-)
> >
> > Read the ruby on rails book - and then you'll get some real-world-
> > applications... take a look at basecamp - that's running with
> > THOUSANDS of users... not sure how many concurrent... and it's all of
> > one to two machines...
Performance is a consideration, but it is only one of many. I switched to
Ruby because of tangible reasons -- for web work I could do it under Ruby and
the framework of my choice faster than I could with anything I had experience
in Perl 3 years ago -- and also for intangibles -- as a long time Perl user
at that time, I found Ruby's syntax to be tremendously more enjoyable to work
with than Perl 5's.
But performance is still a factor. I originally had some concern that Ruby
seemed to be slower than Perl. However, as many people have said,
performance only becomes important when it becomes a problem, and it just
isn't a problem with Ruby, for me.
Web benchmarks are notoriously hard, as they are extremely context sensitive.
How much data is being pushed? How much of it is dynamic? What sort of
manipulations have to be done, and how much database interaction must occur?
The answers to these and other questions all affect the results. However, I
have a web app in production right now, written in Ruby, running on a single
processor midrange linux server (no 3.4Ghz P4's here), with a database
backend, being used by a Fortune 500 company. The design spec called for it
to be able to handle 30 requests per second.
In real world usage they have not come anywhere close to that yet, so time
will tell what happens when there is real data in it, but in testing with
current versions of the framework, I am getting as many as 285 requests per
second for a typical 9k HTML page, served through https, with some modest
dynamic content, when feeding it as many requests as I can (.0035 seconds or
less per page).
In real usage, with larger amounts of user data causing long pages with more
dynamic content, this will go down, but I estimate that it will still average
80-100 requests per second, and I did nothing in particular to enhance
performance. In fact, I coded some sections in ways that improved
readability and maintainability at the cost of performance.
Ruby is plenty fast.
Kirk Haines
Florian Frank
>Those idioms are around 21 seconds each in Ruby.
>
>In perl, its 11 seconds to do this:
>
>for (0..94967295)
>{
>
>}
>
>The question is not so much about the run-time of a particular action,
>but (in a web-based environment, for example) its more to do with
>the number of concurrent users you can have without having to buy
>more hardware.
>
>
This is much faster in Perl, too:
my $num = 2 ** 65;
my $i = 0;
while ($i < 94967295)
{
$num += 1;
$i += 1;
}
From this benchmark alone, you can see, that Perl is superior to Ruby
in every thinkable way.
--
Florian Frank
Adrian Howard
[snip]
> Thanks to Rails, I think we'll see Ruby's market share (on the web)
> increase drastically in time to come.
I agree.
> IMO Ruby (on rails) offers much faster development, and near instant
> productivity. That is a great achievement that no other
> language/framework can come close to.
[snip]
I think the advantage is more Ruby than Rails if you see what I mean.
Framework wise I feel as productive in one of the perl frameworks as
I do in Rails. The framework isn't the thing that makes Rails
attractive to me, it's Ruby.
What Rails did, and what WTR did to a different audience, was
demonstrate to a whole bunch of people what a really excellent
language Ruby is.
Cheers,
Adrian
Adrian Howard
On 12 Aug 2005, at 18:41, tony summerfelt wrote:
[snip]
> i think python has been out there as long as perl has? seems to me i
> read that somewhere...
Depends when you start counting.
1987 Perl 1.0
1991 Python 0.9
1991 Perl 4.0
1994 Perl 5.0
1995 Ruby 0.95
1997 PHP 3.0
1998 PHP 4.0
2000 Python 2.0
2003 Ruby 1.8
2004 PHP 5.0
Younger than Perl 1, but older than Perl 5 (which, in my opinion
anyway, was the first version of Perl that you could actually use for
serious applications).
Adrian
gregarican
> This Is My T... O... Way To Do It?
There Is More Than One Way To Do It.
What are the specs of the Windows box you have if it takes 30 seconds
to run 'ruby -v'???
zed...@zedshaw.com
Too bad there wasn't a way to hook your spiffy ultra-fast C loop into
Ruby. Wouldn't that be great? Some kind of "C" extension thing.
Then, your Ruby (and any language that can 'hook' C) is basically as fast
as C or even Assembler if you really get desperate.
Too bad that didn't exist. Oh well, I guess you'll have to keep testing
these loops and comparing them with Perl.
Zed A. Shaw
http://www.zedshaw.com/
<snip>
> I started with 4294967296 and kept reducing it because I got bored of
> waiting).
> Code is provided below.
>
> Any way, on a 3Ghz P4 CPU, I got the following results:
>
<snip>
Rick Nooner
>
> Performance is a consideration, but it is only one of many. I switched to
> Ruby because of tangible reasons -- for web work I could do it under Ruby and
> the framework of my choice faster than I could with anything I had experience
> in Perl 3 years ago -- and also for intangibles -- as a long time Perl user
> at that time, I found Ruby's syntax to be tremendously more enjoyable to work
> with than Perl 5's.
>
> But performance is still a factor. I originally had some concern that Ruby
> seemed to be slower than Perl. However, as many people have said,
> performance only becomes important when it becomes a problem, and it just
> isn't a problem with Ruby, for me.
>
In my experience, you should choose a language that you are productive and
comfortable with. Performance issues for any language that cannot be
addressed by changing the algorithims used will be dealt with by rewritting
the appropriate pieces in a lower level language. For scripting languages,
that usually means C. For C, that usually means assembly (at the expense
of portability).
Those performance bottlenecks that must be written in a lower level
language are probably going to be just a small part of the overall program
and will have to be written in a lower level language no matter what
scripting language you are using.
Therefore, being comfortable with the language you are using will lead to
more productivity than language performance factors.
For me, Ruby fits the way I like to program better than any other scripting
language that I am familiar with.
>
> Ruby is plenty fast.
>
I agree!
Rick
--
Rick Nooner
ri...@nooner.net
http://www.nooner.net
gabriele renzi
first, let me state that I do have great hopes for parrot, I think perl6
has some very interesting things[1] and pugs is massively cool.
But I think Lothar is right: IMVHO perl6 could have been definitely more
simple, withouth needing ~150 operators[2], special variables like
$?CLASS, ::?CLASS or ::*::Main[3], differentiating multi/method/sub etc
[1] to be fair, I do love multimethods and rules. Real love.
[2] http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf
[3] http://svn.openfoundry.org/pugs/docs/quickref/namespace
sig...@gmail.com
zed...@zedshaw.com wrote:
> Wow, that C program is really fast, especially with the -O3 option.
>
> Too bad there wasn't a way to hook your spiffy ultra-fast C loop into
> Ruby. Wouldn't that be great? Some kind of "C" extension thing.
>
> Then, your Ruby (and any language that can 'hook' C) is basically as fast
> as C or even Assembler if you really get desperate.
>
> Too bad that didn't exist. Oh well, I guess you'll have to keep testing
> these loops and comparing them with Perl.
>
> Zed A. Shaw
> http://www.zedshaw.com/
>
>
He could easily have done that with Tcl. Oh wait, you were being
sarcastic!
Robert
Julian Leviston
On 13/08/2005, at 1:19 AM, Bradley Kite wrote:
> Those idioms are around 21 seconds each in Ruby.
>
> In perl, its 11 seconds to do this:
>
> for (0..94967295)
> {
>
> }
>
> The question is not so much about the run-time of a particular action,
> but (in a web-based environment, for example) its more to do with
> the number of concurrent users you can have without having to buy
> more hardware.
>
> --
> Brad.
>
> On 12/08/05, Robert Klemme <bob....@gmx.net> wrote:
>
>> Bradley Kite wrote:
>>
>>> Hi all,
>>>
>>> I'm a relatively new Ruby programmer, I am curious as to what
>>> Ruby is
>>> trying to achieve that other scripting languages do not already
>>> offer
>>> (Apart from the syntactic differences of yet another scripting
>>> language, that is).
>>> The reason I ask is that it must offer something that is worth a lot
>>> considering it runs twice as slowly as Perl (see below).
>>>
>>> I was also interested in comparing the performance of Ruby against
>>> something like Perl, and (although this test is VERY simple) thought
>>> that I'd benchmark
>>> a simple counter in both Ruby and Perl. The number that it counts to
>>> is arbitrary,
>>> I started with 4294967296 and kept reducing it because I got
>>> bored of
>>> waiting). Code is provided below.
>>>
>>> Any way, on a 3Ghz P4 CPU, I got the following results:
>>>
>>> Perl:
>>> real 0m24.569s
>>> user 0m24.499s
>>> sys 0m0.068s
>>>
>>> Ruby:
>>> real 0m57.218s
>>> user 0m57.108s
>>> sys 0m0.109s
>>>
>>> (Just out of interest I did it in C as well):
>>>
>>> (Average Run, non-optimised)
>>> real 0m0.142s
>>> user 0m0.136s
>>> sys 0m0.005s
>>>
>>> (Average Run, -O3 optimisations):
>>> real 0m0.074s
>>> user 0m0.070s
>>> sys 0m0.004s
>>>
>>> ##################################
>>>
>>> #!/usr/bin/perl
>>> my $num = 0;
>>>
>>> while ($num < 94967295)
>>> {
>>> $num += 1;
>>> }
>>>
>>> ###############
>>>
>>> #!/usr/bin/ruby
>>> num = 0
>>>
>>> while num < 94967295 do
>>> num += 1
>>> end
>>>
>>> ###############
>>>
>>> int main()
>>> {
>>> int counter = 0;
>>>
>>> while (counter < 94967295)
>>> {
>>> counter += 1;
>>> }
>>> }
>>>
>>
>> Just out of curiosity: did you also benchmark these Ruby idioms
>> (which I
>> regard more typical):
>>
>> 94967295.times do
>> end
>>
>> for i in 0..94967295 do
>> end
>>
>> 0.upto 94967295 do
>> end
>>
>> Kind regards
>>
>> robert
>>
>
>
luke
> From this benchmark alone, you can see, that Perl is superior to Ruby
> in every thinkable way.
Now I want to see you do the chimney sweep dance! Dance! Dance!
Christopher Aldridge
GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N+++ o+ K+++ w---
O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++
G+++++ e++ h r-- y++**
lol!
H.P. Gobelli
> Hi all,
>
> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
> trying to achieve that other scripting languages do not already offer (Apart
> from the syntactic differences of yet another scripting language, that is).
> The reason I ask is that it must offer something that is worth a lot considering
> it runs twice as slowly as Perl (see below).
>
> I was also interested in comparing the performance of Ruby against something
> like Perl, and (although this test is VERY simple) thought that I'd benchmark
> a simple counter in both Ruby and Perl. The number that it counts to
> is arbitrary,
> I started with 4294967296 and kept reducing it because I got bored of waiting).
> Code is provided below.
>
> Any way, on a 3Ghz P4 CPU, I got the following results:
>
> Perl:
> real 0m24.569s
> user 0m24.499s
> sys 0m0.068s
>
> Ruby:
> real 0m57.218s
> user 0m57.108s
> sys 0m0.109s
>
I think the performance issues will be fixed with the new virtual
machine they are developing, just look at this:
$ time ruby1.8 perf.rb
real 0m57.328s
user 0m52.766s
sys 0m0.178s
$ time ruby1.9 perf.rb
real 0m41.883s
user 0m40.081s
sys 0m0.085s
$ time ruby1.9 -rite perf.rb
real 0m2.528s
user 0m2.351s
sys 0m0.010s
ruby1.9 -rite means run ruby with the new VM,
Regards,
Paolo.
tony summerfelt
> first, let me state that I do have great hopes for parrot,
i hope parrot dies on the vine...but it doesn't look like it's going to
> I think perl6 has some very interesting things[1]
it's too bad larry wall caved to the python people. is perl5 ugly? you
betcha :) i like everything about perl, tim toadie, perl magic, line noise
most of the perl code i write on windows is technically perl4, and i
can use a 345k dos executable to run/distribute it. very quick
execution. i have the latest perl5 installed but most of the quick and
dirty stuff i write is 4
Julian Leviston
luke
tmtowtdi
is pronounced. which stands for "there's more than one way to do it".
it's like the catchy saying for perl, which allows coders to write in
different ways. the jury's out about whether this is great or not, and comes
down to personal choice. ruby is toady itself.
best
luke
"Julian Leviston" <jul...@coretech.net.au> wrote in message
news:7AF9BAAD-AF9C-43D2...@coretech.net.au...
tony summerfelt
> 'tim toadie' is how the anagram
> tmtowtdi
> is pronounced. which stands for "there's more than one way to do it".
> it's like the catchy saying for perl, which allows coders to write in
> different ways.
one of my favorite larry wall quotes (dealing with tim toadie) is
iirc, 'if it works, it's right'
> the jury's out about whether this is great or not,
if you have to write a 5 line perl program to parse a txt file, and
you've written it in less than 45 seconds, and it takes about 2
seconds to execute, as opposed to searching the documenation/internet
for the 'right way to do it' and the 5 line program takes an hour to
write...
well THIS juror says it's great :)
writing the same 5 line program in python. i had to write it over
again a few times till it was 'written the right way' and accepted by
the entire python community as the right way...but i digress :)
i find ruby almost as flexible as perl is, with the added features of
the oo not feeling tacked on. some of my code isn't as concise as it
could be, but i figure i'll learn that as i write more ruby. for now
i just like getting my code up and running in a reasonable amount of
time...
Robert Klemme
> This is much faster in Perl, too:
>
> my $num = 2 ** 65;
>
> my $i = 0;
> while ($i < 94967295)
> {
> $num += 1;
> $i += 1;
> }
>
> From this benchmark alone, you can see, that Perl is superior to Ruby
> in every thinkable way.
Amazing how you extract "every thinkable way" from an eight liner. Wow!
robert
Brian Schröder
It seems I saw some irony somewhere ...
Julian Leviston
the bit bucket in internet communication.
;-)
Julian.
Adrian Howard
On 13 Aug 2005, at 17:19, tony summerfelt wrote:
[snip]
> i hope parrot dies on the vine...but it doesn't look like it's
> going to
Why? Rather nice VM to play with
>> I think perl6 has some very interesting things[1]
>
> it's too bad larry wall caved to the python people. is perl5 ugly?
To the Python people? I'd like to find one Python fan who would agree
with you on that! Perl 6 is just about as far from Python as I can
imagine a language to be :-)
Adrian
Robert Klemme
It was in the white space but apparently my news client had deleted it.
:-)
robert
Adrian Howard
On 12 Aug 2005, at 23:26, gabriele renzi wrote:
[snip]
> But I think Lothar is right: IMVHO perl6 could have been definitely
> more simple, withouth needing ~150 operators[2]
Curiously enough this number isn't radically more than there are in
Perl 5 (128) - and they're more logically grouped and named now.
> , special variables like $?CLASS, ::?CLASS or ::*::Main[3],
> differentiating multi/method/sub etc
I'm reserving judgement. I've not had the spare time to keep really
up to date and play with Perl 6 properly. However, my suspicion is
that it's going to be a lot simpler and logical than many people expect.
Adriian
Isaac Gouy
> Hi all,
>
> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
> trying to achieve that other scripting languages do not already offer (Apart
> from the syntactic differences of yet another scripting language, that is).
> The reason I ask is that it must offer something that is worth a lot considering
> it runs twice as slowly as Perl (see below).
>
> I was also interested in comparing the performance of Ruby against something
> like Perl, and (although this test is VERY simple) thought that I'd benchmark
> a simple counter in both Ruby and Perl.
That's even more simplistic than the benchmark programs on the Computer
Language Shootout :-)
Here's Ruby vs Perl
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu
and here are the old Doug Bagley programs
http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu
Austin Ziegler
> Bradley Kite wrote:
> > I was also interested in comparing the performance of Ruby against something
> > like Perl, and (although this test is VERY simple) thought that I'd benchmark
> > a simple counter in both Ruby and Perl.
> That's even more simplistic than the benchmark programs on the Computer
> Language Shootout :-)
>
> Here's Ruby vs Perl
> http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu
>
> and here are the old Doug Bagley programs
> http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu
And, like Mr Kite's test, none of the Alioth shootout benchmarks are
worth squat.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
tony summerfelt
> with you on that! Perl 6 is just about as far from Python as I can
> imagine a language to be :-)
my point was there doesn't need to be a perl6.
perl is what it is. those that like it use it, those that don't, don't. :)
tony summerfelt
>> i hope parrot dies on the vine...but it doesn't look like it's going to
> Why?
it started off as an april's fools joke on slashdot (about combining
perl and python or something like that, i still have the page saved
somewhere). the name suggests that perlers were joke's intended target.
Adrian Howard
On 15 Aug 2005, at 17:34, tony summerfelt wrote:
[snip]
> it started off as an april's fools joke on slashdot (about combining
> perl and python or something like that, i still have the page saved
> somewhere). the name suggests that perlers were joke's intended
> target.
There was a joke instigated by Simon Cozens - a Perl developer - put
together for OSCON 2001. Aided and abetted by Eric Raymond, Guido van
Rossum and many more. This was that Perl and Python were being
merged. See <http://www.oreillynet.com/pub/a/oreilly/news/
parrotstory_0401.html> for the full story.
The targets were, of course, everybody gullible enough to fall for
it :-)
Parrot the VM shares nothing beyond the name - and is an interesting
looking VM for dynamic languages. Including Perl 5 :-)
Adrian
Adrian Howard
> my point was there doesn't need to be a perl6.
>
> perl is what it is. those that like it use it, those that don't,
> don't. :)
Speak for yourself :-) I like Perl 5. I'm sure Larry Wall quite likes
Perl 5. However it's not perfect. If nobody tried to improve things
we'd all still be using assembler rather than lovely things like
Ruby and Perl.
Adrian
Jeremy Henty
Adrian Howard wrote:
> On 15 Aug 2005, at 17:34, tony summerfelt wrote:
> [parrot] was a joke ... that Perl and Python were being merged.
Didn't it include a report of Matz thanking Parrot for all the Ruby
converts? :-)
Cheers,
Jeremy Henty
--
There is nothing so useless as doing efficiently that which should not
be done at all.
-- Peter Drucker
Florian Frank
>It was in the white space but apparently my news client had deleted it.
>:-)
>
>
Not in the whitespaces, it's written black on white. This is my first
try in Socratic Trolling, so cut me some slack, ok? ;)
--
Florian Frank
Isaac Gouy
Austin Ziegler wrote:
> On 8/15/05, Isaac Gouy <ig...@yahoo.com> wrote:
> > Bradley Kite wrote:
> > > I was also interested in comparing the performance of Ruby against something
> > > like Perl, and (although this test is VERY simple) thought that I'd benchmark
> > > a simple counter in both Ruby and Perl.
> > That's even more simplistic than the benchmark programs on the Computer
> > Language Shootout :-)
> >
> > Here's Ruby vs Perl
> > http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu
> >
> > and here are the old Doug Bagley programs
> > http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu
>
> And, like Mr Kite's test, none of the Alioth shootout benchmarks are
> worth squat.
Others find worth where you fail.
Austin Ziegler
> Austin Ziegler wrote:
> > On 8/15/05, Isaac Gouy <ig...@yahoo.com> wrote:
> > > Bradley Kite wrote:
> > > > I was also interested in comparing the performance of Ruby against something
> > > > like Perl, and (although this test is VERY simple) thought that I'd benchmark
> > > > a simple counter in both Ruby and Perl.
> > > That's even more simplistic than the benchmark programs on the Computer
> > > Language Shootout :-)
> > >
> > > Here's Ruby vs Perl
> > > http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu
> > >
> > > and here are the old Doug Bagley programs
> > > http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu
> >
> > And, like Mr Kite's test, none of the Alioth shootout benchmarks are
> > worth squat.
> Others find worth where you fail.
That's only because they're uninformed or blinkered by the false
presentation on the shootout.
Isaac Gouy
> On 8/15/05, Isaac Gouy <ig...@yahoo.com> wrote:
> > Austin Ziegler wrote:
> > > On 8/15/05, Isaac Gouy <ig...@yahoo.com> wrote:
> > > > Bradley Kite wrote:
> > > > > I was also interested in comparing the performance of Ruby against something
> > > > > like Perl, and (although this test is VERY simple) thought that I'd benchmark
> > > > > a simple counter in both Ruby and Perl.
> > > > That's even more simplistic than the benchmark programs on the Computer
> > > > Language Shootout :-)
> > > >
> > > > Here's Ruby vs Perl
> > > > http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu
> > > >
> > > > and here are the old Doug Bagley programs
> > > > http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu
> > >
> > > And, like Mr Kite's test, none of the Alioth shootout benchmarks are
> > > worth squat.
> > Others find worth where you fail.
>
> That's only because they're uninformed or blinkered by the false
> presentation on the shootout.
"false presentation" - another baseless accusation?
What specifically is false about the presentation?
Wilson Bilkovich
poster basically just benchmarking startup time, something that is
currently one of Ruby's weak points?
Austin Ziegler
Isaac,
I'm done responding to you. None of my statements about the
fundamental problems of the shootout and your (apparent)
administration (or boosterism, at a minimum) are false or baseless.
They are well documented over the last several months -- pretty much
every time someone brings up the question of the Alioth shootout.
(Frankly, the Debian people ought to be embarrassed that this is
hosted with them. It's an embarrassment to people who know better.)
I've told you how you can fix at least part of this. It won't make the
shootout anything really worthwhile, but it will reduce the outright
*wrong* things.
But mostly, the best thing to do would be to give it up. It's crap --
and nothing will change that.
Daniel Amelang
Austin 'lead' quite an involved and lengthy discussion about
benchmarks (including the Alioth and Ackermann) just two months ago.
Before you leap into the fray, take a look:
http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/145390
If you do a google search of ruby-talk.org for 'austin alioth', or
just 'austin benchmarks' you can get even more on his opinion. I
highly recommend reading through the arguments and counter arguments
before we do a complete reproduction here.
But, hey, if you've got something to say beyond all that has already
been said, don't let me stop you :) I'm just trying to save us (and
you) from more of the same-old-same-old discussions.
Dan
Isaac Gouy
-snip-
> I highly recommend reading through the arguments and counter arguments
> before we do a complete reproduction here.
Thank you Daniel, you might notice my name in those discussions.
As you've mentioned, other folk on ruby-talk presented
counter-arguments to Austin's claims - afaict those counter-arguments
were never rebutted.
-snip-
> I'm just trying to save us (and
> you) from more of the same-old-same-old discussions.
If there's any substance behind the name-calling we should be able to
point-out specific errors on the shootout.
Isaac Gouy
Do you think startup time is large compared to a runtime of nearly a
minute?
Austin Ziegler
> Daniel Amelang wrote:
> -snip-
> > I highly recommend reading through the arguments and counter arguments
> > before we do a complete reproduction here.
> Thank you Daniel, you might notice my name in those discussions.
Only as an uncritical booster who doesn't actually listen. Just like now, no?
> As you've mentioned, other folk on ruby-talk presented
> counter-arguments to Austin's claims - afaict those counter-arguments
> were never rebutted.
Then you simply can't tell. They were. Basically, the shootout you run
is -- always has been -- and always will be -- crap. You can take
steps to make it honest crap, instead of what it is, though.
> -snip-
> > I'm just trying to save us (and
> > you) from more of the same-old-same-old discussions.
> If there's any substance behind the name-calling we should be able to
> point-out specific errors on the shootout.
When the problem with the shootout is the methodology and the
presentation -- without getting into more substantial errors
(statistical problems) -- and the general unwillingness of the people
who run it to do anything to improve the methodology and presentation,
then there's not a specific error. The whole thing is wrong. Until you
understand that there's problems with your whole damned methodology
and even worse problems with your presentation, you're never going to
get it.
Even if Ruby were to become the best performing language tomorrow, I
wouldn't recommend that anyone pay attention to the pile of garbage
known as the "Great Computer Language Shootout." The only thing
"great" about it is the amount of sheer ignorance that it and its
maintainers willingly perpetuate.
Matthew Desmarais
I've paid attention to some of the discussions on the shootout here,
but I'm not sure that I've ever had any of my basic questions
answered. Maybe you can answer them.
The site lists as its goal, "to learn about programming languages,
compare their performance in various (possibly meaningless) ways and,
most importantly, have some fun!"
What is it that we are learning about programming languages?
What do we gain from comparing performance in "various (possibly
meaningless) ways?
I don't think that I've learned much from the shootout, but it may
well be that I'm missing something. I do that a lot. :)
On 8/16/05, Isaac Gouy <ig...@yahoo.com> wrote:
William James
Austin Ziegler wrote:
> Then you simply can't tell. They were. Basically, the shootout you run
> is -- always has been -- and always will be -- crap. You can take
> steps to make it honest crap, instead of what it is, though.
Doug Bagley, the creator of the original "Great Computer Language
Shootout", called his system for ranking the languages "CRAPS".
It allowed him easily to tinker with the weight assigned to each test
and hence to make his favorite language come out on top.
Isaac Gouy
> On 8/15/05, Isaac Gouy <ig...@yahoo.com> wrote:
> > Austin Ziegler wrote:
> > > That's only because they're uninformed or blinkered by the false
> > > presentation on the shootout.
> > "false presentation" - another baseless accusation?
> >
> > What specifically is false about the presentation?
>
> Isaac,
>
> I'm done responding to you. None of my statements about the
> fundamental problems of the shootout and your (apparent)
> administration (or boosterism, at a minimum) are false or baseless.
Just a few days ago, you made claims which are baseless.
http://groups.google.com/group/comp.lang.ruby/msg/9716aeda66f54a17?hl=en&
> They are well documented over the last several months -- pretty much
> every time someone brings up the question of the Alioth shootout.
You're repeated claims are well documented - that doesn't make them
true.
Brock Weaver
Should I invoke Godwin's Law and put this argument to rest?
http://en.wikipedia.org/wiki/Godwin's_law
Okay.
All benchmarks are the brainchild of Hitler and his nazis.
--
Brock Weaver
http://www.circaware.com
Joe Van Dyk
Please, tell us how you *really* feel. I feel like there's some
bottled up emotions in there somewhere that you aren't telling us.
Martin Elzen
Actually, one aspect I've been missing in this whole ... 'debate', is the
point where Ruby, I think, has the chance to outshine most (if not all) of
its competitors... programmer productivity. Ruby has enough easyness built
into it that I'm sure just about anyone who's into it can come up with more
correct programs faster than in just about any other language... I value
*my* free time highly anyway...
Martin
Isaac Gouy
Matthew Desmarais wrote:
> Hi Isaac,
>
> I've paid attention to some of the discussions on the shootout here,
> but I'm not sure that I've ever had any of my basic questions
> answered. Maybe you can answer them.
>
> The site lists as its goal, "to learn about programming languages,
> compare their performance in various (possibly meaningless) ways and,
> most importantly, have some fun!"
>
> What is it that we are learning about programming languages?
>
> What do we gain from comparing performance in "various (possibly
> meaningless) ways?
>
> I don't think that I've learned much from the shootout, but it may
> well be that I'm missing something. I do that a lot. :)
Interesting questions Matthew.
imo What we learn depends on how actively we participate, and what we
already know or assume we know, and many other factors.
So I should ask
- did you try to make any of the programs faster or more elegant?
- did you try to write programs in a new language?
- did you know there was a language Clean?
- did you understand that relative performance would vary so much from
tcp-request-reply to k-nucleotide to n-body and mandelbrot?
- did you notice any patterns: slow for io, fast for number crunching?
- did you wonder why the Lua program used ~100MB for nsieve?
etc
ogilt...@davie.textdrive.com
I don't think that you answered either of my questions. If you have and
someone can tell me what the answers were, I'd appreciate it.
I guess I'm not sure why the site is called "The Computer Language
Shootout". To me, a shootout feels like a thing that pits two entities
against one another in a competition. The result of a shootout is
definitely a winner and a loser, depending on the definition of victory.
When you discuss the site, you talk about it as an educational tool. I'm
all for that kind of thing, and your response to me is reasonable and if I
were looking for help it would be helpful.
The problem is the use of the word benchmark. By claiming to offer
"benchmarks", the site is purporting to offer measured and standard
methods of comparisons between programming languages. The many
disclaimers show that these numbers should be taken with a grain of salt,
but the site's keywords, "benchmarking fast programming language benchmark
performance benchmarks shootout program" show otherwise.
And so I think that the site, or more specifically its design, is very
disingenuous. The site offers itself as a home for objective comparison
of the performance of programming languages. There is no such thing, and
so the site should not claim that there is.
Kirk Haines
> Interesting questions Matthew.
>
> imo What we learn depends on how actively we participate, and what we
> already know or assume we know, and many other factors.
>
> So I should ask
[List of questions that don't answer the prior questions deleted.]
I've been watching this debate with some interest. I think Austin does some
harm to his position with the anger with which he seems to present it, but on
the flipside, you seem to be taking a lot of long, lazy walks around some
clear questions without actually getting to an answer. This last reply that
you sent to Matthew's questions is a perfect example. Answering a question
with a question isn't an answer. It's a dance, a circumlocution, an evasion.
Answer the man's question, one at a time. Then pose questions of your own.
That's how a debate is supposed to take place; answer a question with a
question is just weak.
Kirk Haines
Austin Ziegler
> Please, tell us how you *really* feel. I feel like there's some
> bottled up emotions in there somewhere that you aren't telling us.
Darn. I was aiming for the "perfectly clear that I have no patience
for pseudo-intellectuals" effect. I'll try harder next time to be
clearer. It doesn't help that said pseudo-intellectual is impervious
to reality.
-austin
Sy
and performance discussions.. I did some searching and came up with
this short list:
You can also interchangably use the URL
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/ as with
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/123456
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/145390
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/144966
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/145196
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/145455
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/151897
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/151657
* http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/145325
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/33712
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/59554
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/65270
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/101165
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/103974
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/104182
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/124795
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/129831
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/136932
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/133852
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/133902
* http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/144966
Isaac Gouy
I was trying to answer "I don't think that I've learned much from the
shootout".
Let's try again - "What is it that we are learning about programming
languages?"
I don't know what you learn about programming languages from shootout,
the website states "Our goals are to learn about programming
languages..." - the goals of the folk administering the shootout are to
learn about programming languages...
Let's try again - "What do we gain from comparing performance in
"various (possibly meaningless) ways?"
Some perspective on how performance varies between programming language
implementations and tasks.
> I guess I'm not sure why the site is called "The Computer Language
> Shootout". To me, a shootout feels like a thing that pits two entities
> against one another in a competition. The result of a shootout is
> definitely a winner and a loser, depending on the definition of victory.
History - Doug Bagley's Shootout begat Aldo Calpini's Win32 Shootout
begat Brent Fulgham's Shootout.
> When you discuss the site, you talk about it as an educational tool. I'm
> all for that kind of thing, and your response to me is reasonable and if I
> were looking for help it would be helpful.
>
> The problem is the use of the word benchmark. By claiming to offer
> "benchmarks", the site is purporting to offer measured and standard
> methods of comparisons between programming languages. The many
> disclaimers show that these numbers should be taken with a grain of salt,
> but the site's keywords, "benchmarking fast programming language benchmark
> performance benchmarks shootout program" show otherwise.
>
> And so I think that the site, or more specifically its design, is very
> disingenuous. The site offers itself as a home for objective comparison
> of the performance of programming languages. There is no such thing, and
> so the site should not claim that there is.
The site provides multiple comparison programs, which show various
different language implementations "winning".
The site shows different ways to "win" - by CPU time, by memory use, by
LOCs.
The site provides a synthetic overall score and invites you to
"manipulate the multipliers and weights to make your favourite language
the fastest programming language in the Shootout" for "a solution that
is simple, neat, and wrong".
Does the site proclaim A is faster than B, or subvert that simplistic
notion?
Isaac Gouy
Kirk Haines wrote:
> On Tuesday 16 August 2005 2:46 pm, Isaac Gouy wrote:
>
> > Interesting questions Matthew.
> >
> > imo What we learn depends on how actively we participate, and what we
> > already know or assume we know, and many other factors.
> >
> > So I should ask
> [List of questions that don't answer the prior questions deleted.]
>
> I've been watching this debate with some interest. I think Austin does some
> harm to his position with the anger with which he seems to present it, but on
> the flipside, you seem to be taking a lot of long, lazy walks around some
> clear questions without actually getting to an answer. This last reply that
> you sent to Matthew's questions is a perfect example. Answering a question
> with a question isn't an answer. It's a dance, a circumlocution, an evasion.
Sometimes it's none of those things, sometimes it takes a couple of
conversational turns before we are all clear what the real questions
are.
http://groups.google.com/group/comp.lang.ruby/msg/613e239d096f7138?hl=en&
> Answer the man's question, one at a time. Then pose questions of your own.
> That's how a debate is supposed to take place; answer a question with a
> question is just weak.
Is debate the only form of conversation that's acceptable here, or can
there be discussion without winners and losers?
Kirk Haines
> Sometimes it's none of those things, sometimes it takes a couple of
> conversational turns before we are all clear what the real questions
> are.
>
> http://groups.google.com/group/comp.lang.ruby/msg/613e239d096f7138?hl=en&
"Real questions"? A real question is a question that someone asks. It's
generally safe to assume that the question someone asks is the one that they
want to have answered. You may think you know better than they do what
question they truly want answered, but that's a different issue.
> Is debate the only form of conversation that's acceptable here, or can
> there be discussion without winners and losers?
I said nothing of winners or losers. And I stand by my statement that
answering a question with a question, as in your prior post is a
circumlocution. It's useful if you don't have a good answer, especially if
you want to imply that you have a superior understanding without actually
saying anything useful, but it's a lousy way to have a conversation.
And that's about as far off topic as I personally want to carry this. It's
time to make dinner for the kids and then go write more Ruby code (had to get
Ruby into the post somewhere).
Kirk Haines
Bradley Kite
Well I really had no idea of how much emotional ettatchment people had
to their languages of choice.
When I posted my original question, I had no idea that the later
conversation would
contain such passion, humor, sarcasim and personal insult.
Any way, my orginal post stemmed from my curiosity with regards
to what Ruby was trying to achieve:
>> I'm a relatively new Ruby programmer, I am curious as to what Ruby is
>> trying to achieve that other scripting languages do not already offer (Apart
>> from the syntactic differences of yet another scripting language, that is).
The highly non-real-world and simplistic benchmarks were not meant to
provoke the zeolots, but rather well displayed my lack of understanding
for what Ruby was trying to achieve. Of which I still dont quite understand
Robert Klemme
> [in reply to no single post in particular]
>
> Well I really had no idea of how much emotional ettatchment people had
> to their languages of choice.
>
> When I posted my original question, I had no idea that the later
> conversation would
> contain such passion, humor, sarcasim and personal insult.
There has always been heated debate about which programming language was
best (or better than another). "better" is not easily defined (and it
also changes with context) so there's plenty room for personal taste and
preference. These in turn increase the likelyhood of heated debate...
> Any way, my orginal post stemmed from my curiosity with regards
> to what Ruby was trying to achieve:
>
>>> I'm a relatively new Ruby programmer, I am curious as to what Ruby
>>> is trying to achieve that other scripting languages do not already
>>> offer (Apart from the syntactic differences of yet another
>>> scripting language, that is).
>
> The highly non-real-world and simplistic benchmarks were not meant to
> provoke the zeolots, but rather well displayed my lack of
> understanding
> for what Ruby was trying to achieve. Of which I still dont quite
> understand
Hm... Maybe you should just use it for a while and see for yourself?
IMHO Ruby tries to be a pure OO dynamic language with clean syntax that
doesn't make simple tasks more complicated than necessary. And it does
this just great. My 0.02 EUR.
Kind regards
robert
Bill Kelly
>
> When I posted my original question, I had no idea that the later
> conversation would contain such passion, humor, sarcasim and
> personal insult.
It's Usenet. There's one in every crowd.
> Based on my experience of Ruby (which no doubt has been partly
> determined by my experiences with other languages) I can honestly say
> that it offers me little that is new/unachievable in other languages.
<smile> Well for any Turing-complete language, there's nothing
technically achievable in one that isn't also achievable in all
the others.
The one thing Turing-completeness doesn't cover is the number
and/or degree of headaches the programmer is subjected to before
the desired achievement is accomplished.
From what I've read from other Rubyists, and from my own
experience, many of us use Ruby because we find it more fun and
more productive than other languages we've learned so far.
(For me, that's Forth, C, C++, Java, Perl, Python, and Smalltalk.)
Best wishes to you in whatever language YOU find most fun and
most productive. It's not going to be Ruby for everyone, it just
is for a lot of us.
Regards,
Bill
Matthew Desmarais
Before we go any further, I want to be clear about a couple of things.
I have no problems with what goes on around the shootout site. I don't
think that you'll find many people here that do, since a lot of them
probably found their own path to ruby. There are quite a few
adventurous and curious souls on the list and they spend a lot of time
pulling ruby apart trying to understand it more clearly and find ways to
make it better. (Putting Matz in the unenviable position of having to
reconsider some of the basic features of the language on a regular
basis. If I were he, I'd have an ulcer by now...)
By all means, carry on with experimentation with all of the languages
that you can get your hands on. But let's not pretend that we're
measuring anything.
>I was trying to answer "I don't think that I've learned much from the
>shootout".
>
>
>Let's try again - "What is it that we are learning about programming
>languages?"
>
>I don't know what you learn about programming languages from shootout,
>the website states "Our goals are to learn about programming
>languages..." - the goals of the folk administering the shootout are to
>learn about programming languages...
>
>
I understand you here, but I don't think that you are very clear about
this. More later...
>
>Let's try again - "What do we gain from comparing performance in
>"various (possibly meaningless) ways?"
>
>Some perspective on how performance varies between programming language
>implementations and tasks.
>
>
This is a part of what I take issue with. The site offers a great deal
of disclaimers regarding the worthlessness of the "benchmarks" there.
But most of the space on the main page is devoted to reporting and
comparing these benchmarks.
>>I guess I'm not sure why the site is called "The Computer Language
>>Shootout". To me, a shootout feels like a thing that pits two entities
>>against one another in a competition. The result of a shootout is
>>definitely a winner and a loser, depending on the definition of victory.
>>
>>
>
>History - Doug Bagley's Shootout begat Aldo Calpini's Win32 Shootout
>begat Brent Fulgham's Shootout.
>
>
>
With regard to your justification of the name, I'm not sure that history
is a good reason to keep it.
>
>
>>When you discuss the site, you talk about it as an educational tool. I'm
>>all for that kind of thing, and your response to me is reasonable and if I
>>were looking for help it would be helpful.
>>
>>The problem is the use of the word benchmark. By claiming to offer
>>"benchmarks", the site is purporting to offer measured and standard
>>methods of comparisons between programming languages. The many
>>disclaimers show that these numbers should be taken with a grain of salt,
>>but the site's keywords, "benchmarking fast programming language benchmark
>>performance benchmarks shootout program" show otherwise.
>>
>>And so I think that the site, or more specifically its design, is very
>>disingenuous. The site offers itself as a home for objective comparison
>>of the performance of programming languages. There is no such thing, and
>>so the site should not claim that there is.
>>
>>
>
>The site provides multiple comparison programs, which show various
>different language implementations "winning".
>
>The site shows different ways to "win" - by CPU time, by memory use, by
>LOCs.
>
>The site provides a synthetic overall score and invites you to
>"manipulate the multipliers and weights to make your favourite language
>the fastest programming language in the Shootout" for "a solution that
>is simple, neat, and wrong".
>
>Does the site proclaim A is faster than B, or subvert that simplistic
>notion?
>
>
>
Isaac, you entry into this discussion thread was the following post:
> That's even more simplistic than the benchmark programs on the Computer
> Language Shootout :-)
>
> Here's Ruby vs Perl
>
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu
<http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu>
>
> and here are the old Doug Bagley programs
>
http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu
<http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=ruby&sort=fullcpu>
When you follow the Ruby vs Perl link, you are treated to a nice picture
and some numbers, all of which (you would assume from reading the page)
offer some insight into the comparative merits of the languages.
In this case, the site _does_ proclaim a winner in any number of categories.
The site talks out of both sides of its mouth. Even with all of the
language condemning the "simplistic notion" of winners and losers, the
site still offers results. It is these results that are dishonest and
misleading.
I think that the site would work much better _without_ the results
page. Why not let the curious discover their own results? Hands on
experimentation is the best way to explore the concepts that you are
interested in. Maybe you can find a way to offer free shell accounts
that give access to the tools required to experiment with these
"benchmarks".
Or at the very least, take the focus off of those confounded numbers.
tony summerfelt
> Ruby has enough
> easyness built into it that I'm sure just about anyone who's into it can
> come up with more correct programs faster than in just about any other
> language
unfortunately, ruby has enough 'hardness' built into too. at this
point in my ruby education i'm obviously not 'thinking in ruby'.
i'm working on a module i'm going to be using in just about every
other program i write in ruby. currently it's about 500 lines of code
but likely won't exceed 1000. i can't help thinking i should be using
'yield' (not using it more, using it period). there's not one line
where i use yield. i think it might save me a lot of code but i get
the feeling that i'd have to rethink each method in the module class.
what i have now is working and doing exactly what i want...when i
started i wasn't too worried about how the code looked.
--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Isaac Gouy
-snip-
> By all means, carry on with experimentation with all of the languages
> that you can get your hands on. But let's not pretend that we're
> measuring anything.
On the contrary, we are measuring 'something'.
imo The issue is interpretation - what relevance (if any) do those
measurements have, what worth (if any) do those measurements have, what
(if anything) do they mean?
-snip-
> >Some perspective on how performance varies between programming language
> >implementations and tasks.
> >
> This is a part of what I take issue with. The site offers a great deal
> of disclaimers regarding the worthlessness of the "benchmarks" there.
> But most of the space on the main page is devoted to reporting and
> comparing these benchmarks.
Flawed is not a synonym for worthless ;-)
-snip-
> >History - Doug Bagley's Shootout begat Aldo Calpini's Win32 Shootout
> >begat Brent Fulgham's Shootout.
> >
> With regard to your justification of the name, I'm not sure that history
> is a good reason to keep it.
You may be right about that.
-snip-
> When you follow the Ruby vs Perl link, you are treated to a nice picture
> and some numbers, all of which (you would assume from reading the page)
> offer some insight into the comparative merits of the languages.
>
> In this case, the site _does_ proclaim a winner in any number of categories.
Yes - under said conditions, said program X was measured to be A,B,C
and said program Y was measured to be D,E,F.
imo that's not The issue.
> The site talks out of both sides of its mouth. Even with all of the
> language condemning the "simplistic notion" of winners and losers, the
> site still offers results. It is these results that are dishonest and
> misleading.
Let me clarify what I meant by "simplistic notion".
I meant it's simplistic to measure one program using language
implementation A, and one program using language implementation B, and
then *generalize* to say that language A is faster than language B.
I meant it's simplistic to measure cpu time without measuring memory
use, and then claim that program A is faster than program B.
It's simply true that under said conditions, said program X was
measured to be A,B,C and said program Y was measured to be D,E,F -
there's nothing dishonest about those results.
> I think that the site would work much better _without_ the results
> page.
Which page is "the results page"?
ogilt...@davie.textdrive.com
>> and some numbers, all of which (you would assume from reading the page)
>> offer some insight into the comparative merits of the languages.
>>
>> In this case, the site _does_ proclaim a winner in any number of
>> categories.
>
> Yes - under said conditions, said program X was measured to be A,B,C
> and said program Y was measured to be D,E,F.
>
> imo that's not The issue.
Aha! It appears that this is where we'll have to agree to disagree. For
me this is The issue. There were no conditions mentioned on the page
that you linked to.
There are so many factors that contribute to any measure of performance
for a "program" that any comparison must be qualified to the point of
irrelevance. Some such factors might be:
- Compiled vs Interpreted
-- Implementation of the Compiler/Interpreter
--- Version of the implementation
-- Compilation flags
- Implementation of the algorithm
-- Suitability of the implementation to the algorithm
- System Environment and its affects on the execution environment.
I could spend all day listing considerations like these. To attempt to
boil all of this down to one number for any measure of performance is
naive. These numbers aren't useful to the casual observer who will
misunderstand them, nor are they useful to the person who spends the time
to investigate the execution environment and draw their own conclusions.
Good luck with the site Isaac. I hope that it continues to go well for
you and that you continue to learn from it.
Isaac Gouy
"a genuine object-oriented, easy-to-use scripting language"
http://www.rubygarden.org/faq/entry/show/5
Julian Leviston
Isaac Gouy
> >> When you follow the Ruby vs Perl link, you are treated to a nice picture
> >> and some numbers, all of which (you would assume from reading the page)
> >> offer some insight into the comparative merits of the languages.
> >>
> >> In this case, the site _does_ proclaim a winner in any number of
> >> categories.
> >
> > Yes - under said conditions, said program X was measured to be A,B,C
> > and said program Y was measured to be D,E,F.
> >
> > imo that's not The issue.
>
> Aha! It appears that this is where we'll have to agree to disagree. For
> me this is The issue. There were no conditions mentioned on the page
> that you linked to.
>
> There are so many factors that contribute to any measure of performance
> for a "program" that any comparison must be qualified to the point of
> irrelevance. Some such factors might be:
>
> - Compiled vs Interpreted
> -- Implementation of the Compiler/Interpreter
> --- Version of the implementation
The specific implementation and version is given at the bottom of the
page I linked to
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&sort=fullcpu#about
> -- Compilation flags
Are shown for each program, they may vary program to program, for
example
http://shootout.alioth.debian.org/benchmark.php?test=ackermann&lang=gcc&id=3&sort=fullcpu#log
> - Implementation of the algorithm
> -- Suitability of the implementation to the algorithm
Not sure exactly what you mean, perhaps this
http://shootout.alioth.debian.org/benchmark.php?test=ackermann&lang=all&sort=fullcpu#about
> - System Environment and its affects on the execution environment.
Is given in the FAQ
http://shootout.alioth.debian.org/faq.php?sort=fullcpu#measure
> I could spend all day listing considerations like these. To attempt to
> boil all of this down to one number for any measure of performance is
> naive. These numbers aren't useful to the casual observer who will
> misunderstand them, nor are they useful to the person who spends the time
> to investigate the execution environment and draw their own conclusions.
>
> Good luck with the site Isaac. I hope that it continues to go well for
> you and that ou continue to learn from it.
Thank you.
Julian Leviston
procedures.
Smalltalk is an example of a language which DOESN'T allow you to
think non-oop-ly... because if you do, your programs will be more
hard to understand and work out than if you programmed them in a
procedural language.
Ruby is very flexible, and so it allows you to program however you
like, and still maintains its understandability. Using blocks and
yield statements are very object-oriented ways of dealing with things
and make for efficient and wonderful code if you understand it.
From experience, ruby lets you write crappy code, then refactor it
very easily and efficiently. It also lets you compact the code, and
make beautiful code that sometimes take a bit longer to think
through, but you come to have a greater understanding of how to write
better code for the future as a result - in short, it helps you to
fix up at the core of your code-writing - to write better code in
general and therefore (here) to think better.
Julian.