> The problem are not so much the additional instructions. Rather,
> it's the fact that compare for Float and Double can fail at all
> which inhibits some optimisations. For instance, GHC is free to
> eliminate the comparison in (x `compare` y) `seq` a but wouldn't be
> with your change. It doesn't actually do that at the moment, which
> looks like an optimiser deficiency to me. But in any case, the
> property "can fail" has a significant effect on optimisations
> sometimes.
Yeah, the IEEE FP people knew what they were doing from a performance
perspective. This kind of problem (eg, being able to remove a dead
x+y without proving all kinds of conditions on x and y) is exactly
whey they mandated a NaN value upon arithmetic exception rather than
making the computation fail with a synchronous exception. Or at
least, a mode, almost always used by default, with this behaviour.
What you're describing is a similar performance problem, which argues
for a similar solution:
data Ordering = LT, EQ, GT, OoO
where OoO means Out of Order.
But just because you could doesn't mean you'd have to do this:
compare x y =
case map (\o->x`o`y) [(<),(<=),(==),(>=),(>),(/=)] of
[True,True,False,False,False,True] -> LT
[False,True,True,True,False,False] -> EQ
[False,False,False,True,True,True] -> GT
otherwise -> OoO
--Barak.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
