Janne Blomqvist wrote:
However, I didn't realize so few iterations were required to achieve
(almost) full precision. That's pretty nice.
NR is a nice iteration, you double the number of bits of precision
on each iteration (approximately :-)
Geert Bosch wrote:
On Apr 27, 2007, at 06:12, Janne Blomqvist wrote:
I agree it can be an issue, but OTOH people who care about precision
probably 1. avoid -ffast-math 2. use double precision (where these
reciprocal instrs are not available). Intel calls it -no-prec-div, but
it's enabled for t
Geert Bosch wrote:
I truly doubt that any of the compilers you mention use these
instructions without NR iteration to get required precision.
If they do then they are probably seriously broken, not just
because they give complete junk results in this case, but
such an implementation would indi
On Apr 27, 2007, at 06:12, Janne Blomqvist wrote:
I agree it can be an issue, but OTOH people who care about
precision probably 1. avoid -ffast-math 2. use double precision
(where these reciprocal instrs are not available). Intel calls it -
no-prec-div, but it's enabled for the "-fast" catch
Richard Guenther wrote:
See also http://www.suse.de/~gcctest/c++bench/polyhedron/analysis.html
(same conclusion for gas_dyn).
Thanks, I seem to have completely missed that page (though I was aware
of your polyhedron tester).
>On 4/27/07, Janne Blomqvist <[EMAIL PROTECTED]> wrote: >> The
rea
On 4/27/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
I think that even with -ffast-math 12 bits accuracy is not ok. There is
the possibility of doing another newton iteration step to improve
accuracy, that would be ok for -ffast-math. We can, though, add an
extra flag -msserecip or however y
On 4/27/07, Janne Blomqvist <[EMAIL PROTECTED]> wrote:
Hi,
I spent some time with oprofile, trying to figure out why we suck at the
gas_dyn benchmark in polyhedron. It turns out that there are two lines
that account for ~54% of the total runtime.
In subroutine CHOZDT we have the line
DTEM
