[Haskell-cafe] GHC optimisations

[Hugh Perkins]

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:

"Go!"

... 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGyur/FBz7OZ2P+dIRAleTAJ9WiK8tCp0QZE4syG4BZk5EFm1FuQCgzYGK
> NUv22zY5IgeqkEJ5kL3yriQ=
> =0Xkq
> -----END PGP SIGNATURE-----
>
>