ZCT 0.3.2500 released

Teemu Pudas · Post by **Teemu Pudas** » Thu Jun 04, 2009 2:13 am

#if !defined&#40;ZCT_WINDOWS&#41; && defined&#40;SMP&#41; 
GLOBALS *zct;
#else
THREAD_LOCAL GLOBALS zct&#91;1&#93;;
#endif

Code: Select all

#if !defined&#40;ZCT_WINDOWS&#41; && defined&#40;SMP&#41;
	zct = &#40;GLOBALS *&#41;shared_alloc&#40;sizeof&#40;GLOBALS&#41;);
#endif

I investigated, and now I'm confused. It _looks_ like the Windows version never initializes zct->hash_table for anything but the main thread. MSVC's debugger claims the exact opposite (NULL for main, okay for worker). In either case, it should instantly crash and burn.

MSDN to the rescue:

You must use the thread attribute for the declaration and the definition of a thread local object, whether the declaration and definition occur in the same file or separate files.

Code: Select all

extern GLOBALS zct&#91;1&#93;;

Oops.

The THREAD_LOCAL should be removed. But should zct->killer_move[][] really be shared? The processors will be constantly fighting over those cache lines...

Zach Wegner · Post by **Zach Wegner** » Thu Jun 04, 2009 4:11 am

Teemu Pudas wrote:
Code: Select all
#if !defined&#40;ZCT_WINDOWS&#41; && defined&#40;SMP&#41; 
GLOBALS *zct;
#else
THREAD_LOCAL GLOBALS zct&#91;1&#93;;
#endif
Code: Select all
#if !defined&#40;ZCT_WINDOWS&#41; && defined&#40;SMP&#41;
	zct = &#40;GLOBALS *&#41;shared_alloc&#40;sizeof&#40;GLOBALS&#41;);
#endif
I investigated, and now I'm confused. It _looks_ like the Windows version never initializes zct->hash_table for anything but the main thread. MSVC's debugger claims the exact opposite (NULL for main, okay for worker). In either case, it should instantly crash and burn.

Wow, that's actually a really old bug. I am almost certain that I had fixed that before. In any case, that bug is your fault, since you did the thread local changes.

"zct" should of course be global, not local. That's the reason the Unix version is a pointer--it has to be allocated in shared memory.

MSDN to the rescue:
You must use the thread attribute for the declaration and the definition of a thread local object, whether the declaration and definition occur in the same file or separate files.
Code: Select all
extern GLOBALS zct&#91;1&#93;;
Oops.

The THREAD_LOCAL should be removed. But should zct->killer_move[][] really be shared? The processors will be constantly fighting over those cache lines...

That's already changed.

After the thread on cache coherency earlier I looked through ZCT and found that all the move ordering was global, and even worse, all the statistics (fail_highs, hash_probes, etc.) were too. I changed the move ordering stuff to be inside BOARD (rather than making more thread local stuff, only needs to be one thing), and I commented out the statistics. NPS scaling improved significantly.

OTOH I had it hang on me earlier when doing benchmarks, but it was in heavily optimized code, and it was in an ssh session, so I didn't get enough time to walk through the disassembly...

I will make 2501 once I get around to fixing that, or at least adding back in the statistics inside BOARD.

Teemu Pudas · Post by **Teemu Pudas** » Thu Jun 04, 2009 7:34 am

Zach Wegner wrote:Wow, that's actually a really old bug. I am almost certain that I had fixed that before. In any case, that bug is your fault, since you did the thread local changes.

Sorry, but no way.

Digging up the version I sent you:

Code: Select all

extern thread_local GLOBALS zct&#91;1&#93;;

Code: Select all

thread_local GLOBALS zct&#91;1&#93;;

Hey, at least I had the right idea in making it thread-local because hash_table was the only thing in it that had any business being shared.

Jim Ablett · Post by **Jim Ablett** » Thu Jun 04, 2009 8:28 am

Dann Corbit wrote:
Jim Ablett wrote:I've compiled a Windows 32-bit SMP version of ZCT using GCC/Cygwin.
Not possible to build an x64 version unfortunately because no 64-bit Cygwin exists.

Download:
http://www.mediafire.com/?23ert42ahjj

Jim.
There is a 64 bit mingw compiler for Windows, but it does not have fork().
Does ZCT use fork()?

Hi Dann,

fork () is ok. I have some mingw equivalents for this. Main stumbling block is with these >

Code: Select all

#ifdef SMP

#ifdef ZCT_POSIX
#	include <fcntl.h>
#	include <sys/ipc.h>
#	include <sys/mman.h>
#	include <sys/sem.h>
#endif /* ZCT_POSIX */

Jim.

Zach Wegner · Post by **Zach Wegner** » Thu Jun 04, 2009 8:33 am

Teemu Pudas wrote:
Zach Wegner wrote:Wow, that's actually a really old bug. I am almost certain that I had fixed that before. In any case, that bug is your fault, since you did the thread local changes.
Sorry, but no way. Digging up the version I sent you:
Code: Select all
extern thread_local GLOBALS zct&#91;1&#93;;
Code: Select all
thread_local GLOBALS zct&#91;1&#93;;
Hey, at least I had the right idea in making it thread-local because hash_table was the only thing in it that had any business being shared.

