[Haskell-cafe] Re: [Haskell] Google Summer of Code
claus.reinke at talk21.com
Thu Feb 12 07:56:57 EST 2009
>> > 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
> 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
- 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.
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.
More information about the Haskell-Cafe