Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: About compiler optimizations

Author: Robert Hyatt

Date: 22:45:48 12/20/02

Go up one level in this thread


On December 21, 2002 at 01:11:39, Matt Taylor wrote:

>On December 20, 2002 at 13:58:20, Robert Hyatt wrote:
>
>>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".
>
>Yeah, pretty much. I was thinking about replying with, "???," but I decided it
>wasn't worth the time. I'm trying to figure out how it would be -possible- to
>write a single-pass compiler for C. It's not even possible to do Intel assembly
>in a single 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...
>
>Seems to me that making a problem simpler (and multiple stages) would make it a
>-LESS- buggy approach as the coder need only concentrate on the particular task
>he had to do. Since the data structures don't vary widely (obviously you use an
>AST for the tree and then whatever form of three-operand IL or whatever you like
>in between), I couldn't see how misconceptions about data structures would cause
>bugs either.

I think the entire discussion is stupid.  The more passes, the _better_ the
software, as each pass is simpler...



>
>>>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.
>
>Spoken truely from ignorance. Optimizations that benefit the P7 benefit the K7
>too. The designs are different, but like Dr. Hyatt says, they aren't -that-
>different. Just about every P7 optimization I can think of benefits the K7 too.
>The only place they really differ is in loop unrolling. The K7 benefits heavily
>from unrolled loops. It's not as dramatic on the P7.

Most good optimization books discuss this problem.  Loop unrolling has the
associated problem of "rolling cache".  Machines with large L1/L2/L3 cache
seem to like this optimization better than those "without"...

>
>I have seen the output from the Intel C compiler. It estimates rates that a
>branch will be taken at and does -specific- optimizations to maximize branch
>prediction success rates. Does VC do this? No. With processor pack? No.
>
>To put it more bluntly: I can hand-optimize better than VC 6. VC 7 and the Intel
>C compiler both beat me.
>
>-Matt


When you test, you certainly draw different conclusions than when you just
do things helter-skelter.  "some" spend _far_ more time talking/waving than
real testing, which seems a bit strange to me..




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.