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.