From: harrisj@...
Date: 2006-07-27T00:55:05+09:00
Subject: Re: For performance, write it in C

>
> Kristof Bastiaensen wrote:
>> On Wed, 26 Jul 2006 17:47:13 +0900, Peter Hickman wrote:
>>
>> > Whenever the question of performance comes up with scripting languages
>> > such as Ruby, Perl or Python there will be people whose response can
>> be
>> > summarised as "Write it in C". I am one such person. Some people take
>> > offence at this and label us trolls or heretics of the true
>> programming
>> > language (take your pick).
>> >
>> > <snip>
>>
>> Hi,
>>
>> When reading your C code, I saw that there is a lot of code that is
>> generated.  I'd be interested to see how well the C program does if
>> it can work for any size of the squares. In this case I think the
>> problem
>> is well suited for logic languages. I wrote a version in the functional
>> logic language Curry, which does reasonably well.  It will probably not
>> be
>
> Interesting ... I read somewhere that the OCaml language, while
> higher-level than C (and a functional one too), runs some programs at
> least, as fast or faster than C ...
> Not sure how true that is ...
>
> Vasudev
> http://www.dancingbison.com

You read that correctly. The problem is that nearly every benchmark I've
seen for comparing the performance of various languages has been a
repeated mathematical operation like computing a Mandelbrot Set or running
Fibonacci Sequences that all but guarantees the edge will belong to
functional languages like Haskell and OCAML or stripped-down assembly-like
languages like C (http://shootout.alioth.debian.org/debian/ for samples),
because they are best suited for straight-up number crunching. Are there
good benchmarks for OO languages? Or dynamic languages? Are there good
benchmarks that could actually measure the types of uses I need, where I'm
building a web front end to a DB store? I don't know about you, but my job
has never involved fractals.

I used to put faith into benchmarks like this, but now I think about
developer time and maintenance time as well. That seems to be a more
intelligent approach.

Jake