[Haskell-cafe] Re: GHC predictability
barsoap at web.de
Tue May 13 17:37:28 EDT 2008
Andrew Coppin <andrewcoppin at btinternet.com> wrote:
> You're probably right about all that. I would humbly suggest that
> what is somewhat lacking is a good, introductory, high-level text on
> what makes Haskell go fast and what makes it go slow. As with many
> things in the Haskell world, there are bits and pieces of information
> out there, but it's difficult to track them all down and present a
> coherant picture. We've got a section on the wiki containing scraps
> and snippets of information. There are various GHC-related papers [if
> you can find them online]. GHC has various profiling possibilities,
> but thus far I've found it difficult to digest the results. We need a
> good, thorough body of text on this subject, I feel. [Of course, that
> still means somebody has to write one...]
Something like the history paper but concentrating on algorithms,
techniques & tricks would be great, yes. And, most importantly, less
buzzwords where you're lucky if you find a definition of it by googling.
> 1. What is "ghc-core"?
An intermediate language, I'm quoting from memory:
First comes a Syntax tree, then the type checker, then the translation
to core, then optimisations on core (, then the printout) and finally
> 2. Does anybody know how to actually read GHC's Core output anyway?
> To me, it looks almost exactly like very, very complicated Haskell
> source with a suspicious concentration of case expressions - but I
> understand that in the Core language, many constructs actually mean
> something quite different.
I found it rather easy to parse... as long as you succeed in finding
what you're looking for behind all that inlining. Types ending in #
mean they're unboxed.
It's particularly useful to find out how much ghc specialises your
> 3. Any idea where the STG paper is? Is it still an accurate
> reflection of GHC's current technology?
Implementing lazy functional languages on stock hardware: the Spineless
Tagless G-machine, SL Peyton Jones, Journal of Functional Programming
2(2), Apr 1992, pp127-202.
while googling for it, I stumbled across
which might be more actual, but I neither read it yet or have any
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
More information about the Haskell-Cafe