Author: Robert Hyatt
Date: 14:08:31 07/05/01
Go up one level in this thread
On July 05, 2001 at 16:01:51, Vincent Diepeveen wrote: >On July 05, 2001 at 08:23:47, Robert Hyatt wrote: > >>On July 05, 2001 at 08:07:58, Vincent Diepeveen wrote: >> >>>Hi, risking to be off topic, >>>here a small attempt to adress the intel c++ compiler 5.01 build 15 >>> >>>I tried several options with it for DIEP and figured out that >>>it is 1.5% slower for me as msvc 6.0, nevertheless that's very >>>good considering that 5.00 completely crashed. >>> >>>this version does *not* crash. it produces an exe which runs and >>>which doesn't crash. >>> >>>I measured however in >>>another program of mine some weird things in floating point >>>unit calculations. >>> >>>An AI program of mine, >>>which fiddles with parameters (neural based) is regrettably >>>no longer deterministic. When i use optimizations >>> -O3 and some optimizations that allow Pentiumpro instructions and >>> MMX and SSE and similar instructions, then >>> i get completely different results. >>> >>>Especially the function >>> >>> y = ax^2 + bx + c >>> >>>which i use everywhere in the network, is giving different results >>>when using different optimizations. This is a bad thing! >>> >>>I cannot explain it but i feel that it has to do with the >>>fact that all these values are 'float'. >>> >>>Then when casting them back to parameters in 1/1000 pawn, i >>>get differences in testruns of up to 1 millipawn for the average >>>calculation! >> >>Some IEEE FP hardware has the ability to round or truncate on the LSB. >>Perhaps Intel is doing that opposite to MSVC? > >i feel it has to do with that it is using those MMX registers/ SSE >somehow. on paper the round off in this testset should be as the >default optimizations show it. It is giving an result which is far >from it. > >also casting could cause this round off error. > >most important is not the value it gives, but the fact that other >optimizations give different values! > >>Another explanation is a program bug that has an unitialized variable. > >No it is not that. we talk about 5 lines of code here which >produce the round off error. > >y = ax^2 + bx + c, >where the parameters of the function are giving already a few of >those variables. > >>High levels of optimization often cause such bugs to produce non-deterministic >>results. > >I know i have intensively checked the code again, but it wasn't a bug. >it's only a few lines anyway. This can produce different results: int a,b,c,d; d=a*b/c; where a and b and c can have any sort of integer value. If a is 2 billion, b is 2 billion and c is 2 billion, the result should be 2 billion. But not if it first does a*b. Order can change things here. If you do b/c first, you get the right answer. But in other cases, doing b/c first would produce wrong answers. The normal rules of math don't _quite_ apply to computers... unfortunately. > >> >> >> >>> >>>This is WEIRD!!!!!!!!!!!!!!!!!!!!!!!! >>> >>>I cannot explain it!!!!!!!!!!!!!1 >>> >>>So i cannot use this compiler. Note that i find it pretty bad that >>>a compiler which was already very good some time ago, that it still >>>can't beat at a P3-800, which is an intel chip, the visual c++ compiler. >>> >>>It was 0.5% slower this intel c++ some years ago as visual. Latest visual >>>c++ compiler is 1.5% faster, despite that it has all kind of instructions >>>nowadays this intel c++! >> >> >>why is this "pretty bad"? MS has a good compiler group and they are selling >>MSVC to make money. That is an incentive to produce the best compiler they >>can. Intel isn't competing with that at all... > >it is bad because m$ in all those years only got 2% faster for me, >whereas intel c++ won less as that. > >So from 486 code to IA32 model code it's now like 1% faster as it used >to be for my chessprogram? > >460kb code size. Huge number of registers are in existance now on >all x86 processors, can't compiler assume register renaming a bit >more? > >Well i'm no compiler expert of course, lucky i am not, but i find >a speedup of 1% over all those years pretty bad! > >The size of the executable is also way bigger as gcc and visual >produce exe. > >In fact gcc produces the smallest executable which i like a lot! > >If a function must be inlined then i can put inline in front of it, >no problem! > >> >> >> >> >>> >>>Using all those instructions it's NOT giving deterministic results. >>>If i turn off those P3 instructions, then it is of course going to >>>be hell slower as visual. >>> >>>Nevertheless it's a good thing that it no longer crashes like version 5.00 >>> >>>Best regards, >>>Vincent
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.