[Haskell-cafe] Re[4]: [Haskell] Google Summer of Code

[Claus Reinke]

>> > Check out what GHC is doing these days, and come back with an analysis
>> > of what still needs to be improved.  We can't wait to hear!
>> can you point me to any haskell code that is as fast as it's C
>> equivalent?
> You should do your own benchmarking!

Please, folks! This is hardly helpful.

It isn't difficult to find examples of fast Haskell code by Don, nor
is it difficult to find benchmarking and analyses of slow GHC-generated 
code by Bulat. But expecting "your" readers to search for such fragments
instead of providing direct references weakens your cases. In fact, I'm
not aware of any documents that would make a coherent argument
either way: 

- most of Don's examples focus on small bits of code where (a) it is still 
    possible to associate core output with parts of the input (making the dire
    state of tool support less of an issue) and (b) few real-life awkwardnesses 
    interfere with the optimization of pure algorithms (by which I mean code 
    artifacts such as error handling etc confusing GHC's optimization phases).

- most of Bulat's analyses refer to the via-C path, which used to be the
    fastest path, but appears to have an uncertain future (not that I'm aware
    of any claims, let alone documentation showing that the now standard 
    compilation path in GHC is at least as good as via-C used to be).

That summary is of course only based on the fragments I have chosen
to find - if you want a fairer summary, you need to provide concrete and
uptodate references!-) And if you don't want to be asked to repeat your
argument every time this thread comes up, you need to present it in easily
referenced form outside this mailing list. In particular, I would suggest that 

1. performance issues are recorded as GHC trac tickets, with test cases, 
    (there is an explicit ticket type for this) so that we could check easily 
    whether any general GHC improvements have had any effect on which 
    known bad cases. Note that performance isn't a high-priority issue
    per se at GHC HQ (due to manpower), unless it is a show-stopper
    or many users report it as important to them. Nevertheless, the issues
    should be recorded, so that we know where we stand.

2. performance wisdom is recorded on the Haskell/GHC wikis, or in
    tutorials/papers. There is a lot of information on small tricks already,
    but very little on what to do when those small tricks no longer suffice
    (eg, after one has found out that profiling lies, that core isn't easy to
    link back to source, when the code in question is not just pure and
    simple algorithm but riddled with error handling imported from libraries).

Personally, I find the situation wrt performance of GHC-generated code
very unsatisfactory, not because it isn't good (more often than not, it is),
but because there is very little help when it isn't. And the first step towards
improving that situation (eg, with tools helping to analyse core, or better
understood profiling tools, or support for by-hand application of optimization
transformation/undo/modify/retarget/replay..) is to acknowledge that there 
is a problem.

Pointing out that some experienced hackers have been through this,
and are now able to make do for themselves, is a non-solution (unless 
you want to secure consulting fees;-). Just as declarative languages allow 
us to ignore operational details until/unless they really are needed, offering
a clear path on how to specify declarative aspects of our code, so there
should be a clear path on how to specify operational details if that becomes
necessary. A path that any mildly experienced Haskeller should be
able to follow through good documentation, examples, and tools.

Claus

PS. Talking about "high-performance computing" seems slightly
    misleading in this context, if the only goal is to have code as fast
    as typical C. From what I've heard from HPC folks, generic
    compilers or generic C code are not tough benchmarks from 
    their point of view, platform vendor compilers and platform-tuned
    Fortran code are. Of course, that info is second-hand, and 
    somewhat dated, but I think it would help to state our goals 
    explicitly, to avoid confusion or unreasonable expectations.