TalkChess.com

This is very unlikely. For one, compilers and linkers allocate variables as a contiguous set. they have no reason at all to leave large, unused holes between them. So if your total of global variables / tables does not exceed 1MB, they will all nicely map in one L2 cache way without possibilities f...

I don't like the assumption however. You assume that with 4-way, 4mb cache, each way is 1mb. I agree there. But then you assume that your program is laid out in memory in such a way that the "important stuff" doesn't have any aliasing issues (here I am talking about memory to cache set addressing co...

POSIX threads already provides that facility. You can run multiple threads on one physical CPU if you want to. Of course there would be no speedup, and the overhead would actually slow you down some to boot.

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...