Computer draughts tournament announcement

[TAILLE]

Hi,

It is a Dell 5500 with a xeon architecture (two core i7) 2,4Ghz and 12Gb of DDR3-ECC memory

Gerard, interesting machine.
Is it a server , workstation or desktop.
Tried to find it on the web-side but couldn't find it.
Maybe you have the right link to the Dell webpage...

How much HardDisk is installed and what is the oS you run.
Think you are right, to stay competitive we have to move to dual-socket QuadCore type of machines.

Bert

It is a desktop. I chose to use XP windows x64 and my hard disk will have 1,5 Tb. Concerning the hardDisk I had of course some hesitation. The point is the following. I know that I need only 400Gb for the 8 pieces endgame database but, in order to have a much more efficient db, I want to try to store also the results of capture positions. I guess that the 400Gb may easily becomes 1Tb and that is the reason of my choice.

[TAILLE]

It is a Dell 5500 with a xeon architecture (two core i7) 2,4Ghz and 12Gb of DDR3-ECC memory

Gerard, interesting machine.
Is it a server , workstation or desktop.
Tried to find it on the web-side but couldn't find it.
Maybe you have the right link to the Dell webpage...

How much HardDisk is installed and what is the oS you run.
Think you are right, to stay competitive we have to move to dual-socket QuadCore type of machines.

Bert

The site I used was the following :
http://www1.euro.dell.com/fr/fr/entrepr ... cs=frbsdt1
It is a french link but I assume it exits the same site in dutch or at least in english

[TAILLE]

Hi Gerard,

That sounds like a very capable machine. No doubt you will be able to build the 8pc db quickly with it.

I found that with my 8-core machine, I get no additional search speed past 4 search threads. There seems to be too much cache contention caused by globals that are read and written by multiple threads. AFAIK the main globals in this category are the hash table and history table. I need to work on this because the chess program Crafty seems to get good scaling with up to at least 8 search threads, and except for his lack of a history table I don't see much difference in its use of globals. I will be interested to hear how well you can get damy to scale with more than 4 threads.
-- Ed

I have now received my new computer and I am testing my new multithread algorithm. As I said before I decided to test a version with no hashtable sharing. My first obervations concerning the number of positions generated with this algorithm are the following :
1 thread : x 1
2 threads : x 1,85
4 threads : x 3,5
8 threads : x 5,9

These figures correspond to a position in the beginning of the game, i.e. with no disk access to the endgame db.

I tried to use 16 threads in order to take advantage of the hyperthreading but it does not work very nice : in this configuration 8 threads are working "normally" but the other 8 threads works at only 20% of the charge of the first threads. Because I cannot know in advance if a thread will work at 100% or 20% my algorithm cannot dispatch correctly the works on the different threads.
As a consequence, for the moment, I use only 8 threads, one per "real" core.

[Ed Gilbert]

Hi Gerard,

I have found that 'time to depth' is a useful parameter to measure in comparing different parallel search results. Nodes is not a good indicator, because with parallel search you may descend into a large subtree which later gets cutoff by another thread working from the same split point, so you searched a lot more nodes but some of it was wasted effort. Particularly in your case of not sharing a common hashtable, you will have more duplicate effort.

Another thing I have learned is that there is a very wide variation in performance ratio of (time_to_depth_N_threads / time_to_depth_1_thread) from one search to the next. To get a good ratio of the improvement for N threads I have been running a test suite of about 70 positions and averaging the ratios from each.

There is a recent topic on the talk chess forum about using i7 hyperthreads for parallel search. Bob Hyatt wrote this about it:

Do not do it. You will see a slight improvement in overall NPS, but the trees will grow by much more than that and make this an overall slowdown. I tested on a quad i7 for a month or so back in the Spring. hyper-threading is simply a no-no. You can safely turn it on if you are using linux (not sure about windows) if you only use 4 threads for your search. Linux is quite good about making sure that if you have 4 cores, each with hyperthreading on, and 4 threads, it will run one thread per core to produce max performance.

What kind of improvement are you seeing in search speed of damy on the i7 compared to your laptop (for the same 2 thread version)? I would guess that the search is about 2x the speed of the laptop search.

-- Ed

[TAILLE]

What kind of improvement are you seeing in search speed of damy on the i7 compared to your laptop (for the same 2 thread version)? I would guess that the search is about 2x the speed of the laptop search.
-- Ed

No the gain is (only) 36% : 9% due to the 2.4Ghz against 2.2Ghz and 27% due to the xeon structure. But remember that I have two quad processors. When I run only 2 threads I do not know if the 2 threads will run on the same processor and I do not know either if this point could be significant.

[TAILLE]

Hi Gerard,

That sounds like a very capable machine. No doubt you will be able to build the 8pc db quickly with it.

I found that with my 8-core machine, I get no additional search speed past 4 search threads. There seems to be too much cache contention caused by globals that are read and written by multiple threads. AFAIK the main globals in this category are the hash table and history table. I need to work on this because the chess program Crafty seems to get good scaling with up to at least 8 search threads, and except for his lack of a history table I don't see much difference in its use of globals. I will be interested to hear how well you can get damy to scale with more than 4 threads.

I will be looking forward to some long kingsrow vs. damy matches when you get the dam exchange working.

-- Ed

Hi Ed,

I hesitated a lot on the type of algorithm to use in a 8 cores environment. The problem was that I was not quite satisfactory with the existing algorithms. Basically I use the YBW algorithm with a tree exploration based on a mixture of MTD-f and MTD-f best procedure and a lot of gadgets.
The management of the multithread environment is handled by the main thread which is the only thread allowed to create and delete splitnodes.
I came back to the implementation of a big shared hashtable.
I have finished the analyse and the coding of this new algorithm but the version is not yet stable and I do need some more time to achieve the debbugging activity.
I am not worry about the Cannes tournament (it remains 3 months) but I am worry about a match Damy-Kingsrow at the beginning of the year because I am not yet in a situation to include in damy the damexchange algorithm. It will be by next priority!

Gérard

[Ed Gilbert]

Hi Gerard,

I too am usually working on some new things in kingsrow and so often I have some new code which is not really stable. I use a source code versioning system called Subversion, and it helps me manage these kinds of activities. It allows me to keep a stable source code base called a "trunk", and also create development "branches" for working on new ideas. I sometimes have several new branches in progress simultaneously. When I have tested a branch to the point where I am satisfied that it is stable and worth keeping I use Subersion's merge capability to merge the branch code back into the trunk. So theoretically I always have a stable source code base in the trunk for playing matches, even though I might have several new branches that are unfinished or have bugs. I highly recommend this Subversion program. It is free, and I also use it with a free user interface for it called TortoiseSVN.

-- Ed