Folding constants for floats

[Carter Schonwald]

Sven, I'm one of those people who cares about numerical performance :-).
Kinda been my obsession :-). My near term stop gap is writing some very
high quality ffi bindings, but I'm very keen on Haskell giving fortran a
run for it's money.

Glad we agree the version that's easier to debug (IEEE, ie current ghc
semantics) should be the default

There's much more meaningful ways we can improve floating point perf, like
adding simd support more systematically to ghc (which I'm just now getting
the ball rolling on that hacking, there's a lot of things I need to do
before adding that mind you ).

better constant propagation will help in a few cases, and should be
explored. But deciding what the right relaxed rules should be isn't
something we should do off the cuff.  We should write down the space of
possible relaxed rules, add engineering support to ghc better experiment
with benchmarking various approaches, and then if something has a good perf
impact see about providing it exposed through a flag.

On Tuesday, January 14, 2014, Sven Panne wrote:

> 2014/1/14 Carter Schonwald <carter.schonwald at gmail.com <javascript:;>>:
> > maybe so, but having a semantics by default is huge, and honestly i'm not
> > super interested in optimizations that merely change one infinity for
> > another. What would the alternative semantics be?
>
> I'm not sure that I understood your reply: My example regarding -0 was
> only demonstrating the status quo of GHCi and is IEEE-754-conformant.
> The 1/foo is only used to distinguish between 0 and -0, it is not
> about infinities per se.
>
> My point was: As much as I propose to keep these current semantics,
> there might be users who care more about performance than
> IEEE-754-conformance. For those, relatively simple semantics could be:
> Regarding optimizations, numbers are considered "mathematical"
> numbers, ignoring any rounding and precision issues, and everything
> involving -0, NaN, and infinities is undefined. This would open up
> optimizations like easy constant folding, transforming 0 + x to x, x -
> x to 0, x `op` y to y `op` x for mathematically commutative operators,
> associativity, etc.
>
> I'm not 100% sure how useful this would really be, but I think we
> agree that this shouldn't be the default.
>
> Cheers,
>    S.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/88c92653/attachment.html>