[Haskell-cafe] GHC optimisations

Hugh Perkins hughperkins at gmail.com
Tue Aug 21 23:19:00 EDT 2007

Thank-you for the information.  It was very useful.  Couple of reactions FWIW:

On 8/21/07, Stefan O'Rear <stefanor at cox.net> wrote:
> > 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.

Yes, that is true.  However, this is also true, for an appropriate
compiler, for programs such as:

"Give me the first 10 numbers of the Fibonnacci (spelling?) series".

The compiler can search on the internet for what is the Fibonnacci
series, and/or ask its friends.

In a subsequent version, a compiler could in fact compile programs such as:


... where the compiler uses context to deduce what I want it to do ;-)

Nevertheless certain compilers are easier to write than others, and
writing code to automatically port ghc-generated C code is likely to
be significantly easier than to compile Haskell to C#, or to .Net
bytecode, from scratch.

> 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.

Ah, hence SPJ's C-- project?

> 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.

Could be good enough.  C# compiler and VM provides some optimizations
which could handle this.  What is the function pointer hack?
Specifically, is that why you say "near-ANSI" C, rather than "ANSI C"?

> > 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
> Version: GnuPG v1.4.6 (GNU/Linux)
> NUv22zY5IgeqkEJ5kL3yriQ=
> =0Xkq

More information about the Haskell-Cafe mailing list