[computer-go] State of the art of pattern matching

Mark Boon tesujisoftware at gmail.com
Thu Mar 27 08:08:46 PDT 2008


Jacques,

Yes, I do an incremental update so the board-size should be almost  
irrelevant. I'm not sure why I see any difference between 9x9 and  
19x19 but it may have to do with the fact that the edge cuts a lot of  
pattern seach short.


On 27-mrt-08, at 10:13, Santiago Basaldúa wrote:

> Mark Boon wrote:
>
>> What I have now takes 10-15 microseconds on a 2Ghz Intel computer  
>> to  find all the patterns on a board (on average for 9x9, for  
>> 19x19 it's  more like 15-20 usec)
>
>> From your difference between 9x9 and 19x19 I assume that you are  
>> updating
> the patterns of the cells after a stone was placed, (else the  
> difference should be 361/81 times) not a computation from scratch.  
> I make this sure so that we compare apples to apples. As far as the  
> patterns computing is
> concerned, (i.e. excluding the board part verifying captures, etc.)  
> for
> a pattern of 40 neighbors I get times easily below 500 nanoseconds  
> (even on an old P4 3.4 GHz) for updating 40 hashes. I explained  
> that about
> June last year, when I wrote it. Since it passed my tests (June 07)  
> I have never changed a character in the code that writes the 67090 asm
> lines. It is just a black box, that works 100%. Each board cell has  
> an updating function that knows where the board limits are, the  
> resulting
> code (for hash 32 bit mode) is something like an endless:
>
>           lea     ebx, [edx + ecx*2 - SizeOf_bccCell]
>           mov     eax, 0967f6762h
>           bt      dword ptr [ebx], bidx_StoneBit
>           cmovc   eax, esi
>           xor     [ebx + 4], eax
>           lea     ebx, [edx + ecx*2]
>           mov     eax, 0d83b6518h
>           bt      dword ptr [ebx], bidx_StoneBit
>           cmovc   eax, esi
>           xor     [ebx + 4], eax
>           lea     ebx, [edx + ecx*2 + SizeOf_bccCell]
>           mov     eax, 0121001f7h
>           bt      dword ptr [ebx], bidx_StoneBit
>           cmovc   eax, esi
>           xor     [ebx + 4], eax
>

Sorry, without a bit more explanation, the assembler code is very  
hard to understand. What exactly does it do? Does it relate to a  
pattern? Did you write a paper or post explaining this in more detail?

Do I understand correctly that you generate this code automatically?  
I believe David Fotland does something similiarly. I have thought  
about that but I wasn't sure if that was really much faster.

You are talking about updating 40 hashes. Does it mean your patterns  
have fixed size? In the 500 nanoseconds, how many patterns do you  
compare? One? A thousand? A million? How about rotations and color  
inversions? To make it really an apples to apples comparison I'd like  
to make sure we're talking about the same thing.

Mark



More information about the computer-go mailing list