[Haskell-cafe] GHC optimisations

[Stefan O'Rear]

On Tue, Aug 21, 2007 at 09:39:32PM +0800, Hugh Perkins wrote:
> On 8/21/07, Stefan O'Rear <stefanor at cox.net> wrote:
> > Currently, it's never worse.  GHC's backend is about as good as GCC;
> > most of the optimiations it doesn't do are not possible for GCC because
> > of various lack-of-information problems (the stack pointer never aliases
> > the heap pointer, stuff like that).  It's conceivable that at some point
> > -fasm will be faster, because you have the possibility of much more
> > accurate aliasing information inside the compiler, than can be coded in
> > C.  In the meantime, note that the runtime difference is less than 3%
> > and the compile time difference is over 100%, so it's only worthwhile if
> > you expect *this version* of your program to be used more than 30 times,
> > ie releases only.
> 
> Wait, you're saying that ghc can produce "pure" c-code, that doesnt
> contain any assembly code, and that runs as fast as ghc code that does
> contain assembly?

No.

Name:        Registerized C
Performance: 1.00
Flags:       -fvia-C

C, but with gcc and machine specific hacks to implement general tail
calls and (most notably) register global variables.

Name:        Native code generator
Performance: 0.97
Flags:       -fasm

GHC's own mini C compiler converts the internal C-- data into assembly
code, which is then piped to gas.

Name:        Unregisterized C
Performance: 0.40
Flags:       -unreg

Generates near-ANSI C, using memory variables for the VM's registers and
the returning function pointer hack seen in oh so many Scheme compilers.
Good for early stages of porting, and not much else.

Name:        Byte-code
Performance: 0.05
Flags:       -fbyte-code (GHCi HEAD only)

Generates a compact form of STG code, and then interprets it.  A
generally quite bad idea, whose main redeeming feature is that it
doesn't require starting the GNU toolchain.

> Sooo.... if I was feeling "evil", could I take this c-code and pipe it
> into something that turns it into C#???

Yes.  You could do the same with the original haskell.  It's called a
compiler.

> If it contains lots of macros (or any macros at all perhaps...), this
> becomes non-trivial,

I fail to see how macros have anything to do with this.  Especially
since cpp removes them all.

> but otherwise I think most things in C can be mapped fairly trivially
> to C#?

Unsafe C#, sure.  Haskell's type system is strictly more expressive than
C#, and you need to sacrifice either machine efficiency or checked
safety.

> (It's a one-way mapping of course, eg "delete" in C is simply dropped
> when mapped to c#).

There is no delete in C, and even if there was, GHC wouldn't use it.
Allocation is *the* major bottleneck of functional programs, and having
a custom allocator inlined into every call site is vital to have usable
performance.

> (Not that I have any good reason to do this, simply... fun).

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070821/ffb7dc94/attachment.bin