can a lazy language give fast code?

[Andrew J Bromage]

G'day all.

On Tue, Jul 30, 2002 at 08:14:27AM +0100, D. Tweed wrote:

> Mmm, such statements really assume that there's a sensible meaning to
> `almost always' when applied to the set of all programmers, whereas I
> think a much more realistic assumption is that `there's lots of people out
> there, all with different priorities' and present things in way which 
> lets people perform their own evaluations.

Let me clarify what I meant by that and see if you still disagree.

Realistically, _most_ new software installations today (I deliberately
ignore legacy systems etc) are not overloaded, in that there are more
"computrons" available than are required to perform the task required
of them.  Of course this is partly because when you do a new
installation, you add more than you need because you expect to grow.

Secondly, most non-embedded CPUs in the world are not overloaded
either.  Chances are for a given desktop machine, it spends most of
its waking hours waiting for the next keystroke or mouse movement.
Web developers in particular know this: For the typical case, your
application server runs at the speed of the network.

If you agree with me so far, it follows that for most _new_ software,
"throughput" is not as great a consideration as other performance
metrics, because "throughput" measures the saturation point of your
system, and most new systems don't get saturated.

Of course I'm speaking in generalities, and there are an awful lot of
situations where throughput is an issue.  I've worked in a few of those
situations before.  I'm working in that situation right now, in fact.
Throughput measures are important to have if this is the situation that
you're in.

More information is good.  Perhaps the problem is I don't trust
everyone to use the information wisely?

> The problem with language
> benchmarks is not that they `over-rate' the importance of performance but
> that they assume per se that choice of language is a single-variable
> (execution speed) optimization problem; there's no attempt to measure the
> other items in your list, most especially flexibility.

While I agree with you here, I don't even claim that language benchmarks
of this kind "over-rate" the value of performance.  I claim that they
don't measure "performance" _at_all_!  They measure (in this case) two
possible measures of performance, namely memory usage and execution
speed, but ignores factors like scalability and latency, which are IMO
often more important.

> Of more
> concern to me is, when's the last time you actually got a well specified
> computational problem and a reasonable amount of time to write a carefully
> crafted program to solve it, (particularly when you had some reassurance
> that the very specification of what to solve wouldn't change after the
> first time you ran the code :-) )?

Perhaps the ICFP contests are actually fairer as benchmarks than as
competitions?

Cheers,
Andrew Bromage