Re: [Haskell-cafe] GHC optimisations

On Tue, Aug 21, 2007 at 09:39:32PM +0800, Hugh Perkins wrote:

On 8/21/07, Stefan O'Rear 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