Author: Robert Hyatt
Date: 10:58:20 12/20/02
Go up one level in this thread
On December 20, 2002 at 11:21:40, Vincent Diepeveen wrote:
>On December 19, 2002 at 13:16:02, Frank Sgarra wrote:
>
>After that diep gave away a pawn with the intel c++ compiler
>and not with any other compiler (also giving difference in score
>for mainlines), i started checking out that intel compiler
>more.
>
>I found several bugs in intel c++.
>
>One of them i posted here at CCC some time ago for version 6.0 of
>intel c++.
>
>it was something in factorization code to see whether there
>is a coefficient somewhere. something like:
>
>int lineaircoefficient(int a,int b) {
> float a,b,c;
>
> (formula)
> a = ..
> b = ..
> c = ..
>
> return((int)(a*b+c));
>}
>
>There was a big bug in the:
> return((int)(a*b+c));
You posted that, I tried it and it worked _perfectly_ as I reported at the
time. I'd much more likely suspect some programming mistakes in your code
rather than in the compiler...
>
>It is not my work to detect bugs in the intel c++ compiler, which
>is a fulltime work i bet.
>
>Just compile any non-specint software and see what happens with it.
I have done that...
>
>A good example is to compile some linux stuff with gcc.
>
>Perhaps the gcc compiler itself would be a good example. Please compile
>it with intel c++ and you'll see yourself zillions of examples.
>
>Then you first find out whether it's a bug in the software secondly
>you try to find out whether it's a compiler bug.
>
>I am not big compiler expert but i even understood what a compiler
>expert wrote at a homepage somewhere.
>
>Most compilers are single pass compilers.
>the intel c++ compiler is not.
Most compilers are _not_ "single pass". In fact, that is impossible to
do, because of forward references. Something has to make the second pass
to fill in the missing blanks.
Not to mention optimizations that get done on the second or third pass.
GCC certainly isn't "one pass".
>
>advantage: they can use more optimizations than other compilers especially
> for specint that is very useful.
>disadvantage: it is a more buggy approach.
That is nonsense, spoken from someone that knows _zero_ about compiling
techniques. Pick up _any_ good compiler book. Read it. Come back to the
discussion with some understanding of what goes on...
>
>also in past (especially 5 versoins) i used to get a lot of internal
>intel compiler errors.
I specifically mentioned version 6 and 7. Which is compiling all sorts of
non-spec code here for users on my cluster. One code having over two
million lines of code.
>
>I hope you realize that compilers and testing them is going to be
>a fulltime job and i for sure am only going to do that when i get
>paid for it.
>
>Until then i will skip taking a good look to intel c++.
>
>Additionally i own AMD machines which are faster than the intel machines
>i own. Intel is of course not doing effort to be fast on AMD machines.
>
>In contradiction. It's trivial that if version 5.0 is not doing bad for
>AMD K7 processors, that when version 6 is doing a lot better for P4,
>and a lot worse for K7, that version 7 and 8 aren't going to perform
>better.
>
>Even a default compile with a compiler from years ago (msvc6 sp4 procpack)
>is already a lot faster on any K7 than intel c++ 6.0 is.
I seriously doubt that. The K7 is not _that_ different.
>
>The major problem i have with intel c++ is simply that i cannot trust it.
>You can only trust on it that specint and specfp programs run well with it.
Crap, crap, and more crap.
>
>Crafty is a good example.
>
>Best regards,
>Vincent
>
>
>>On December 19, 2002 at 12:59:05, Vincent Diepeveen wrote:
>>
>>>On December 19, 2002 at 11:40:14, Frank Sgarra wrote:
>>>
>>>use intel c++ at own risk.
>>>
>>>never use it for code that is very critical for your company.
>>>never use it for a version of your chess program that joins
>>>a tournament.
>>>
>>>you'll give away a piece (or pawn in case of diep) because of
>>>bugs in a new intel c++ version. Let me assure you that.
>>>
>>>DIEP did.
>>
>>
>>
>>i would be happy to have a pice (my own) of code
>>that produces wrong(different) outputs compiled with intel C++,
>>because maybe it would give me a pointer to a buggy place in
>>my own program.
>>
>>can you repeat the wrong output of diep when using that compiler?
>>
>>did you prove, that intel C++ is doing a bad job ?
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.