inside the GHC code generator
bulat.ziganshin at gmail.com
Thu Feb 23 15:30:37 EST 2006
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
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
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> 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.
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
Bulat mailto:Bulat.Ziganshin at gmail.com
More information about the Glasgow-haskell-users