Oleg Goldshmidt wrote:
Nzer Zaidenberg <[EMAIL PROTECTED]> writes:
you would say that you expect problems when mixing -ffast-math with
-O9 and optimization?
I wouldn't, but gcc info would:
This option should never be turned on by any `-O' option since it
can result in incorre
Nzer Zaidenberg <[EMAIL PROTECTED]> writes:
> --0-2076963316-1123574270=:75895
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
>
> let me get it stright...
>
> you would say that you expect problems when mixing -ffast-math with
> -O9 and optimization?
I wouldn't
On Tue, Aug 09, 2005 at 11:52:35AM +0300, Ariel Biener wrote:
> On Monday 08 August 2005 21:30, Shachar Shemesh wrote:
> >
> > Actually, something extremely weird it going on here. The result change,
>
> Not weird, Anatoly didn't read what I sent through, see gcc man page for what
> -fno-math-errn
On Monday 08 August 2005 21:30, Shachar Shemesh wrote:
>
> Actually, something extremely weird it going on here. The result change,
Not weird, Anatoly didn't read what I sent through, see gcc man page for what
-fno-math-errno does.
I'll repaste it:
-fno-math-errno
Do not set ER
--0-2076963316-1123574270=:75895
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
let me get it stright...
you would say that you expect problems when mixing -ffast-math with -O9 and
optimization?
I have huge project (video encoder/decoder) that uses -ffast-math -
Anatoly Vorobey wrote:
If you declare it with
double q = 0;, you will get a meaningful answer in the -fno-math-errno
case as well.
Thanks, that was it, sort of:
[EMAIL PROTECTED]:/tmp$ cat test.c
#include
#include
int
main(int argc, char **argv)
{
long long i;
double q=0;
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Actually, something extremely weird it going on here. The result
> change, considerably, when I compile with or without "no-math-errno":
> > [EMAIL PROTECTED]:/tmp$ gcc -O2 -fno-math-errno -o test -lm test.c && time
> > ./test
> > nan
> >
> > real
On Mon, Aug 08, 2005 at 09:30:18PM +0300, Shachar Shemesh wrote:
> Actually, something extremely weird it going on here. The result change,
> considerably, when I compile with or without "no-math-errno":
Yeah. The no-math-errno thing seems to trigger quite a few FPU-related
optimizations.
> >[EM
Anatoly Vorobey wrote:
On Mon, Aug 08, 2005 at 06:30:58PM +0300, Ariel Biener wrote:
gcc -O2 -fno-math-errno -o /tmp/bnch-O2-no-math-errno /tmp/drek.c -lm
Try doing something with q after the loop to force it to compute sqrt,
that'll reflect reality better. printf or whatever. If you d
On Mon, Aug 08, 2005 at 06:30:58PM +0300, Ariel Biener wrote:
> YMMV, but the difference between running with gcc 3.4.3 was huge:
Because with this invocation
> gcc -O2 -fno-math-errno -o /tmp/bnch-O2-no-math-errno /tmp/drek.c -lm
gcc actually optimises sqrt away and never calculates it. No wond
-O3):
gcc -O2 /tmp/bnch-O2 /tmp/drek.c -lm
real0m4.440s
user0m4.358s
sys 0m0.001s
3). With -O2(or -O3) and -fno-math-errno:
gcc -O2 -fno-math-errno -o /tmp/bnch-O2-no-math-errno /tmp/drek.c -lm
real0m0.228s
user0m0.226s
sys 0m0.002s
--Ariel
> Example of an idiotic benchm
On Mon, Aug 08, 2005 at 04:29:57PM +0300, Omer Zak wrote:
> 1. How do you ensure that the compiler did not optimize away the
> assignment to q or the call to sqrt() due to recognition that it has no
> side-effects (in 80x86 processors, there is a FP sqrt instruction so a
> serious compiler knows to
Omer Zak wrote:
1. How do you ensure that the compiler did not optimize away the
assignment to q or the call to sqrt() due to recognition that it has no
side-effects (in 80x86 processors, there is a FP sqrt instruction so a
serious compiler knows to inline the function call and that it leaves no
"Marc A. Volovic" <[EMAIL PROTECTED]> writes:
> Example of an idiotic benchmark:
>
> int
> main()
> {
> long long i;
> double q;
>
> for (i=0; i<1000; i++) {
> q = sqrt(i);
> }
> }
>
&
Marc A. Volovic wrote:
Example of an idiotic benchmark:
int
main()
{
long long i;
double q;
for (i=0; i<1000; i++) {
q = sqrt(i);
}
}
Now, see what I don't like about gcc. It should really have known that
"sqrt" is a fun
. Why not use q += sqrt(i) in the benchmark (solves the above problems
without special compiler options or obscure pragmas)?
On Mon, 2005-08-08 at 16:02 +0300, Marc A. Volovic wrote:
> Example of an idiotic benchmark:
>
> int
> main()
> {
> long long i;
> doubl
Example of an idiotic benchmark:
int
main()
{
long long i;
double q;
for (i=0; i<1000; i++) {
q = sqrt(i);
}
}
Under gcc 3.3.5 (Debian Sarge) this pile of drek executes in 1.4-1.8
seconds (depending on -O level). Under icc 9.0 it execu
17 matches
Mail list logo
