From: Austin Ziegler <austin@...>
Date: 2002-12-16T21:56:12+09:00
Subject: Re: Ruby slow??

On Mon, 16 Dec 2002 15:11:17 +0900, Bulat Ziganshin wrote:
> Hello Austin,
> Sunday, December 15, 2002, 6:32:29 PM, you wrote:
>>> YS> Slowness is an implementation issue, not to be confused with
>>> YS> the language that is implemented.
>> really?
>AZ> Really. I've seen C/C++ programs which perform abominably
>AZ> because of (1) poor implementation (gcc/g++ are among the
>AZ> slowest implementations available for any given platform)
> really? :)

Really. On Windows, gcc/g++ are slower than any other compiler
available; this is also true on Solaris and HP-UX. IIRC, for Linux,
gcc/g++ are also slower than Kylix/C++ and the Intel C++ compiler.

> AZ> and (2) poor use of the language's facilities.
> please don't change the theme

This isn't changing the theme. There are many ways to do things in
almost all languages, but not all of them will be efficient. This
was illustrated here recently by the tweaking of some NArray code to
use the facilities offered by the NArray extension itself, resulting
in a *significant* performance boost.

> AZ> I've also seen PL/SQL programs (often considered a "slow"
> AZ> language) which rival or best well-written C/C++ programs in
> AZ> performance for particular tasks because it is better suited
>                     ^^^^^^^^^^^^^^^^ ditto - don't switch to
>                     another theme
> AZ> to the nature of the tasks in question.

Again, this isn't a change of theme. To use PL/SQL as an example,
the language is a general purpose programming language. Like Ruby
and Perl, it has one implementation (I am discounting JRuby for now,
as it doesn't seem to be *quite* feature-complete, although it may
be usable.) However, for numeric tasks, PL/SQL isn't the language
you're going to want to use -- the implementation isn't tuned to
that, although nothing in the language prevents an implementation
from being "good" at numeric computation (it's an Ada derivative).
With database-oriented data manipulation tasks, however, PL/SQL will
outperform C/C++ in most cases.

Yes, sometimes language features will be slow regardless of the
implementation; but before you claim that something is slow because
of a language feature, you need to make sure that (1) you have used
the optimal implementation within the language, and (2) that it
isn't simply a performance problem with the implementation itself.
(2) is easier if you have multiple implementations available.

-austin
-- Austin Ziegler, austin@halostatue.ca on 2002.12.16 at 07.45.56