From: Bulat Ziganshin <[EMAIL PROTECTED]>
Hello Rene,
i done reading. my question - is YOU read this? the lisp problems have
almost
nothing in common with haskell
It is a long time since i read this, but some things come to mind. Listed
below.
Maybe GHC should generate better C. I am just not sure whether this will
bring the best global (as opposed to micro-optimizations) performance.
However doing anything else might be difficult.
Generating better C might also be much more difficult for idioms that don't
exist in C, and might encourage people to write Haskell that looks like C
(in order to get C like performance).
I prefer idiomatic Haskell. It would be nice if this could be fast. But can
idiomatic Haskell be translated to efficient C? It might not have many
direct loops for example.
-- Other notes
Integer is about 30 times slower than it needs to be on GHC if you have over
half the values between 2^-31 and 2^31. On i386 can you basically can test
the low bit for free (it runs in parallel to the integer add instruction).
This would allow only values outside this range to required calling the long
integer code. Such an optimization is not easily done in C.
This encourages Haskell programmers to always use Int, even if the value
might get too big, because Integer is too slow.
Also Tail recursion is more general than looping. A general tail call
optimization will bring better returns than a loop optimization in GHC
(though I could be wrong here). This requires special stack handling. Also
not so easy in C.
If only simple loops are optimized it will encourage people to always code
loops in their haskell rather than perhaps using more appropriate
constructs.
Also take the Maybe data type with Nothing and Just ... or any other
datatypes with 0 and 1 variable constructors. Here these could be represent
by special values for the 0 variable case and bit marking on the single
constructor values. This could lead to good optimizations on case
expressions.
Also not so easy in C.
The lack of this feature encourages people to encode their datatypes as
Int's to get speed. Also not good.
Whether we can communicate the non aliasing and aliasing properties of GHC
to the C compiler, I am also not so sure.
Also in GHC, I am not sure whether stack base locals are the best move. It
might be best to have a fixed page as register spill in some cases.
If you wish to pass and return unboxed tuples without reboxing you will
probably required a special function interface with double entry points (I
think this can be done in C, but it is a bit tricky).
Summary: If only C like Haskell is fast, we end up with Haskell that looks
like C. Yuck.
Rene.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
