n Mon, Oct 11, 2004 at 12:22:13PM +0100, Malcolm Wallace wrote:
> "karczma" <[EMAIL PROTECTED]> writes:
>
> > > I think the Haskell community has just been a bit slower in understanding
> > > the importance of strictness :)
> >
> > OK, I admit that I will never understand these complaints about the
> > inefficiency of non-strict computations, since what I *require* in most
> > of my work is laziness.
>
> Indeed, I have to agree. I have spent some time fiddling with
> programs for the Language Shootout which started this conversation,
> and by far most of the effort was spent in deliberately making code
> /slower/ by introducing strictness.
>
> For instance, the shootout often requires that a task be carried out N
> times, to make the timings large enough to measure. In all the naive
> Haskell implementations of these tasks, Haskell wins by a mile. Why?
> Because the language quite reasonably says that if you multiply
> a matrix by itself N times, but only use the result of the last
> multiplication, well it is jolly well not going to bother computing
> the first (N-1) identical multiplications - what a waste of time!
>
> So is it fair to compare the default lazy Haskell solution with all
> the eager solutions out there that laboriously do all this unnecessary
> work? Apparently not, so we have gone to all kinds of trouble to slow
> the Haskell solution down, make it over-strict, do the work N times,
> and thereby have a "fair" performance test. Huh.
I think the naive way is perfectly fair. If haskell has to live with
the disadvantages of lazy evaluation, it only makes sense we should be
able to take advantage of the advantages. The fact that haskell doesn't
have to compute those intermediate values is a real advantage which
should be reflected in the results IMHO.
John
--
John Meacham - ârepetae.netâjohnâ
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
