Help with Crafty....please!

[zullil]

SOLVED THE PROBLEM!

I was using the 23.0 engine from the 'speed complie' list that Jim provides which, ironically, doesn't seem to support multithreading.

I'm now using the full featured one and it does.

Thanks!

As I noted in my previous post, the binary

Code: Select all

crafty-23.0_ja/speed compiles/win32/crafty_230_win32_uci_ja.exe

does support multithreading. Which engine, specifically, was causing the trouble?

[sje]

I've shied away from too much unix dependence, and since hyper-threading adds yet another level of complexity, I've just left that to the user. If one was to be anal, one could use the "cpuid" instruction and discover how many physical cores there are and whether hyper-threading is enabled or not. That might actually be a more portable solution since that is not dependent on linux or windows. Maybe, one day. However, there are other interesting issues and I don't want to spend weeks trying to make the compile operation option-free. For example, Nehalem's SSE4.2 which has (finally) the popcnt instruction that I am now using when I run on that platform. But I am not relying on the compiler telling me about SSE4.2 because older compilers don't understand it, so I added a -DPOPCNT option to say use a hardware popcnt instruction which will crash and burn on a non-SSE4.2 box.

Symbolic is produced in PowerPC versions as well as Intel/AMD, so there's no SSE* and no cpuid either.

For popcnt() (which I've always called Card() after my early Pascal indoctrination), the use of the gcc built-in intrinsic functions will eliminate the x86 dependency although at at the cost of adding a gcc dependency.

Perhaps it's time to start using the multi-platform Boost framework to cover feature dependency issues. If Boost doesn't have a particular capability, then it could be added for the next release. I'd rather have to use Boost than to have too many preprocessor directives cluttering my source.