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


 

Forums >

comp.lang.ruby

python/ruby benchmark.

\"</script>

6/9/2005 3:16:00 PM

I took a look at
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=python&so...
and found the tests on ruby disapointing :(.
So what I'm asking for is a link to some ruby-specific optimisation tips.

--
Regards, Groleo!

# touch universe
# chmod +x universe
# ./universe
75 Answers

gabriele renzi

6/9/2005 3:27:00 PM

0

"</script> ha scritto:
> I took a look at
> http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=python&so...
> and found the tests on ruby disapointing :(.
> So what I'm asking for is a link to some ruby-specific optimisation tips.

a simple thing: do the most normal thing instead of writing code in ruby
that is innatural, i.e. instead of rewritine an heapsort by hand, use
the builtin sort/sort!/sort_by routines. Instead of writing a random
function by hand, use the builtin rand().

If you really feel ruby (or python) is slow you can act later optimizing
it, not doing it before you ever need to be faster. "premature
optimization is the root of all evil", people say.

Glenn Parker

6/9/2005 3:43:00 PM

0

> So what I'm asking for is a link to some ruby-specific optimisation tips.

Avoid creating new objects, e.g. re-use strings and arrays, or modify
them in place when possible, especially large ones.

Use built-in iterators as much as possible.

Pray for YARV! :)

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

Ryan Leavengood

6/9/2005 3:55:00 PM

0

gabriele renzi said:
>
> If you really feel ruby (or python) is slow you can act later optimizing
> it, not doing it before you ever need to be faster. "premature
> optimization is the root of all evil", people say.

I heartily agree with this, and it doesn't just apply to Ruby and Python,
but every language. I used to find myself wasting a lot of time trying to
come up with some clever "fast" solution, when the reality is in almost
every conceivable case the "dumb" solution does the job very fast on
modern machines.

But Python does seem to be faster in most cases, and this is because the
Python interpreter uses bytecode while the current Ruby interpreter just
interprets the AST tree after parsing. But there is currently a lot of
impressive work going into a Ruby bytecode interpreter, called YARV:
http://www.atdot...

You can expect the Ruby interpreter that uses YARV to be 3 or 4 times
faster (I've compiled it and ran the benchmarks.)

Ryan

Vincent Foley

6/9/2005 3:59:00 PM

0

As Gabriele mentionned, they implement a lot of stuff that is done in C
in Ruby. Also, the tests must use the exact same algorithm, so this
disadvantages Ruby is some situations. I say the test should compare
same algorithms, but also the one best suited to the language.

Lothar Scholz

6/9/2005 4:23:00 PM

0

Hello gabriele,

gr> "</script> ha scritto:
>> I took a look at
>> http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=python&so...
>> and found the tests on ruby disapointing :(.
>> So what I'm asking for is a link to some ruby-specific optimisation tips.

gr> a simple thing: do the most normal thing instead of writing code in ruby
gr> that is innatural, i.e. instead of rewritine an heapsort by hand, use
gr> the builtin sort/sort!/sort_by routines. Instead of writing a random
gr> function by hand, use the builtin rand().

Sorry you don't understand this benchmark. It is there to do this
algorithms to compare the basic data operations.

The benchmark is not useable to compare compiled languages with
interpretered, but comparing python with ruby is a valid comparision.

And that ruby is so worse then python is a real problem. If you still
try to deny this, then you have a real mental problem.

If ruby is 9 times slower then python in for example function calling intensive
code that means that ruby will slow down your development time a lot
as it forces you to use optimized code or even C code much more often
then python.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

Kent Sibilev

6/9/2005 4:41:00 PM

0

Java is an order of magnitude faster than Ruby. The development of a
web app using Rails is an order of magnitude faster than the
development of a similar web app using Struts/Hibernate frameworks.
There are other factors that can slow down your development time
besides the speed of your language of choice.

Cheers,
Kent
Just another guy with huge mental problems.

On 6/9/05, Lothar Scholz <mailinglists@scriptolutions.com> wrote:
> Hello gabriele,
>
> gr> "</script> ha scritto:
> >> I took a look at
> >> http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=python&so...
> >> and found the tests on ruby disapointing :(.
> >> So what I'm asking for is a link to some ruby-specific optimisation tips.
>
> gr> a simple thing: do the most normal thing instead of writing code in ruby
> gr> that is innatural, i.e. instead of rewritine an heapsort by hand, use
> gr> the builtin sort/sort!/sort_by routines. Instead of writing a random
> gr> function by hand, use the builtin rand().
>
> Sorry you don't understand this benchmark. It is there to do this
> algorithms to compare the basic data operations.
>
> The benchmark is not useable to compare compiled languages with
> interpretered, but comparing python with ruby is a valid comparision.
>
> And that ruby is so worse then python is a real problem. If you still
> try to deny this, then you have a real mental problem.
>
> If ruby is 9 times slower then python in for example function calling intensive
> code that means that ruby will slow down your development time a lot
> as it forces you to use optimized code or even C code much more often
> then python.
>
>
> --
> Best regards, emailto: scholz at scriptolutions dot com
> Lothar Scholz http://www.ru...
> CTO Scriptolutions Ruby, PHP, Python IDE 's
>
>
>
>

Dibya Prakash

6/9/2005 6:03:00 PM

0

Hi,
I definitely agree.Only feature of a particular programming language
cannot determine the speed of software.Other factors are also
crucially important.
I didnot know about YARV,but gr8 that I came to know it thru u
people.I'll surely check it out.

Bye
Dibya Prakash
Happy coding

On 6/9/05, Kent Sibilev <ksruby@gmail.com> wrote:
> Java is an order of magnitude faster than Ruby. The development of a
> web app using Rails is an order of magnitude faster than the
> development of a similar web app using Struts/Hibernate frameworks.
> There are other factors that can slow down your development time
> besides the speed of your language of choice.
>
> Cheers,
> Kent
> Just another guy with huge mental problems.
>
> On 6/9/05, Lothar Scholz <mailinglists@scriptolutions.com> wrote:
> > Hello gabriele,
> >
> > gr> "</script> ha scritto:
> > >> I took a look at
> > >> http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=python&so...
> > >> and found the tests on ruby disapointing :(.
> > >> So what I'm asking for is a link to some ruby-specific optimisation tips.
> >
> > gr> a simple thing: do the most normal thing instead of writing code in ruby
> > gr> that is innatural, i.e. instead of rewritine an heapsort by hand, use
> > gr> the builtin sort/sort!/sort_by routines. Instead of writing a random
> > gr> function by hand, use the builtin rand().
> >
> > Sorry you don't understand this benchmark. It is there to do this
> > algorithms to compare the basic data operations.
> >
> > The benchmark is not useable to compare compiled languages with
> > interpretered, but comparing python with ruby is a valid comparision.
> >
> > And that ruby is so worse then python is a real problem. If you still
> > try to deny this, then you have a real mental problem.
> >
> > If ruby is 9 times slower then python in for example function calling intensive
> > code that means that ruby will slow down your development time a lot
> > as it forces you to use optimized code or even C code much more often
> > then python.
> >
> >
> > --
> > Best regards, emailto: scholz at scriptolutions dot com
> > Lothar Scholz http://www.ru...
> > CTO Scriptolutions Ruby, PHP, Python IDE 's
> >
> >
> >
> >
>
>

Lothar Scholz

6/9/2005 6:07:00 PM

0

Hello Kent,

KS> Java is an order of magnitude faster than Ruby. The development of a
KS> web app using Rails is an order of magnitude faster than the
KS> development of a similar web app using Struts/Hibernate frameworks.
KS> There are other factors that can slow down your development time
KS> besides the speed of your language of choice.

If i can't use the language because it is to slow to solve the problem
then the development time doesn't matter. There are just too many
problem domains left where you can't ignore it.

But we all hope and pray for YARV.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

Gavri Fernandez

6/9/2005 7:44:00 PM

0

On 6/10/05, Ryan Leavengood <mrcode@netrox.net> wrote:

> I would like to hear some more specifics on these problem domains. I'm not
> trying to start an argument, I'm just wondering if the problems you are
> thinking of are just not appropriate for any interpreted language.

So you're saying that when the performance requirements crosses a
certain threshold, interpreted languages should not be used.
The idea here is that if Ruby is faster, that threshold where should a
switch needs to be made is shifted.

--
Gavri
http://livejournal.com/us...

Ryan Leavengood

6/9/2005 8:15:00 PM

0

Gavri Fernandez said:
>
> So you're saying that when the performance requirements crosses a
> certain threshold, interpreted languages should not be used.
> The idea here is that if Ruby is faster, that threshold where should a
> switch needs to be made is shifted.

Of course, and I'm all for that. I want Ruby to be as fast as possible. In
fact I have some application domains in mind I'd like to use Ruby for that
may run into this exact problem (sound processing.)

But still, at this point in the state of computing, I would not use Ruby
in certain applications:

- operating system level code.
- heavy duty 3D rendering.
- device drivers.
- any major number crunching (math, video processing, low-level image
manipulation.)

But hey, maybe with some special hardware (a Ruby Chip?), all the above
would be possible and fast with Ruby. That may be the next level of
computing: hardware accelerated high level languages.

Ryan