Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: GCC 2.95 big step forward

Author: Vincent Diepeveen

Date: 12:14:03 08/07/99

Go up one level in this thread


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.

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

>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.

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.




This page took 0.01 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.