[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Benchmark Mono - Ruby

e

2/6/2005 6:26:00 AM

> Lähettäjä: Kent Sibilev <ksibilev@bellsouth.net>
> Aihe: Re: Benchmark Mono - Ruby
>
> Consider this 'tuning':
>
> $ cat t.rb
> require 'ruby_to_c'
>
> module Inline
> class Ruby < Inline::C
> def initialize(mod)
> super
> end
>
> def optimize(meth)
> src = RubyToC.translate(@mod, meth)
> @mod.class_eval "alias :#{meth}_slow :#{meth}"
> @mod.class_eval "remove_method :#{meth}"
> c src
> end
> end
> end
>
> class Test
> def run
> d=0
> 1000000000.downto(1) {
> d = d + 1
> }
> return d
> end
>
> inline(:Ruby) do |builder|
> builder.optimize :run
> end
> end
>
> puts Test.new.run
>
> $ time ruby t.rb
> 1000000000
>
> real 0m3.118s
> user 0m2.670s
> sys 0m0.050s
>
> $ cat t.cs
> using System;
>
> class Bench {
> public static void Main() {
> double d = 0;
>
> for (int i = 0; i < 1000000000; i++) {
> d = d + i;
> }
>
> Console.WriteLine(d);
> }
> }
>
> $ mcs t.cs
> Compilation succeeded
>
> $ time mono t.exe
> 4.99999999067109E+17
>
> real 0m37.692s
> user 0m34.540s
> sys 0m0.040s

The kind of magnitude in difference that the OP cited is certainly
something to worry about, performance-wise. A couple seconds here or
there in large operations is OK, of course. I'm not going to argue
against it if someone comes up with a Ruby implementation that runs
as fast as native C, but in general Ruby's performance is well above
adequate. If one finds a serious bottleneck, it may first be possible
to be solved simply by rewriting the Ruby. That failing, dropping
down to Inline/Ruby2C/C will certainly remove the problem--and the
two former with relative ease since one doesn't have to actually
write C.

Here Mr. Sibilev succintly isolated the bit of code that was assessed
to be a candidate for lower-level implementation for performance
enhancement and enhanced its performance.

> Cheers,
> Kent.

E

> On Feb 5, 2005, at 10:05 PM, Michael Gebhart wrote:
>
> > Hi,
> >
> > because of my interest in mono and ruby I have done a small benchmark.
> > These are the results:
> >
> > Mono Code:
> >
> > using System;
> >
> > class Bench {
> > public static void Main() {
> > double d = 0;
> >
> > for (int i = 0; i < 1000000000; i++) {
> > d = d + i;
> > }
> >
> > Console.WriteLine(d);
> > }
> >
> > Needs 10.8 Seconds.
> >
> >
> > In Ruby:
> >
> > d=0
> > 1000000000.times {
> > d = d + 1
> > }
> >
> > puts d
> >
> >
> > Needs: 8 minutes and 20 seconds.
> >
> >
> > Does not look very good :( Is there a possibility to tune my
> > ruby-program,
> > to be as fast as mono?
> >
> > Greetings
> >
> > Mike
> >
>
>
>



12 Answers

moma

2/6/2005 9:55:00 AM

0

E S wrote:
>>Lähettäjä: Kent Sibilev <ksibilev@bellsouth.net>
>>Aihe: Re: Benchmark Mono - Ruby
>>
>>Consider this 'tuning':

<snip>

> The kind of magnitude in difference that the OP cited is certainly
> something to worry about, performance-wise. A couple seconds here or
> there in large operations is OK, of course. I'm not going to argue
> against it if someone comes up with a Ruby implementation that runs
> as fast as native C, but in general Ruby's performance is well above
> adequate. If one finds a serious bottleneck, it may first be possible
> to be solved simply by rewriting the Ruby. That failing, dropping
> down to Inline/Ruby2C/C will certainly remove the problem--and the
> two former with relative ease since one doesn't have to actually
> write C.
>
> Here Mr. Sibilev succintly isolated the bit of code that was assessed
> to be a candidate for lower-level implementation for performance
> enhancement and enhanced its performance.
>
>

Source code in Mono (as in the Microsoft .Net tool) is first
->Compiled into a byte code (CLI, Common Language Infrastructure),
--> And CLI code is compiled by JIT (Just in Time Compiler) into
machine code.

So the first run is rather slow, but subsequent calls should hasten.

CLI spesification:
http://www.ecma-international.org/publications/standards/Ec...

So it's not fair to compare Ruby's runtime against Mono or .Net.

---------------------------
RUBY needs a Parrot !

Parrot will be a "common language runtime" for dynamic languages such as
Ruby, Python and Perl. It will be a competitor to (ecma's)CLI.

Parrot will probably implement a JIT too.

Parrot project
http://www.parrotcode.org/docs/...

http://www.linux-mag.com/2003-04/parr...
Page-5 has some explanation why implementing a new 'Parrot' and not
targeting the existing (ecma)CLI and Java VM.

+ Dynamic type systems in Python/Ruby/Perl are too complex for (ecma's)
frigid CLI spec!
----------------------------

But I would like to see some official comparison between PYTHON and
RUBY. Have u seen any?


// moma
http://www.futuredesktop.org/OpenO...
http://www.futuredesktop.org/how...

gabriele renzi

2/6/2005 10:59:00 AM

0

moma ha scritto:

> ---------------------------
> RUBY needs a Parrot !
>
> Parrot will be a "common language runtime" for dynamic languages such as
> Ruby, Python and Perl. It will be a competitor to (ecma's)CLI.

we don't "need it", imo. It would be a really nice thing, but not
definitely necessary.

> Parrot will probably implement a JIT too.

so should rubydium and yarv.

<snip>
> + Dynamic type systems in Python/Ruby/Perl are too complex for (ecma's)
> frigid CLI spec!
> ----------------------------
>
> But I would like to see some official comparison between PYTHON and
> RUBY. Have u seen any?

there are plenty, please google for them or for "ruby eye for the python
guy", it is a kind of permathread.

Stefan Lang

2/6/2005 11:11:00 AM

0

moma wrote:

> ---------------------------
> RUBY needs a Parrot !
>
> Parrot will be a "common language runtime" for dynamic languages such as
> Ruby, Python and Perl. It will be a competitor to (ecma's)CLI.
>
> Parrot  will probably implement a JIT too.

AFAIK they are already working on it.
They also care about bytecode, threading, unicode etc.

>
> Parrot project
> http://www.parrotcode.org/docs/...
>
> http://www.linux-mag.com/2003-04/parr...
> Page-5 has some explanation why implementing a new 'Parrot' and not
> targeting the existing (ecma)CLI and Java VM.
>
> + Dynamic type systems in Python/Ruby/Perl are too complex for (ecma's)
> frigid CLI spec!
> ----------------------------

Ville Mattila

2/6/2005 12:51:00 PM

0

moma <moma@example.net> writes:
> So it's not fair to compare Ruby's runtime against Mono or .Net.

I agree it is pointless to compare apples to oranges.

There similar benchmark data for YARV (the ruby VM project). Here
ruby has equal performance against MONO. See for example:
http://rubyforge.org/pipermail/yarv-devel/2005-February/t...
>
> ---------------------------
> RUBY needs a Parrot !

Well, YARV is doing quite many things already. Unfortunately all
the intersting information is in japanese.


- Ville

Alexander Kellett

2/6/2005 12:58:00 PM

0

On Feb 6, 2005, at 11:00 AM, moma wrote:
> + Dynamic type systems in Python/Ruby/Perl are too complex for
> (ecma's) frigid CLI spec!

this is FUD

Alex

Richard Dale

2/6/2005 1:31:00 PM

0

Alexander Kellett wrote:

> On Feb 6, 2005, at 11:00 AM, moma wrote:
>> + Dynamic type systems in Python/Ruby/Perl are too complex for
>> (ecma's) frigid CLI spec!
I think dynamic type systems, such as in ruby, are easier to understand and
simpler than static typing systems. The type model for C++ is incredibly
complex, yet the CLI handles a large subset of C++ quite well.

> this is FUD
Where are open classes, meta classes, and dynamic despatch on class methods
in the CLI?

Instead you can't add behaviour to existing classes, it has static methods
instead of class methods and classes aren't first class instances. How can
you work round those problems? For instance, you would need two C# style
CLI classes for every ruby one for a start; one as the ordinary class, and
one to act as a metaclass. Once you go to those lengths is it really true
to say that ruby and C# are sharing the same class model?

I've read that the Iron Python guy that Microsoft hired, is pleased with the
progress he has made, and last I heard he was tackling the problem of
static methods, being static. But to me, that doesn't mean that the CLI was
designed for dynamic languages, or that it's a particularly good place to
start.

-- Richard

Alexander Kellett

2/6/2005 2:28:00 PM

0

On Feb 6, 2005, at 2:35 PM, Richard Dale wrote:
> I've read that the Iron Python guy that Microsoft hired, is pleased
> with the
> progress he has made, and last I heard he was tackling the problem of
> static methods, being static. But to me, that doesn't mean that the
> CLI was
> designed for dynamic languages, or that it's a particularly good place
> to
> start.

i don't care about interoperability though :)
and mono / .net optimize low level code extremely
well. so, its enough :)

Alex

Glenn Parker

2/6/2005 3:49:00 PM

0

Ville Mattila wrote:
> moma <moma@example.net> writes:
>
>>So it's not fair to compare Ruby's runtime against Mono or .Net.
>
> I agree it is pointless to compare apples to oranges.
>
> There similar benchmark data for YARV (the ruby VM project). Here
> ruby has equal performance against MONO. See for example:
> http://rubyforge.org/pipermail/yarv-devel/2005-February/t...

I think the OP makes a valid point, if only because the performance
difference is measured in multiple orders of magnitude. In general,
Perl and Python do not do nearly so poorly in such comparisons. All
this equivocation about how Ruby does well enough on real tasks is just
defensive posturing. The fact is, Ruby is remarkably slower for many
common tasks, and it can take a clever hand to isolate and eliminate
Ruby performance bottlenecks. Resorting to inline/embedded code in
another language is simply a bald concession of the point, not a proof
that Ruby is doing OK.

The few benchmarks posted by the YARV folks hint that pure Ruby
performance could be much, much better. I think this may become the
single most critical factor in the acceptance of Ruby. Right now, Ruby
still looks more like an academic project than a production system.
It's lovely to look at, but it's lacking raw power.

Based on languages with similar features, I would have to say there is
plenty of room for improvement. Perl and Python have all been though
the same arguments before. Every interpreted language eventually
reaches a performance threshold where it becomes necessary and practical
to drop into a compiled language. The problem is that the Ruby
threshold is quite low.

I can develop beautiful solutions in Ruby, but if the Ruby performance
penalty is drastic enough, all the language purity in the world won't
pay for the extra hardware I need to make Ruby a profitable choice.

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoi...

Alexander Kellett

2/6/2005 4:06:00 PM

0

On Feb 6, 2005, at 4:48 PM, Glenn Parker wrote:
> I can develop beautiful solutions in Ruby, but if the Ruby performance
> penalty is drastic enough, all the language purity in the world won't
> pay for the extra hardware I need to make Ruby a profitable choice.

check out the performance of beautiful code in python or perl.
afaik, ruby is much faster.

Alex

Eric Hodel

2/6/2005 7:15:00 PM

0

On 06 Feb 2005, at 05:35, Richard Dale wrote:

> Alexander Kellett wrote:
>
>> On Feb 6, 2005, at 11:00 AM, moma wrote:
>>> + Dynamic type systems in Python/Ruby/Perl are too complex for
>>> (ecma's) frigid CLI spec!
> I think dynamic type systems, such as in ruby, are easier to
> understand and
> simpler than static typing systems. The type model for C++ is
> incredibly
> complex, yet the CLI handles a large subset of C++ quite well.
>
>> this is FUD
> Where are open classes, meta classes, and dynamic despatch on class
> methods
> in the CLI?

Where are open classes, meta classes, and dynamic dispatch on class
methods in C?

> Instead you can't add behaviour to existing classes, it has static
> methods
> instead of class methods and classes aren't first class instances. How
> can
> you work round those problems? For instance, you would need two C#
> style
> CLI classes for every ruby one for a start; one as the ordinary class,
> and
> one to act as a metaclass. Once you go to those lengths is it really
> true
> to say that ruby and C# are sharing the same class model?

C doesn't even have classes! You'd have to write your own classes by
hand in C!

> I've read that the Iron Python guy that Microsoft hired, is pleased
> with the
> progress he has made, and last I heard he was tackling the problem of
> static methods, being static. But to me, that doesn't mean that the
> CLI was
> designed for dynamic languages, or that it's a particularly good place
> to
> start.

If that guy is having so many problems, porting Ruby to C to interact
with C libraries will be impossible!

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04