Marc A. Volovic wrote:
Example of an idiotic benchmark:
int
main()
{
long long i;
double q;
for (i=0; i<10000000; i++) {
q = sqrt(i);
}
}
Now, see what I don't like about gcc. It should really have known that
"sqrt" is a function with no side effects, and turned the above program
progressively into:
{
long long i;
double q;
i=10000000;
q=sqrt(9999999);
}
and then, figure out that no one is using "i" or "q" after their last
initialization, and so into:
{
}
When I have a chance, I'll try to see what Visual Studio makes of it.
For reference, VS's assembly optimization is nowhere near as good as
Intel's, but its platform independant optimizations are much better.
This is something I expect it to catch.
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 executes between in
3.4 seconds for -O0 and -O1, and in 0.015 seconds for -O2.
It sounds like ICC caught on to the fact that this function is a no-op.
Pick a better benchmark.
And don't tell me this is not a valid benchmark. I know. This is as
artificial as I can get without using a wooden leg.
Try defining q to be "volatile double *q", and init it with malloc. do
the obvious change to the rest of the code. After all, this is a test to
see who manages to ceate more efficient "sqrt", not see who's C
understanding is better.
M
You do, obviously, remeber that my original question was about *integer*
performance, right?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
