[Haskell-cafe] GHC optimisations
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
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
> > (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
> > (Not that I have any good reason to do this, simply... fun).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> -----END PGP SIGNATURE-----
More information about the Haskell-Cafe