[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 2:33:00 PM

> 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/Ec...
>
> 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/...
>
> 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!
> ----------------------------

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
> http://www.futuredesktop.org/OpenO...
> http://www.futuredesktop.org/how...

E
10 Answers

Ville Mattila

2/7/2005 6:39:00 AM

0

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

Alexander Kellett

2/7/2005 8:49:00 AM

0

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.

Alex

Ville Mattila

2/7/2005 8:59:00 AM

0

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

Alexander Kellett

2/7/2005 9:16:00 AM

0

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?

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

Alex

Adrian Howard

2/7/2005 3:51:00 PM

0

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.

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

bruno modulix

2/7/2005 5:48:00 PM

0

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('@')"
--

bruno modulix

2/7/2005 5:50:00 PM

0

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('@')"
--

Alexander Kellett

2/7/2005 6:37:00 PM

0

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

i'm working on that for ruby :P

Alex

Ryan Davis

2/7/2005 7:06:00 PM

0


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.

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.

--
ryand-ruby@zenspider.com - Seattle.rb -
http://www.zenspider.com/...
http://blog.zens... - http://rubyforge.org/proje...

Kaspar Schiess

2/8/2005 12:59:00 PM

0

(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