[Haskell-cafe] Hugs/nhc getting progressively slower

[Duncan Coutts]

On Tue, 2007-05-01 at 20:37 +0100, Neil Mitchell wrote:
> Hi,
> 
> I like to develop on Hugs, because its a nice platform to work with,
> and provides WinHugs, auto-reloading, sub-second compilation etc.
> Unfortunately some of the newer libraries (ByteString/Binary in
> particular) have been optimised to within an inch of their lives on
> GHC, at the cost of being really really slow on Hugs.
> 
> Taking the example of Yhc Core files, which are stored in binary.
> Using a very basic hPutChar sequence is miles faster (10x at least)
> than all the fancy ByteString/Binary trickery.
> 
> Taking the example of nobench, Malcolm told me he reimplemented
> ByteString in terms of [Char] and gained a massive performance
> increase (6000x springs to mind, but that seems way too high to be
> true) using nhc.

That does not surprise me.

> 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.

We're optimising for totally different sets of primitives. With GHC
we're optimising for machine code and thinking about branch prediction
and cache misses. We're also writing high level combinators that are
quite inefficient to execute directly but we rely on inlining and
rewrite rules to combine then expand them to efficient low level code.

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.

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.

Duncan