inside the GHC code generator

[Bulat Ziganshin]

Hello Rene,

Thursday, February 23, 2006, 10:17:40 PM, you wrote:

RdV> Maybe GHC should generate better C. I am just not sure whether this will
RdV> bring the best global (as opposed to micro-optimizations) performance.

i answered in the original letter (search for "Cray" :)

RdV> Generating better C might also be much more difficult for idioms that don't
RdV> exist in C,

i will be glad to see concrete examples

RdV> and might encourage people to write Haskell that looks like C
RdV> (in order to get C like performance).

yes, they do just it now (see shootout entries or my Streams library)
but still don't get C performance. so i think that we will go to
something better position :)

RdV> I prefer idiomatic Haskell. It would be nice if this could be fast. But can
RdV> idiomatic Haskell be translated to efficient C? It might not have many
RdV> direct loops for example.

sorry, i don't understand that you mean? in general, idiomatic Haskell
has big efficiency problem and this problem is laziness. the strict
Haskell code is, like ML code, can be compiled efficient

RdV> -- Other notes

RdV> Integer is about 30 times slower than it needs to be on GHC if you have over
RdV> half the values between 2^-31 and 2^31. On i386 can you basically can test
RdV> the low bit for free (it runs in parallel to the integer add instruction).
RdV> This would allow only values outside this range to required calling the long
RdV> integer code. Such an optimization is not easily done in C.

RdV> This encourages Haskell programmers to always use Int, even if the value
RdV> might get too big, because Integer is too slow.

this optimization is not implemented in ghc until now and i think that
amount of work required to implement it is bigger than requirements to
do faster Integer processing. moreover, i hope that good optimizing C
compiler can avoid additional testing

RdV> Also Tail recursion is more general than looping. A general tail call 
RdV> optimization will bring better returns than a loop optimization in GHC
RdV> (though I could be wrong here). This requires special stack handling. Also
RdV> not so easy in C.

seems that you don't seen the attached files. tail calls are optimized
in gcc

RdV> If only simple loops are optimized it will encourage people to always code
RdV> loops in their haskell rather than perhaps using more appropriate 
RdV> constructs.

you are prefer that people will not have any option to make fast code?
:)  also i want to emphasize that C loops is the Haskell recursion. we
always said that these two constructs are equivalent, now it's the
time to generate code with the same speed

RdV> Also take the Maybe data type with Nothing and Just ... or any other 
RdV> datatypes with 0 and 1 variable constructors. Here these could be represent
RdV> by special values for the 0 variable case and bit marking on the single
RdV> constructor values. This could lead to good optimizations on case 
RdV> expressions.
RdV> Also not so easy in C.

1) it is far from current ghc optimization facilities
2) i don't see problems with using if()

RdV> The lack of this feature encourages people to encode their datatypes as
RdV> Int's to get speed. Also not good.

RdV> Whether we can communicate the non aliasing and aliasing properties of GHC
RdV> to the C compiler, I am also not so sure.

concrete examples?

RdV> Also in GHC, I am not sure whether stack base locals are the best move. It
RdV> might be best to have a fixed page as register spill in some cases.

it's the optimization that gcc can handle much better :)  just see at
the code generated for the fac() function

RdV> If you wish to pass and return unboxed tuples without reboxing you will
RdV> probably required a special function interface with double entry points (I
RdV> think this can be done in C, but it is  a bit tricky).

as i said, probably pair<a,b> can be used, but i don't tested this yet



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com