TalkChess.com

Ok - meant as a pathological race between one thread using "dirty" read plus conditional lock exchange versus other threads polling with lock exchange only. Is the "dirty" read before the lock exchange a hyper-threading relict - or is it beneficial with multiple cores also? To safe the write cycles...

Here's the concept as I use it and as it is used most everywhere that wants to use spinlocks. It is called a "shadow lock" where the name comes from keeping a "shadow copy" of the lock in your local cache. You spin on a simple read, which comes from your cache and stays off the system bus. When some...

another suggestion... If you reach any q-search node, and you do not search a check there, there is no point in searching checks at nodes below that point for that side, since any mate you find will be pruned by the "stand pat" score where a check was not played. I used to do checks in the q-search,...

But isn't it possible that one thread never gets the ressource because some ather spinning thread always takes the chance to write a "one" between dirty read a "zero" and lock xchg? Yes it is possible, but maybe this will be the same thing as you never getting the lock because other threads always ...

I assume your program only probes the hash table, but never generates moves, does repetition checks, evaluation, etc? It doesn't use much memory for that. About 6KB of global data, with, the board, piece list and a few lokup tables (e.g. Zobrist random table), ~256 bytes of local variables, and 4 b...

Norm Pollock wrote:I'm waiting for a 1200GB stick drive.

It's amazing how much faster egtb access is when the files are on a stick drive. Currently the available 8GB, good enough for 5-man egtbs, costs around $74 (US).

You should try raid-0 with good SCSI drives to see what real performance can do...

You can easily do that. But the cost is prohibitive, in that the program will play so incredibly weakly because of the internet latency. Currently you do a probe and get an answer back in a few milliseconds. On the internet, multiply that by 100 or 1000, and it would absolutely kill the search spee...

The problem is this: You probe A and miss and do a cache line fill. Now you search all kinds of nodes, and then return to store position A's results. What's the probability it is still in L1/L2?? Pretty thin I would suspect... On the contrary. A 2MB L2 cache contains 32,768 cache lines, so the chan...

You can easily do that. But the cost is prohibitive, in that the program will play so incredibly weakly because of the internet latency. Currently you do a probe and get an answer back in a few milliseconds. On the internet, multiply that by 100 or 1000, and it would absolutely kill the search speed.

I am not seeing how this avoids the classic race condition, which would allow multiple processors to search the same exact tree. If you introduce critical sections, I believe their overhead will _far_ exceed the overhead of doing a normal split algorithm like DTS or YBW... When you start a brand new...