can a lazy language give fast code?Fair answer.

[Scott J.]

Hi,

I don't think I have got a fair answer to my questions regarding these
(silly?) benchmarks. I cannot write the programs with the unboxed "things",
but I have both the Ocaml compiler and the latest Glasgow compiler installed
on my windows XP machine. So, if someone sends the programs I'll type it in
and let you know these results. I don't want to be impolite : the fact that
I am on this list proves that I am seriously interested in the elegance of
Haskell. But I am searching a language to program in it: I think e.g. to a
front end of the Lout typesetting program. Also I have the impression that
such fancy things as HOpenGL are not for windows because of the GTK
bindings. It seems that I have to move to a Linux OS.

Regards

John Scott


----- Original Message -----
From: "D. Tweed" <tweed@compsci.bristol.ac.uk>
To: "Andrew J Bromage" <ajb@spamcop.net>
Cc: <haskell-cafe@haskell.org>
Sent: Wednesday, July 31, 2002 10:59 AM
Subject: Re: can a lazy language give fast code?


> On Wed, 31 Jul 2002, Andrew J Bromage wrote:
>
> > 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.
>
> I don't disagree at all with your conclusion that there are many factors
> other than throughput that a programmer wants to know and trade-off when
> choosing a language. It's in saying this is warranted by `almost all'
> processes being bound by things other than throughput which may be true in
> the average sense, but I don't think that all programmers have almost all
> their programming tasks being dominated by something other than raw
> throughput but rather there are sets of programmers who have all of the
> tasks being dominated by the need something else (robustness, say) and
> some who have all their tasks being dominated by the need for raw
> throughput. To an extent, I'm being pedantic but I do think it's important
> when re-thinking benchmarks to recognise that it's a diverse world of
> programming out there and ideally we want programmers to be able to
> perform comparisons between languages using the criteria that matter to
> them (and some may validly value throughput) rather than to change from
> measuring on only one variable (throughput) to measuring on a different
> variable but still only one variable.
>
> > 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.
>
> This is a perfect example of where using an average is pretty misleading:
> my desktop machine spends a maybe half of its time doing essentially
> nothing since my thinking time as I write programs and papers is long
> enough that the text editor, etc, spends most of its time waiting on
> input. The other half the time it's running image processing code which is
> essentially CPU bound, so it's running at close to 100% processor
> utilisation. But (even one of the robust-statistics definitions of) the
> average would say my machine is using about half the processor power at
> any given time instant. Clearly this isn't what's happening, there's
> actually two regimes of operation which it switches between.
>
> You make very good points in what I've snipped below, again it's just
> the use of `most' in a way that implies (to me) taking an average as
> the representative of what everyone has to deal with that I `disagree
> with'.
>
> [snip]
> > > 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?
>
> Interesting thought, particularly if the judges announced changes to what
> the problem to be solved was half-way through :-)
>
> ___cheers,_dave_________________________________________________________
> www.cs.bris.ac.uk/~tweed/  |  `It's no good going home to practise
> email:tweed@cs.bris.ac.uk  |   a Special Outdoor Song which Has To Be
> work tel:(0117) 954-5250   |   Sung In The Snow' -- Winnie the Pooh
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>