Author: Dezhi Zhao
Date: 08:56:54 06/24/04
Go up one level in this thread
On June 24, 2004 at 11:17:50, Robert Hyatt wrote:
>On June 24, 2004 at 09:03:57, Gian-Carlo Pascutto wrote:
>
>>On June 24, 2004 at 07:56:32, Anthony Cozzie wrote:
>>
>>>Bob's code looks like this in assembly:
>>>
>>>if(wtm)
>>>{
>>> xor eax+0x334, ebx //take memory at eax+0x334 and xor it with ebx
>>> ...
>>>
>>>Your code would look like
>>>
>>> xor eax + 8*ecx + 0x334, ebx
>>> ^--- Index register
>>>
>>>Register pressure is one of the biggest problems with bitboards on x86. Just
>>>having 1 bitboard in registers requires almost 1/3 of the registers.
>>
>>I don't see how this is possibly a justification:
>>
>>1) Because of the same register pressure you're talking about, most of the
>>data in x86 is retried from caches. Duplicating code is not helping
>>cache pressure.
>
>Caches are getting bigger and bigger. 1995 had 16kb as big. Today has
>512-1024K as big and that can even be pushed higher if you want to pay...
>
>
>>
>>2) You need to handle the branch too. The cost of that is going to be way
>>higher than the cost of setting up/restoring a register.
>
>
>That branch is probably predicted perfectly. it is "yes" "no" "yes" "no".
>something the PIV handles well although others do not.
I think it is most probably not predicted. If it is in a small loop, the
prediction works fine. However the cpu has executes too many instructions before
it meets this branch again in the next ply. The search easily beats the pattern
reconigzation used in PIV.
>
>
>
>>
>>>Switch is _fast_. Again, in assembly:
>>>
>>> and eax, 0xF
>>> jmp table[eax]
>>
>>An indirect jmp fast?
>>
>>Are you joking?
>>
>>Also good luck with getting the compiler to generate that code.
>>
>>--
>>GCP
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.