[Haskell-cafe] Hugs/nhc getting progressively slower

[Neil Mitchell]

Hi

> > Could we have a collective thought, and decide whether we wish to
> > either kill off all compilers that don't start with a G, or could
> > people at least do minimal benchmarking on Hugs? I'm not quite sure
> > what the solution is, but it probably needs some discussion.
>
> I don't think doing minimal benchmarking on hugs will help at all unless
> we are prepared to act on it and I'm pretty sure anything we do to
> improve hugs performance will be detrimental to the GHC performance.

#ifdef? Malcolm has a ByteString implementation that runs much faster
under nhc, and I suspect would also run faster under Hugs. Why not
have a big #ifdef around the difference?

> With hugs/yhc/nhc I assume the optimisation technique is simply to
> minimise the number of primitive reduction steps. This is really totally
> different. I don't see any obvious way of reconciling the two in a
> single implementation of an interface. Having totally different
> implementations of an interface for different Haskell systems is an
> option though it has obvious disadvantages.

I can see that two implementations are undesirable, but at the moment
people have a choice: to write fast GHC and slow Hugs (ByteString), or
to write slow GHC and fast Hugs (String). If we could make ByteString
the "right answer" always, then I think its a much nicer choice. For
the particular case of ByteString, type ByteString=String means you
roughly import Data.List - not that much additional work or
maintenance.

> So I don't know what to do. We're not stopping out quest for high
> performance idiomatic code because it doesn't play nicely with
> interpreters.

Indeed, and you shouldn't! Your quest for nice idiomatic code has
saved countless programmers from low-level IO prodding, and for that
we salute you! However, if you could at least give a nod in the
direction of Hugs, even if you get to 50% slower than before, it keeps
Hugs at least useable with the new API's.

Thanks

Neil