Benchmark Mono - Ruby

ruby-talk
1

Lähettäjä: moma <moma@example.net>
Aihe: Re: Benchmark Mono - Ruby

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/Ecma-335.htm

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

I think it's fair and most prudent to compare programs written in
Ruby to programs written in Whatever both for performance and their
respective capabilities.

When examining the fastest methods to get from place A to place B,
you wouldn't disqualify someone for using a car because it's 'unfair'
to those whose solutions include walking?

---------------------------
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/intro.html

http://www.linux-mag.com/2003-04/parrot_01.html
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!
----------------------------

I agree that a VM might be a good solution for Ruby. Whether that's
Parrot, YARV or something else I can't say, though I'm leaning for
a Ruby-specific one since it'd quite likely be superior to any sort
of a common bytecode.

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

// moma
    OpenOffice, the first class Office Suite for home desktop and office users - www.futuredesktop.org
    How to create a bootable installation CD for Linux - www.futuredesktop.org

E

2

E S <eero.saynatkari@kolumbus.fi> writes:

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

I think it's fair and most prudent to compare programs written in
Ruby to programs written in Whatever both for performance and their
respective capabilities.

When examining the fastest methods to get from place A to place B,
you wouldn't disqualify someone for using a car because it's 'unfair'
to those whose solutions include walking?

    No, you can choose whatever is most suitable for your needs. I just say
    that you shouldn't be surprised that interpreted language cannot compete
    with bytecode language. It's meanigfull to complaint that ruby is slower
    than python or perl... Good expample about this is the recent CSV thread.

- Ville

3

just a technical correction, python at the
very least is already bytecode based. it just
doesn't have a very fast / jitt'ing vm.

Alex

···

On Feb 7, 2005, at 7:40 AM, Ville Mattila wrote:

    No, you can choose whatever is most suitable for your needs. I just say
    that you shouldn't be surprised that interpreted language cannot compete
    with bytecode language. It's meanigfull to complaint that ruby is slower
    than python or perl... Good expample about this is the recent CSV thread.

4

Ville Mattila wrote:

E S <eero.saynatkari@kolumbus.fi> writes:

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

I think it's fair and most prudent to compare programs written in
Ruby to programs written in Whatever both for performance and their
respective capabilities.

When examining the fastest methods to get from place A to place B,
you wouldn't disqualify someone for using a car because it's 'unfair'
to those whose solutions include walking?

    No, you can choose whatever is most suitable for your needs. I just say
    that you shouldn't be surprised that interpreted language cannot compete
    with bytecode language. It's meanigfull to complaint that ruby is slower
    than python or perl...

Just for the record, Python is compiled to bytecode... (I think Perl is too, but I wouldn't bet my favorite keyboard on this...)

···

--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
--

5

Alexander Kellett <ruby-lists@lypanov.net> writes:

···

On Feb 7, 2005, at 7:40 AM, Ville Mattila wrote:

    No, you can choose whatever is most suitable for your needs. I
just say
    that you shouldn't be surprised that interpreted language cannot
compete
    with bytecode language. It's meanigfull to complaint that ruby is
slower
    than python or perl... Good expample about this is the recent CSV
thread.

just a technical correction, python at the
very least is already bytecode based. it just
doesn't have a very fast / jitt'ing vm.

  Thanks for correction. I didn't know that. Has python always had bytecode
  or was it added recently?

- Ville

6

Perl too.

Well, I guess you could argue that it's not a linear byte code - it's compiled down to an internal tree structure which is then executed. Various modules for fiddling with it live in Perl's B:: namespace. It's certainly not interpreted at the "language" level.

Always been that way AFAIK - at least since the mid-nineties anyway, which was when I started using Perl.

Cheers,

Adrian

···

On 7 Feb 2005, at 08:48, Alexander Kellett wrote:

On Feb 7, 2005, at 7:40 AM, Ville Mattila wrote:

    No, you can choose whatever is most suitable for your needs. I just say
    that you shouldn't be surprised that interpreted language cannot compete
    with bytecode language. It's meanigfull to complaint that ruby is slower
    than python or perl... Good expample about this is the recent CSV thread.

just a technical correction, python at the
very least is already bytecode based. it just
doesn't have a very fast / jitt'ing vm.

7

Alexander Kellett wrote:

just a technical correction, python at the
very least is already bytecode based. it just
doesn't have a very fast / jitt'ing vm.

try psyco...

···

--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
--

8

(In response to news:4207a9ea$0$608$636a15ce@news.free.fr by bruno modulix)

Just for the record, Python is compiled to bytecode... (I think Perl is
too, but I wouldn't bet my favorite keyboard on this...)

Especially if your favourite keyboard is a laptop keyboard...

···

--
kaspar

code manufacture - ruby lab
www.tua.ch/ruby

9

for a long time already afaik. 1.5.x at least
included it and that was 3 years back already.

Alex

···

On Feb 7, 2005, at 10:00 AM, Ville Mattila wrote:

  Thanks for correction. I didn't know that. Has python always had bytecode
  or was it added recently?

10

i'm working on that for ruby :stuck_out_tongue:

Alex

···

On Feb 7, 2005, at 6:55 PM, bruno modulix wrote:

Alexander Kellett wrote:

just a technical correction, python at the
very least is already bytecode based. it just
doesn't have a very fast / jitt'ing vm.

try psyco...

11

Yes, technically it is, but that is done on every run, so it isn't really all that different than ruby in that regard. Python actually saves out the bytecode in a .pyo file that it'll read if newer than the corresponding .py file, so at least you can skip the compile phase. But as someone else mentioned, it doesn't JIT or do much of anything in the way of optimization, so it really is just a compile phase optimization. I think that counted for more earlier on than it does now.

···

On Feb 7, 2005, at 7:51 AM, Adrian Howard wrote:

On 7 Feb 2005, at 08:48, Alexander Kellett wrote:

just a technical correction, python at the
very least is already bytecode based. it just
doesn't have a very fast / jitt'ing vm.

Perl too.

--
ryand-ruby@zenspider.com - Seattle.rb - Seattle.rb | Home
http://blog.zenspider.com/ - http://rubyforge.org/projects/ruby2c