ZCT 0.3.2500 released

[Jim Ablett]

Ok Here's the
ZCT 0.3.2500 Windows Intel Compiler 11/10 x64/win32 SMP pgo builds.

Download:
http://www.mediafire.com/?itqmyuejzjm

Jim.

[AdminX]

Ok Here's the
ZCT 0.3.2500 Windows Intel Compiler 11/10 x64/win32 SMP pgo builds.

Download:
http://www.mediafire.com/?itqmyuejzjm

Jim.

Thanks Jim!

[Dr.Wael Deeb]

Thanks....the new updated opening book will follow soon....
Dr.D

[Zach Wegner]

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?

Well zct should definitely not be thread local anyways, so what's the point? Is the thread local working for board? If so, then no need to experiment.

Anyways, the builds I was doing at work the past couple days were working OK, but as was happening to Fonzy, they would fail ASSERTs every once in a while, or seemed to hang. Debug builds never seemed to have problems, but they were sooooooo slooooooooow, so maybe I just didn't have the patience to hit them. They were getting <100 knps on an Athlon 64 dual-core, I think 2.2 GHz, with both cores, albeit in 32 bit mode. As opposed to about 2.4 mnps on my quad core.

[F. Bluemers]

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?

Well zct should definitely not be thread local anyways, so what's the point? Is the thread local working for board? If so, then no need to experiment.

Anyways, the builds I was doing at work the past couple days were working OK, but as was happening to Fonzy, they would fail ASSERTs every once in a while, or seemed to hang*. Debug builds never seemed to have problems, but they were sooooooo slooooooooow, so maybe I just didn't have the patience to hit them. They were getting <100 knps on an Athlon 64 dual-core, I think 2.2 GHz, with both cores, albeit in 32 bit mode. As opposed to about 2.4 mnps on my quad core.

* I got that fixed:
just put

Code: Select all

#pragma optimize( "", off )

just before

Code: Select all

int find_split_point(void)
{

in smp2.c
it turns off optimization just for that function.So no need to run a Debug build
But there is still something wrong with the compile,if you compare it with jim's.
Best
Fonzy

[Dr.Wael Deeb]

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?

Well zct should definitely not be thread local anyways, so what's the point? Is the thread local working for board? If so, then no need to experiment.

Anyways, the builds I was doing at work the past couple days were working OK, but as was happening to Fonzy, they would fail ASSERTs every once in a while, or seemed to hang. Debug builds never seemed to have problems, but they were sooooooo slooooooooow, so maybe I just didn't have the patience to hit them. They were getting <100 knps on an Athlon 64 dual-core, I think 2.2 GHz, with both cores, albeit in 32 bit mode. As opposed to about 2.4 mnps on my quad core.

Hi Zach,
Can you remind me please of the command line that creates the opening book
Dr.D

[Jim Ablett]

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?

Well zct should definitely not be thread local anyways, so what's the point? Is the thread local working for board? If so, then no need to experiment.

Anyways, the builds I was doing at work the past couple days were working OK, but as was happening to Fonzy, they would fail ASSERTs every once in a while, or seemed to hang. Debug builds never seemed to have problems, but they were sooooooo slooooooooow, so maybe I just didn't have the patience to hit them. They were getting <100 knps on an Athlon 64 dual-core, I think 2.2 GHz, with both cores, albeit in 32 bit mode. As opposed to about 2.4 mnps on my quad core.

Hi Zach,
Can you remind me please of the command line that creates the opening book
Dr.D

Hi Wael,

Double-click on the exe. Type bookc

Code: Select all

Usage: bookc pgn_file book_file min_play max_depth win_percent

Jim.

[Dr.Wael Deeb]

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?

Well zct should definitely not be thread local anyways, so what's the point? Is the thread local working for board? If so, then no need to experiment.

Anyways, the builds I was doing at work the past couple days were working OK, but as was happening to Fonzy, they would fail ASSERTs every once in a while, or seemed to hang. Debug builds never seemed to have problems, but they were sooooooo slooooooooow, so maybe I just didn't have the patience to hit them. They were getting <100 knps on an Athlon 64 dual-core, I think 2.2 GHz, with both cores, albeit in 32 bit mode. As opposed to about 2.4 mnps on my quad core.

Hi Zach,
Can you remind me please of the command line that creates the opening book
Dr.D

Hi Wael,

Double-click on the exe. Type bookc

Code: Select all

Usage: bookc pgn_file book_file min_play max_depth win_percent

Jim.

Hi Jim,
Thanks....I'll send it to you when ready....pretty soon
Dr.D

[Werner]

Thanks Jim,
are there other changes to your first 32bit compiles?

Which compile should I use for 32bit 1CPU tests (the first ones or the smp version with 1CPU ?)

[Jim Ablett]

Thanks Jim,
are there other changes to your first 32bit compiles?

Which compile should I use for 32bit 1CPU tests (the first ones or the smp version with 1CPU ?)

Hi Werner,

You can use latest 32-bit MP version. MP is not enabled in the 'ZCT.ini' by default.

Code: Select all

# Use 4 processors
#mp 2

Remove hash in front to enable MP.

Jim.