Early "prefetch" instruction for probing TT is not a waste of time.hgm wrote:I never noticed that. I always start calculating the hash key, to use it for repetition detection. If the move is a repetition, then making it is a waste of time. (And probing the TT would also be a waste of time.)
Hash cache
Moderators: hgm, Rebel, chrisw
-
Aleks Peshkov
- Posts: 892
- Joined: Sun Nov 19, 2006 9:16 pm
- Location: Russia
Re: Hash cache
-
bob
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Hash cache
Hopefully most will be cache-to-cache. It even gets transported L3 to L3 if this is a dual-chip box with two (or more) L3 caches.hgm wrote:The private CPU caches simply reloads from memory or the shared L3 when the thread access those memory location from the new CPU, not?
For me, a split block contains a lot of data, and each thread (for crafty) has 64 split blocks. Don't want those to be on a different node from the thread using them, otherwise the cache miss penalty will double or more.
-
Aleks Peshkov
- Posts: 892
- Joined: Sun Nov 19, 2006 9:16 pm
- Location: Russia
Re: Hash cache
What about the case of pawn's double push en passant capture flag being invalid due pinned opponent's pawn? Do you just ignore such case?hgm wrote:I always start calculating the hash key, to use it for repetition detection. If the move is a repetition, then making it is a waste of time. (And probing the TT would also be a waste of time.)