[Haskell-cafe] Re: speed: ghc vs gcc

[Claus Reinke]

>> Turning this into a ticket with associated test will:
> 
> but why you think that this is untypical and needs a ticket? ;)

Because generally ghc is doing a good-enough job. And it is doing
that because long ago, ghc hq's war cry was "if ghc generates code
that is slower than any other haskell implementation, it is a bug, and
you should file a ticket".

The failure of "avoid success at all cost" has meant shifting priorities,
and those priorities tend to imply that alternative implementations
can't keep up (not over the full range of ghc's offerings). So there is
less "internal" competition, more "other stuff" on todo lists, and good
enough just has to be good enough most of the time. 

But when it isn't, then not just people at ghc hq are still listening. And 
among all the other good stuff they keep adding, they also keep 
tweaking ghc's basics, in such a way that what would be hard to 
do now, may be easier to implement in future ghc versions. And for 
that, they need input about what they should focus on. And the 
advertised way of providing that input is the ticket tracker.

For tickets, small examples are great - they often highlight aspects
that are still present in real code, but are hard to see there (let alone
reducing complex code to small test cases that help to fix those
cases). In the particular example of unrolling, iirc, the issue was 
that ghc's internal representation does not easily lend itself to adding
some counter that would keep the very modular optimizer from
applying recursive unfoldings uselessly. Once that fundamental
problem is fixed, I am optimistic that this useful optimization will
be looked at again - if there is a ticket to remind everyone.

And if -as I suspect- lots of ghc users find themselves doing 
loop unrolling/partial recursion unfoldings by hand (worker/wrapper
for recursive functions is just such an example), they will up
the priority on that ticket. You're right that ghc hq can't be
everywhere, but they aren't the only ones who are invited to
look at those tickets. And everytime someone starts on ghc
hacking for some unrelated purpose, they need a small project
to start on - well-defined tickets have a chance there.

I'm not at all happy with Haskell optimists turning evangelists, 
but neither is it productive for Haskell pessimists to spread
their frustration. There are useful ways for both sides to 
contribute to the Haskell world, can we focus on those ways?

Claus