I took a quick look at many of the performance tests at
http://www.bagley.org/~doug/shootout/. You’re right, Ruby is not 30 times
slower than Perl, but it seems to take about twice as long as Perl in most
of the tests. Some aren’t quite that bad, but many are much worse than twice
as long. Python appears to be much closer to the performance of Perl than
Ruby.
···
-----Original Message-----
From: Berger, Daniel [mailto:djberge@qwest.com]
Sent: Monday, July 01, 2002 9:41 AM
To: ruby-talk@ruby-lang.org
Subject: RE: ruby vs. perl
-----Original Message-----
From: ccos [mailto:ccos@bigpond.com]
hello,
i’m not a perl user.
i have no agenda.
somebody on another list i’m on just
made something of a sweeping statement.
that ruby is slow.
thirty times slower than perl.
there is discussion on that list
about whether to use ruby for a certain project
which is very timing sensitive.
just curious what any of you might have to
say about the aforementioned comparison.
thanks,
c
Ruby has a slightly slower startup time, but actual execution
speed is about
the same in my experience. It is NOT 30 times slower than
Perl. For a
benchmark comparison of Ruby & Perl (among many others), see
the “Great
Computer Language Shootout”:
http://www.bagley.org/~doug/shootout/
Regards,
Dan
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
Ruby is also faster than Perl on at least one of the tests. If you go
to the scorecard page and enter a multiplier of 1 for cpu, memory, and
lines of code, then Ruby and Perl are neck and neck. It would be
interesting to see how Ruby 1.7 stacks up.
As interesting as this is, I don’t think that for real-world
applications, any of it is relevant. Most Ruby and Perl programmers
will rewrite a portion of code as a C extension when it is not fast
enough. Given this approach, Ruby and Perl will probably perform
similarly for most applications.
Paul
···
On Tue, Jul 02, 2002 at 12:43:18AM +0900, Volkmann, Mark wrote:
I took a quick look at many of the performance tests at
http://www.bagley.org/~doug/shootout/. You’re right, Ruby is not 30 times
slower than Perl, but it seems to take about twice as long as Perl in most
of the tests. Some aren’t quite that bad, but many are much worse than twice
as long. Python appears to be much closer to the performance of Perl than
Ruby.
Paul Brannan wrote:
As interesting as this is, I don’t think that for real-world
applications, any of it is relevant. Most Ruby and Perl programmers
will rewrite a portion of code as a C extension when it is not fast
enough. Given this approach, Ruby and Perl will probably perform
similarly for most applications.
Ruby’s advantage here is that the C interface is very nice. From what
I’ve heard, it’s much more seamless than Perl’s C interface (which I
admit to not having used).
I use Ruby for performance-intensive numerical simulations. Because
Ruby’s so good at quick and dirty string processing (like Perl) as well
as complex data structures (unlike Perl), it’s a reasonable task to
generate C code on the fly to implement user-defined simulation
specifications. I’m getting performance comparable with the C
application that was originally used to do this work, plus advantages of
being able to control, inspect, etc. the simulation from Ruby code.
In article 3D20A557.8010906@path.berkeley.edu,
···
Joel VanderWerf vjoel@PATH.Berkeley.EDU wrote:
Paul Brannan wrote:
As interesting as this is, I don’t think that for real-world
applications, any of it is relevant. Most Ruby and Perl programmers
will rewrite a portion of code as a C extension when it is not fast
enough. Given this approach, Ruby and Perl will probably perform
similarly for most applications.
Ruby’s advantage here is that the C interface is very nice. From what
I’ve heard, it’s much more seamless than Perl’s C interface (which I
admit to not having used).
I use Ruby for performance-intensive numerical simulations. Because
Ruby’s so good at quick and dirty string processing (like Perl) as well
as complex data structures (unlike Perl), it’s a reasonable task to
generate C code on the fly to implement user-defined simulation
specifications. I’m getting performance comparable with the C
application that was originally used to do this work, plus advantages of
being able to control, inspect, etc. the simulation from Ruby code.
Joel,
This generating C on the fly concept sounds interesting, can you go into
more detail? Any code you can post?
Phil
Phil Tomson wrote:
This generating C on the fly concept sounds interesting, can you go into
more detail? Any code you can post?
Phil,
It’s in the cgen library on RAA:
http://www.ruby-lang.org/en/raa-list.rhtml?name=CGenerator
The name is a bit unfortunate. Cgen is not a code generator in the sense
of a compiler back-end. What it does is manage the mundane aspects of
defining C functions and using the Ruby C interface. In this respect,
it’s like an inline. But, unlike inline, it also has a templating aspect
that allows you to incrementally add code to methods and members to
structs. This feature is used in the CShadow module to simplify defining
classes wrapped around C structs that have inheritance of the struct
members. Struct members can be basic C types or references to Ruby objects.
A too-simple example:
require ‘cgen/cshadow’
class MyComplex < Numeric
include CShadow
shadow_attr_accessor :re => “double re”, :im => “double im”
def initialize re, im
self.re = re
self.im = im
end
m = define_method(:mul!) {
arguments :other
declare :other_shadow => “MyComplex_Shadow *other_shadow”
declare :new_re => “double new_re”, :new_im => “double new_im”
body %{
// Your C code here. Full example is included in tarball.
// you can refer to shadow attrs like so: shadow->re
}
returns “self”
}
It’s not useful in this example, but you can add code
to the “body” of #mul! as follows:
m.body %{
// more C code
}
end
MyComplex.commit # generate the lib and load it
z = MyComplex.new 5, 1.3
z.mul! 10
p z.re
p z.im