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:[EMAIL PROTECTED] _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
