Author: Vincent Diepeveen
Date: 01:50:31 09/30/02
Go up one level in this thread
On September 28, 2002 at 23:35:51, Tom Likens wrote:
There is zillions of bugs in the intel c++ compiler where it
generates code that is buggy both at my P3 as well as the K7s.
Of course the majority of bugs in the intel 6.0 compiler i didn't
checkout, i just file compared the logs.
All compilers produced the same log except the intel c++ 6.0 compiler.
One bug i HAD to investigate and it was in a program doing floating point
for a database conversion tool where i casted things to int.
something like
int coefficient(int bla,int blabla)
double a,b,c,d,e,f,g;
.. (all kind of stuff)
return( (int)((a*b)+c));
}
It took me very long to find this bug. I was very sick when
i learned that sometimes it returned a random value.
Obviously it didn't happen when i compiled without optimizations.
Just debug code with intel c++ it worked fine. Yet i'm not having
a good feeling running always with debug code turned on :)
Do you?
Further the intel c++ 6.0 compiler is hell slower for DIEP
at AMD than even a default msvc 6.0 sp4 procpack compile.
Not to mention the gcc 3.1 which has branch
reorder optimizations using profile info
just like the intel c++ thing has.
to my amazement gcc 3.1 with branch reordering also was a bit faster
at my P3 than the intel c++ 6.0 thing.
I do not know what the 6.0 compiler is doing, but it seems they only
did effort to get it slower at the K7, thereby also sacraficing speed
at their own P3 hardware.
Another weird thing for me is the realisation that the optimizing with
profile information in a open source compiler is doing way better than
the intel c++ is. Isn't it allowed in the specint or so? :)
If i see the specbench.org testresults, i do not see them use the
profile info to reorder branches.
msvc doesn't have all this cool features regrettably, otherwise it would
be by far fastest compiler as a default compile from it is way faster
than a default gcc compile is for k7. Yet the 20% speed the k7 executable
of DIEP wins by that extra optimization pass using profile info, that's the
big win.
Best regards,
Vincent
>On September 28, 2002 at 12:32:41, Robert Hyatt wrote:
>
>>On September 28, 2002 at 11:12:29, Tom Likens wrote:
>>
>>>On September 27, 2002 at 23:37:43, Robert Hyatt wrote:
>>>
>>>[snip!]
>>>
>>>>>>>So reality is that the above result in reality is even more positive for
>>>>>>>AMD than it looks like. We simply cannot trust these intel c++ compiles.
>>>>>>
>>>>>>Sure you can. I have tested the 6.0 release of their compiler exhaustively,
>>>>>>comparing various optimizations with a known good executable from gcc 2.95.2,
>>>>>>and the intel compiler is producing perfect code from a comparison of the
>>>>>>two...
>>>
>>>Actually, in my tests it's producing *significantly* faster code (especially, if
>>>you use the profile-enabled optimizations).
>>>
>>>regards,
>>>--tom
>>
>>I hope I had said the intel compiler was faster. However, Vincent keeps saying
>>it produces bad code that doesn't work. I think he just writes bad code himself
>>and then complains when the compiler does something that is unexpected, even
>>if it is legal. I use the intel compiler everywhere, including my cluster where
>>several have carefully compared program output between intel and gcc to check
>>for correctness.
>>
>>Intel is faster and correct, which is all I want. :)
>
>I haven't seen any incorrect code being produced with the 6.x compiler series.
>My engine is written in C++ and it stresses most compilers fairly hard (it
>breaks
>BoundsChecker completely when I compile it under Windows). So far, the output
>of the Intel version has matched the gcc version exactly (except for the speed).
>
>It's possible that Vincent is using (and counting on the behavior of) some
>of the compiler specific functions such as rand(). If so, even with the same
>initial
>seed he would get different results, which he may consider an error.
>
>On the other hand, I'm willing to give Vincent the benefit of the doubt. If he
>has
>a code snippet or two that he would be willing to post, that produces incorrrect
>code
>under the Intel compiler, I would be interested in seeing it.
>
>Vincent?
>
>And yes, fast *and* correct is the goal. So far, the Intel compiler has been
>impressive.
>One of the more pleasant surprises was the compatability with gcc. Even the gcc
>inline assembly routines I threw at it (which use AT&T syntax), compiled
>correctly
>the first time out of the box. I've always been, and still am, very loyal to
>gcc. But
>having a second quality compiler under Linux is an embarrasment of riches.
>Compiling my code under both compilers keeps it (and me) "honest".
>
>regards,
>--tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.