Exactly! I guess I did a find/replace with thread_local to THREAD_LOCAL as a preprocessor macro just to make it portable, but having a definition with the words "global" and "local" should be raising red flags.

And the CVS repository comes in handy here to prove that I DID fix this bug before, between revision 1.9 and 1.10: http://zct.cvs.sourceforge.net/viewvc/z ... c?view=log
In fact, looking at globals.h: http://zct.cvs.sourceforge.net/viewvc/z ... h?view=log The revision 1.8 is only the removal of THREAD_LOCAL, with the comment "Fixed a couple of Windows SMP bugs". So this must have been found between 6:18 and 11:17 PM on July 18, 2008!!

And it also showed something else interesting: this bug was never reintroduced, the current version 1.11 does not have the GLOBALS object declared as thread local. So the question is now, how did it get that way in your version? You introduced the bug in the first place, and then you try and bring it in again? Nice try.

Seriously though, if that wasn't the problem, what is really happening with SMP on windows?

Jim Ablett · Post by **Jim Ablett** » Thu Jun 04, 2009 8:35 am

Christopher Conkie wrote:
Jim Ablett wrote:I've compiled a Windows 32-bit SMP version of ZCT using GCC/Cygwin.
Not possible to build an x64 version unfortunately because no 64-bit Cygwin exists.

Download:
http://www.mediafire.com/?23ert42ahjj

Jim.
There are these Jim

http://sourceforge.net/project/showfile ... _id=679919

http://sourceforge.net/project/showfile ... _id=663967

Also there is this.....

http://sourceforge.net/project/showfile ... _id=545943

Chris

Thanks Chris,

I'm just checking it it out now.

Jim.

Zach Wegner · Post by **Zach Wegner** » Thu Jun 04, 2009 8:39 am

Jim Ablett wrote:
Dann Corbit wrote:
Jim Ablett wrote:I've compiled a Windows 32-bit SMP version of ZCT using GCC/Cygwin.
Not possible to build an x64 version unfortunately because no 64-bit Cygwin exists.

Download:
http://www.mediafire.com/?23ert42ahjj

Jim.
There is a 64 bit mingw compiler for Windows, but it does not have fork().
Does ZCT use fork()?
Hi Dann,

fork () is ok. I have some mingw equivalents for this. Main stumbling block is with these >
Code: Select all
#ifdef SMP

#ifdef ZCT_POSIX
#	include <fcntl.h>
#	include <sys/ipc.h>
#	include <sys/mman.h>
#	include <sys/sem.h>
#endif /* ZCT_POSIX */
Jim.

fcntl.h should be there, as there is an equivalent file in the Windows environment (used in smp.c). So it would be strange if MSVC is more POSIXy than mingw there...

For the others, only sys/mman.h is needed anymore. The other two were from back when ZCT used both shmget and semget, the SysV inter-process-communication stuff. Now it uses mmap (which is much easier to deal with)) and assembly/intrinsic locks. Not sure if that would help though.

Jim Ablett · Post by **Jim Ablett** » Thu Jun 04, 2009 10:32 am

Zach Wegner wrote:
Jim Ablett wrote:I've compiled a Windows 32-bit SMP version of ZCT using GCC/Cygwin.
Not possible to build an x64 version unfortunately because no 64-bit Cygwin exists.

Download:
http://www.mediafire.com/?23ert42ahjj

Jim.
Thanks Jim. Works fine here, but it's a shame that no PGO'd 64 bit ICC binaries can be made. Just curious, were you running into the same issue Fonzy was if it was compiled natively? I'm hitting it as well, but I can't seem to figure out why. Works perfectly fine under Unix.

I might be able to make some 64-bit MP builds later, but they'd just be with MSVC EE 2008. I have the full version (with PGO) at work, but it's on 32-bit vista...

Windows Intel x64 pgo MP compiling ok now.

Just testing - builds up soon.

Jim.

Teemu Pudas · Post by **Teemu Pudas** » Thu Jun 04, 2009 11:25 am

Zach Wegner wrote:Seriously though, if that wasn't the problem, what is really happening with SMP on windows?

Even when I add the THREAD_LOCAL to the declaration, both threads still somehow manage to see the same zct. At first I thought it must have copied the contents when creating the thread, but I've disproved that theory now.

Conclusion: THREAD_LOCAL isn't working (and MSVC10's debugger is buggy).

Did anyone ever actually produce and test a working Windows SMP build with MSVC?

Teemu Pudas · Post by **Teemu Pudas** » Thu Jun 04, 2009 12:13 pm

Teemu Pudas wrote:Conclusion: THREAD_LOCAL isn't working

Or the worker thread refuses all work because zct->process_count == 0.

New conclusion: something else isn't working. Now it burns (but doesn't crash

) within the first 50 milliseconds.

MSDN wrote:int j = j; // Okay in C++; C error

Incidentally, the Level 1 compiler warnings include a number of int*'s pointing to VALUE (short) and vice versa.

ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released

Re: ZCT 0.3.2500 released