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


 

Forums >

comp.lang.ruby

Re: Huge performance gap

Stephen Waits

2/23/2006 10:39:00 PM

E. Saynatkari wrote:
>
> Post the code somewhere, there might be room for improvement
> in the algorithm though it will still be considerably slower.

It looks, to me, like he attached his code to the OP.

Regardless, it doesn't matter. Algorithmic improvements may help both
the C++ and Ruby versions - but it's not going to change the fact that
one is a relatively low-level language, compiled to native machine code,
and the other is an interpreted dynamic language. To compare them is
either ridiculous, or more likely in this case, simply ignorant.

--Steve
22 Answers

Yuu

2/23/2006 10:46:00 PM

0

Stephen Waits wrote:
> E. Saynatkari wrote:
>>
>> Post the code somewhere, there might be room for improvement
>> in the algorithm though it will still be considerably slower.
>
> It looks, to me, like he attached his code to the OP.

Ah, caveat forum-user!

> Regardless, it doesn't matter. Algorithmic improvements may help both
> the C++ and Ruby versions - but it's not going to change the fact that
> one is a relatively low-level language, compiled to native machine code,
> and the other is an interpreted dynamic language. To compare them is
> either ridiculous, or more likely in this case, simply ignorant.

In general, sure. Ruby will afford doing some things better
than most C++ coders would (or would bother to), so it might
be worth looking into.

Plus, if one were to get the Ruby time down to 15 seconds, it
would still be worth it even if the C++-version were cut to 0.15
seconds (mainly because it would probably take at least twice
as long to implement in C++).

> --Steve


E

--
Posted via http://www.ruby-....

Alexis Reigel

2/23/2006 10:56:00 PM

0

Stephen Waits wrote:
> E. Saynatkari wrote:
>
>>
>> Post the code somewhere, there might be room for improvement
>> in the algorithm though it will still be considerably slower.
>
>
> It looks, to me, like he attached his code to the OP.
>
> Regardless, it doesn't matter. Algorithmic improvements may help both
> the C++ and Ruby versions - but it's not going to change the fact that
> one is a relatively low-level language, compiled to native machine code,
> and the other is an interpreted dynamic language. To compare them is
> either ridiculous, or more likely in this case, simply ignorant.
>
> --Steve
>
Why should that be ridiculous or ignorant?
I stated that I was aware of the differences between interpreted and
compiled languages. But that does not change the fact that I believe
that this does not explain the performance gap. An execution time of
27.65 seconds against 0.33 seconds is not just nothing is it? It's a
factor of over 80 times. Besides, I implemented the same code in java
too, which isn't native code as well and runs in a virtual machine too,
and it executed in about the same time as c++.

Yuu

2/23/2006 11:02:00 PM

0

Alexis Reigel wrote:
> Stephen Waits wrote:
>> the C++ and Ruby versions - but it's not going to change the fact that
>> one is a relatively low-level language, compiled to native machine code,
>> and the other is an interpreted dynamic language. To compare them is
>> either ridiculous, or more likely in this case, simply ignorant.
>>
>> --Steve
>>
> Why should that be ridiculous or ignorant?
> I stated that I was aware of the differences between interpreted and
> compiled languages. But that does not change the fact that I believe
> that this does not explain the performance gap. An execution time of
> 27.65 seconds against 0.33 seconds is not just nothing is it? It's a
> factor of over 80 times. Besides, I implemented the same code in java
> too, which isn't native code as well and runs in a virtual machine too,
> and it executed in about the same time as c++.

Well, Ruby is strictly interpreted using the parse tree instead
of VM opcodes which may or may not (depending on who you ask)
make a difference. Ruby is pretty slow but usually Fast Enough(tm).

You could try to run your script on YARV[1] to see if it helps.

[1] http://atdo...


E

--
Posted via http://www.ruby-....

Marcin Mielzynski

2/23/2006 11:03:00 PM

0

Alexis Reigel wrote:
> Stephen Waits wrote:
>> E. Saynatkari wrote:
>>
>>> Post the code somewhere, there might be room for improvement
>>> in the algorithm though it will still be considerably slower.
>>
>> It looks, to me, like he attached his code to the OP.
>>
>> Regardless, it doesn't matter. Algorithmic improvements may help both
>> the C++ and Ruby versions - but it's not going to change the fact that
>> one is a relatively low-level language, compiled to native machine code,
>> and the other is an interpreted dynamic language. To compare them is
>> either ridiculous, or more likely in this case, simply ignorant.
>>
>> --Steve
>>
> Why should that be ridiculous or ignorant?
> I stated that I was aware of the differences between interpreted and
> compiled languages. But that does not change the fact that I believe
> that this does not explain the performance gap. An execution time of
> 27.65 seconds against 0.33 seconds is not just nothing is it? It's a
> factor of over 80 times. Besides, I implemented the same code in java
> too, which isn't native code as well and runs in a virtual machine too,
> and it executed in about the same time as c++.
>
>

