Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: GCC 2.95 big step forward

Author: Robert Hyatt

Date: 13:44:40 08/07/99

Go up one level in this thread


On August 07, 1999 at 15:14:03, Vincent Diepeveen wrote:

>On August 07, 1999 at 12:56:44, Robert Hyatt wrote:
>
>>On August 07, 1999 at 08:13:33, Vincent Diepeveen wrote:
>>
>>>installed gcc 2.95 a few days ago.
>>>didn't speedup diep at all, whatever option i tried
>>>or used.
>>>
>>>HOWEVER,
>>>where i recently reported about all problems diep had
>>>with linux, now a different story.
>>>
>>>All those problems DIEP had with linux have dissappeared.
>>>DIEP runs stable under linux, no forfeits at a dual machine
>>>sincethen at the icc server.
>>>
>>>Seems gcc 2.95 is a big step forward for my program!
>>>
>>>Greetings,
>>>Vincent
>>
>>
>>I would be concerned, if that fixed (or hid) your bugs.  I am using this
>>same compiler, and find that it is almost identical to my favorite version
>>of pgcc.  Very little difference in execution speed.
>>
>>And there have been no serious parallel programming bugs exposed in the older
>>gcc/egcs compilers.  We have all sorts of parallel programming going on here
>>using gcc under linux, and in over 2 years, we have _never_ found a bug in the
>>code produced by the compiler.
>>
>>However, if you have uninitialized variables and the like, the non-determinism
>>will certainly cause a program to behave differently with multiple threads
>>active.  But if it has bugs in a non-parallel mode, just because they suddenly
>>become visible in parallel search doesn't mean the compiler is broken. It means
>>that the program is very suspect.
>
>It's very hard to call a big program buggy if it's
>running stable under NT for years
>without any problems having major bugs, which only show up under linux,
>but dissappear when a bugfixed gcc compiler comes out.
>


I see this _all_ the time.  Just because a program runs correctly, doesn't
mean it is a correct program.  Bad memory references can luckily land on
variables that don't mind getting overwritten, or which have a value of 0.
Uninitialized variables (local) can be fortunate that they luck into a zero
on the stack, until some new optimization changes this.  Etc...

Blaming the compiler is wrong, 99.99999999% of the time...




>a big program with difficult pointer datastructures and very well
>hand optimized is no compare with a bunch of quick&cheap&slow students
>programs.


Sorry to tell you this, but we have students here that have written programs
over 200,000 lines long working on MS/PhD projects.  Those are as complex as
anything I have written...




>
>>In your case, the way you are sharing things, the compiler really doesn't even
>>care that you are doing things in parallel because you aren't using the 'light-
>>weight thread' approach to parallel search, which means the compiler has no
>>influence at all over your program...  the only danger is in whatever you are
>>sharing among the processes...  because you _must_ get the 'volatile' things
>>properly identified or the optimizer will zap you.  But once they are right,
>>I don't see any problems at all, even in hundreds of different student programs
>>that are being worked on/tested...
>
>i'm not claiming my parallellism is bugfree. i never will. I'm talking
>about the single processor version. Of course i never tried to find the
>bug in the compiler. I only looked for bugs in DIEP all that time.
>
>If i compile kernels or the gcc compiler i see weird warnings which i would
>never want to have in my program. And then compile the new gcc compiler,
>also seeing all kind of weird warnings, then
>that gives people stuff to think about.


warnings really are 'warnings'.  99 % of them are type mismatches in procedure
calls, but since it knows this, it does the conversions just fine.  I compile
linux with my old pgcc for years...  and it has worked _flawlessly_.  And I
don't think either your program nor mine are _anything_ like as complex as
Linux is...






>
>There were definitely bugs in gcc, that's the only sure thing.
>I'm happy DIEP runs very good now. Next
>step is of course bugfree parallel.



There were no documented bugs that I am aware of...  If you believe that the
compiler was the problem, I'm not going to try to convince you otherwise.  But
you are going to be sadly disappointed when the bugs finally show up and get
fixed... and they turn out to be 'hidden' bugs in your code...




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.