bob wrote:
My approach is similar. An array of thread pointers to access local data, local data (Per thread) allocated in the usual way, with a little care exercised due to NUMA considerations (first CPU to touch a thread block gets that block in its local memory, so this 'first to touch" needs to be spread over all threads and processors to spread the data uniformly, then one wants to use the local data on your core, not on a remote one, etc...
I remember that being an issue with Cilkchess on a big SGI machine we used with 256 processors.
But I did not realize that it was an issue here. So you can control which processor gets the data? How do I do that? I basically keep everything for a single thread in this structure and I have an array of them. I allocate memory for the evaluation cache and pawn structure caches and other read/write tables (such as the history table) are declared statically because their size are small and fixed.
So how can I control which processes get assigned to a given thread?
Easy.
1. Malloc the data you need. You need to make things align on a page size. IE if a split block is 1024 bytes, each thread should get a multiple of 4 split blocks allocated. You malloc at one point, something like this:
split_blocks = malloc(4 * sizeof(split_block) * 64) or something similar.
2. Now, each individual thread should initialize the split blocks it prefers to use without touching any others. When a page initially faults in, it faults in to the local memory of the processor that caused the fault.
bob wrote:
My approach is similar. An array of thread pointers to access local data, local data (Per thread) allocated in the usual way, with a little care exercised due to NUMA considerations (first CPU to touch a thread block gets that block in its local memory, so this 'first to touch" needs to be spread over all threads and processors to spread the data uniformly, then one wants to use the local data on your core, not on a remote one, etc...
I remember that being an issue with Cilkchess on a big SGI machine we used with 256 processors.
But I did not realize that it was an issue here. So you can control which processor gets the data? How do I do that? I basically keep everything for a single thread in this structure and I have an array of them. I allocate memory for the evaluation cache and pawn structure caches and other read/write tables (such as the history table) are declared statically because their size are small and fixed.
So how can I control which processes get assigned to a given thread?
Easy.
1. Malloc the data you need. You need to make things align on a page size. IE if a split block is 1024 bytes, each thread should get a multiple of 4 split blocks allocated. You malloc at one point, something like this:
split_blocks = malloc(4 * sizeof(split_block) * 64) or something similar.
2. Now, each individual thread should initialize the split blocks it prefers to use without touching any others. When a page initially faults in, it faults in to the local memory of the processor that caused the fault.
That's it...
Thanks Bob, I am eager to try this out.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
bob wrote:
My approach is similar. An array of thread pointers to access local data, local data (Per thread) allocated in the usual way, with a little care exercised due to NUMA considerations (first CPU to touch a thread block gets that block in its local memory, so this 'first to touch" needs to be spread over all threads and processors to spread the data uniformly, then one wants to use the local data on your core, not on a remote one, etc...
I remember that being an issue with Cilkchess on a big SGI machine we used with 256 processors.
But I did not realize that it was an issue here. So you can control which processor gets the data? How do I do that? I basically keep everything for a single thread in this structure and I have an array of them. I allocate memory for the evaluation cache and pawn structure caches and other read/write tables (such as the history table) are declared statically because their size are small and fixed.
So how can I control which processes get assigned to a given thread?
Easy.
1. Malloc the data you need. You need to make things align on a page size. IE if a split block is 1024 bytes, each thread should get a multiple of 4 split blocks allocated. You malloc at one point, something like this:
split_blocks = malloc(4 * sizeof(split_block) * 64) or something similar.
2. Now, each individual thread should initialize the split blocks it prefers to use without touching any others. When a page initially faults in, it faults in to the local memory of the processor that caused the fault.
That's it...
Thanks Bob, I am eager to try this out.
Don
One other note I forgot about. You should lock a thread on a particular processor (core) before doing this. Then let each thread use memset() or whatever to zero the data, which faults it in onto the right local memory pages. This assumes NUMA hardware run in NUMA mode (each CPU has N pages of memory with consecutive physical addresses as opposed to interleaving the address space across all processors as some NUMA boxes can do.
I'm having a problem with the 23.6 Ablett full-feature compile. (I used the 64-bit version; I didn't try the 32-bit version.) I set up an Arena tournament with skill levels 1 through 5, along with a few non-crafty engines. All of the Crafty 23.6 skill levels lose just about all games by time forfeit. Crafty just doesn't move fast enough and usually doesn't make the 40/4 time control. I do have the noise 100000 command in the crafty.rc file, which seems to fix time forfeit issues when using full-strength Crafties. (It doesn't seem to make a difference with the low skill values, so I guess it's OK to leave it in the configuration file.)
I tried the same tournament with the same crafty.rc file using Crafty 23.5, and I had no problems. Crafty 23.5 would use most of the clock early and would have to make a mad scramble to make time control, but it always did make it.
I know that Jim won't be making any more compiles, but I thought this was worth mentioning just in case the problem is a source code issue.
Jimbo I wrote:I'm having a problem with the 23.6 Ablett full-feature compile. (I used the 64-bit version; I didn't try the 32-bit version.) I set up an Arena tournament with skill levels 1 through 5, along with a few non-crafty engines. All of the Crafty 23.6 skill levels lose just about all games by time forfeit. Crafty just doesn't move fast enough and usually doesn't make the 40/4 time control. I do have the noise 100000 command in the crafty.rc file, which seems to fix time forfeit issues when using full-strength Crafties. (It doesn't seem to make a difference with the low skill values, so I guess it's OK to leave it in the configuration file.)
I tried the same tournament with the same crafty.rc file using Crafty 23.5, and I had no problems. Crafty 23.5 would use most of the clock early and would have to make a mad scramble to make time control, but it always did make it.
I know that Jim won't be making any more compiles, but I thought this was worth mentioning just in case the problem is a source code issue.
It is probably related to how I "slow down" the search. The "spin loop" does not pay attention to the time, which might be a problem at very fast games...
On your hardware, can you tell me the normal NPS, and the NPS at those very low skill settings? I might can tune that a bit...
OK, I checked. It's a dual core laptop, but I only run the engine on one thread.
The normal Crafty runs at around 2,600 to 3,000 KNPS, and the low skill level Crafties run at around 3 KNPS normally, but sometimes get up to 6 or 8 KNPS.
I hope that's enough information to go on. Thanks Bob!
Jimbo I wrote:OK, I checked. It's a dual core laptop, but I only run the engine on one thread.
The normal Crafty runs at around 2,600 to 3,000 KNPS, and the low skill level Crafties run at around 3 KNPS normally, but sometimes get up to 6 or 8 KNPS.
I hope that's enough information to go on. Thanks Bob!
That 6-8K might be too slow. I see about 5M nps (one thread) on my dual-core 2.0ghz i7 macbook. I'll take a look at my slowdown and see if there is another solution. Tried nano sleep() but it did not work very well and slowed it down too much... will keep looking...
Jimbo I wrote:OK, I checked. It's a dual core laptop, but I only run the engine on one thread.
The normal Crafty runs at around 2,600 to 3,000 KNPS, and the low skill level Crafties run at around 3 KNPS normally, but sometimes get up to 6 or 8 KNPS.
I hope that's enough information to go on. Thanks Bob!
That 6-8K might be too slow. I see about 5M nps (one thread) on my dual-core 2.0ghz i7 macbook. I'll take a look at my slowdown and see if there is another solution. Tried nano sleep() but it did not work very well and slowed it down too much... will keep looking...
Just a quick thought: maybe the number of nodes until checking the clock again needs to be adapted to NPS? E.g. if you always check after 64k nodes then with 5MNPS you check the clock about every 13ms but with 8KNPS you do that every 8 seconds ...