Which version of java did you use ? Since 1.4 there is a JIT compiler so
java _IS_ compiled into native code unless you disable it explicitly.

lopex

Marcin Mielzynski

2/23/2006 11:07:00 PM

0

E. Saynatkari wrote:

>
> You could try to run your script on YARV[1] to see if it helps.
>
> [1] http://atdo...
>
>
> E
>

And turn the magic opcodes on :D

http://eigenclass.org/hiki.rb?yarv+ueber+algorithmical+op...

lopex

Logan Capaldo

2/23/2006 11:11:00 PM

0


On Feb 23, 2006, at 5:55 PM, Alexis Reigel wrote:

> Why should that be ridiculous or ignorant?
> I stated that I was aware of the differences between interpreted and
> compiled languages. But that does not change the fact that I believe
> that this does not explain the performance gap. An execution time of
> 27.65 seconds against 0.33 seconds is not just nothing is it? It's a
> factor of over 80 times. Besides, I implemented the same code in java
> too, which isn't native code as well and runs in a virtual machine
> too,
> and it executed in about the same time as c++.

Ruby's method (function) lookup is gonna be slower no matter what
because of the typing situation. That's probably the biggest hit
here. The C++ code can for the most part turns function calls into
jumps at compile time (excluding virtual methods, although even there
there is less indirection than ruby). Similarly for Java. Have you
tried running it in YARV?

William James

2/23/2006 11:12:00 PM

0


Alexis Reigel wrote:
> Stephen Waits wrote:
> > E. Saynatkari wrote:
> >
> >>
> >> Post the code somewhere, there might be room for improvement
> >> in the algorithm though it will still be considerably slower.
> >
> >
> > It looks, to me, like he attached his code to the OP.
> >
> > Regardless, it doesn't matter. Algorithmic improvements may help both
> > the C++ and Ruby versions - but it's not going to change the fact that
> > one is a relatively low-level language, compiled to native machine code,
> > and the other is an interpreted dynamic language. To compare them is
> > either ridiculous, or more likely in this case, simply ignorant.
> >
> > --Steve
> >
> Why should that be ridiculous or ignorant?
> I stated that I was aware of the differences between interpreted and
> compiled languages. But that does not change the fact that I believe
> that this does not explain the performance gap. An execution time of
> 27.65 seconds against 0.33 seconds is not just nothing is it? It's a
> factor of over 80 times. Besides, I implemented the same code in java
> too, which isn't native code

More ignorance. Java has a JIT compiler which produces
machine code.

Alexis Reigel

2/23/2006 11:31:00 PM

0

>
> More ignorance. Java has a JIT compiler which produces
> machine code.
>

Why are you being so mean? I wasn't aware of that.
I was just wondering why my results were so significantly different. All
I was asking was if someone had some explanations and comments on why
that is like that. I got some nice and reasonable answers, but I got
some unkind answers too... I didn't ask for bitter and unconstructive
comments. Did I somehow offend your honor? I did not say that ruby is
crap compared to c++ or java. I find ruby is an absolute fantastic
language. I was just surprised about my results.

Stephen Waits

2/23/2006 11:55:00 PM

0

Alexis Reigel wrote:
> >
>> More ignorance. Java has a JIT compiler which produces
>> machine code.
>
> Why are you being so mean? I wasn't aware of that.

Calm down Alexis.. nobody is being mean. When someone doesn't
understand something because they aren't educated about it, they are
considered ignorant. There's nothing wrong with that.

Enough people have explained the reasons for the performance gap by this
point that it should be clear. If you still need more help with this
issue, please let us know.

Meanwhile, I'm certain that none of us intended to be mean, or otherwise
attack you in any way.

--Steve

Daniel Nugent

2/24/2006 2:41:00 AM

0

Yikes! What's with the snarkiness guys?

One thing you should consider in particular, Alexis, is the
performance impact Ruby's objects are causing. In your C++ code, it
appears that everything's running on the stack. The Ruby interpreter
is allocating and disposing of every object in the Ruby code onto the
heap and running garbage collection on them.

It might be worth attempting to at least change the code into
accepting Sodoku puzzles of any size (bear in mind I haven't looked at
Sodoku solvers very much myself, so this may have all sorts of
technical challenges I'm unaware of).

On 2/23/06, Stephen Waits <steve@waits.net> wrote:
> Alexis Reigel wrote:
> > >
> >> More ignorance. Java has a JIT compiler which produces
> >> machine code.
> >
> > Why are you being so mean? I wasn't aware of that.
>
> Calm down Alexis.. nobody is being mean. When someone doesn't
> understand something because they aren't educated about it, they are
> considered ignorant. There's nothing wrong with that.
>
> Enough people have explained the reasons for the performance gap by this
> point that it should be clear. If you still need more help with this
> issue, please let us know.
>
> Meanwhile, I'm certain that none of us intended to be mean, or otherwise
> attack you in any way.
>
> --Steve
>
>
>


--
-Dan Nugent