On 21 Sep 1999, Marcin 'Qrczak' Kowalczyk wrote:
> Sat, 18 Sep 1999 00:06:37 +0200 (MET DST), Juergen Pfitzenmaier
><[EMAIL PROTECTED]> pisze:
>
> > I dont't care very much how fast a program runs. I care about how
> > long it takes me to write it. If you take a programming task of
> > reasonable complexity you will finish *months* earlier using a
> > --good-- functional language instead of C++.
> >
> > Use a functional language and buy a faster computer with the saved
> > money/time.
>
> I have to care how fast my programs run. I like writing in Haskell
> very much, it's my favorite general-purpose language, but one of the
> biggest weak points of Haskell for me is poor efficiency (at least
> with ghc, I don't know how fast are other compilers). I wonder whether
> this is the issue of Haskell itself or the compilers, I wonder if I
> can expect things to go better in future.
Hear, hear. Sometimes the problem that you're working on requires such
a lot of computation (e.g., typical image processing stuff) that no
savings from reduced writing time can by a machine fast enough to
compensate for the slow-down. And if you're in research where you need
to scrutinise the results of `prototypes' (this isn't quite the word
because it implies that once you've produced it you've ironed out almost
all the problems & issues and are ready to build the `final system') to
figure out why the algorithm isn't working on real data and how to improve
it.
I'm quite open to arguments that maybe you can't
make a functional language that's as nice as Haskell (features like lazy
evaluation, nice type classes, etc) that's also able to `really hammer
until it's totally flat' functional code that implements heavily numerical
algorithms. However I'd argue that this is still an area where a
functional language which was standard, widely used and compilable into
very very efficient code would be of great benefit to many people who work
on simulation, image processing problems, control systems, etc. (So I'm
happy for the Haskell people to say `We can't make
computation intensive programming better because it'd screw up stuff we do
well now' but not that `development time shrinkage compensates for
run-time growth'.)
> I would be much more happy if Haskell could be compiled to a more
> efficient code. "Only 10 times slower than C" may be unacceptable.
> Sometimes the speed doesn't matter, sometimes it does. It's not fun
> to use a worse language only because a better one is too slow.
The thing that's more annoying is that there seems to be no _standard_
ways of indicating that a certain small patch of the code is the
metaphorical `inner loop' and that the compiler should try anything and
everything, probably including exhaustive search of exponential search
spaces, to generate good code for it. I know that you can twiddle the
optimisation with pragmas in ghc files, but that's ad-hoc and doesn't
really make the fanatically insane optimization steps that generating
efficient computation-intensive code from declarative languages seems to
demand.
___cheers,_dave______________________________________________________
email: [EMAIL PROTECTED] "He'd stay up all night inventing an
www.cs.bris.ac.uk/~tweed/pi.htm alarm clock to ensure he woke early
work tel: (0117) 954-5253 the next morning"-- Terry Pratchett
