Author: Matthias Gemuh
Date: 01:22:24 05/13/02
Go up one level in this thread
On May 12, 2002 at 15:31:28, Tim Foden wrote:
>On May 12, 2002 at 07:29:12, Matthias Gemuh wrote:
>
>>On May 12, 2002 at 05:34:48, Tim Foden wrote:
>>
>>>On May 12, 2002 at 02:53:12, Matthias Gemuh wrote:
>>>
>>>>On May 12, 2002 at 00:23:07, Robert Hyatt wrote:
>>>>
>>>>>On May 11, 2002 at 05:48:17, Matthias Gemuh wrote:
>>>>>
>>>>>>
>>>>>>Hi Experts,
>>>>>>how much faster can I compute attacks when I rotate ? 5%? 20%? 50%?
>>>>>>I don't understand rotation and hope the gain is 1% speed boost :-).
>>>>>>Regards,
>>>>>>Matthias.
>>>>>
>>>>>It is more than that. The main thing is that it eliminates the loop needed
>>>>>to find where a particular diagonal, file or rank is blocked. Generating
>>>>>the attacks on a particular "ray" becomes a simple table lookup...
>>>>
>>>>
>>>>I don't loop. I use an idea from Crafty (blocking squares)
>>>>
>>>>if (((MovesAndAttacks->obstructed[k][j] & BitBoth) == 0) &&
>>>> (MovesAndAttacks->SlidingMoves[bishop][k]&ChsPos->Mask[j]))
>>>>
>>>>tells me bishop on square k can move unhindered to square j.
>>>>Is this too expensive ?
>>>
>>>Let's see if I understand this. You have a bishop on square k, and you are
>>>testing whether the bishop can be moved to square j?
>>>
>>>How do you get the value for j?
>>>
>>>Maybe an example of generating ALL the moves for the bishop would be more
>>>beneficial.
>>>
>>>A rotated bitboard implementation will do something like this (this is adapted
>>>from the code in Green Light):
>>>
>>>
>>> // first we generate the bitmap of all moves
>>>
>>> int rank = Rank(from);
>>> int file = File(from);
>>>
>>> UINT8 diag1 = m_bitBoard.m_rows[bbDiag1 + 7 + rank - file];
>>> UINT8 diag2 = m_bitBoard.m_rows[bbDiag2 + rank + file];
>>> UINT64 diag1Moves = m_diag1Moves[from][diag1];
>>> UINT64 diag2Moves = m_diag2Moves[from][diag2];
>>>
>>> // we remove moves that take the bishops own pieces
>>> UINT64 bitmap = (diag1Moves | diag2Moves) & ~m_colourBoard[m_wtm];
>>>
>>> // now we generate the moves
>>> while( bitmap )
>>> {
>>> Square to = BitScanForwardRemove(bitmap);
>>> moves.Add( CMove(cBishop, from, to) );
>>> }
>>>
>>>What would your code to generate all the bishop's moves look like?
>>>
>>>Cheers, Tim.
>>
>>
>>
>>
>>Your solution looks smarter. I will study it carefully.
>>Yes, I need a loop to get that "j" when generating moves. In eval(), j be some
>>interesting target (got without loop).
>>I do this for white:
>>
>> BitS = WhiteBishops;
>> while (BitS) {
>> nFrom = FirstOne(BitS); Move = PutFrom(Move,nFrom);
>> if (ChsPos->piece[white][bishop] & MovesAndAttacks->set_mask[nFrom])
>>Move = PutPieceNr(Move,bishop);
>> Move = PutEp(Move,0); Move = PutPromo(Move,0); Move =
>>PutCapturedNr(Move,0);
>> moves = MovesAndAttacks->SlidingMoves[bishop][nFrom] & BitEmpty;
>> while (moves) {
>> nTo = FirstOne(moves); Move = PutTo(Move,nTo);
>> if ((MovesAndAttacks->obstructed[nFrom][nTo] & BitBoth) == 0) {
>> MoveList[nIndex] = Move; nIndex++;
>> }
>> Klear(nTo, moves);
>> }
>> Move = PutEp(Move,0); Move = PutPromo(Move,0); Move =
>>PutCapturedNr(Move,0);
>> moves = MovesAndAttacks->SlidingMoves[bishop][nFrom] &
>>ChsPos->occupied[black];
>> while (moves) {
>> nTo = FirstOne(moves); Move = PutTo(Move,nTo);
>> if ((MovesAndAttacks->obstructed[nFrom][nTo] & BitBoth) == 0) {
>> Move = PutCapturedNr(Move, ChsPos->PieceOnSq[nTo]);
>> MoveList[nIndex] = Move; nIndex++;
>> }
>> Klear(nTo, moves);
>> }
>> Klear(nFrom, BitS);
>> }
>>
>>
>>This generates noncaptures, then caps.
>
>OK. In Green Light I actually have separate code for generating captures and
>non-captures, so that the quiescence search only calls the capture code, and the
>normal search doesn't have to generate non-captures if it gets an early cut off.
>
>>I generate 10 million pseudolegal per sec on Athlon 1.4GHz.
>
>Your movegen speed will probably vary depending on the current position. Which
>position was this in?
>
>You can test Green Light using the "perf" for all psuedo moves, and "perfc" for
>only captures.
>
>In this position:
>
>[d]r1bqkb1r/ppp2ppp/2n2n2/3pp3/3PP3/2N2N2/PPP2PPP/R1BQKB1R w KQkq - 4 5
>
>on my AXP1700+ I get almost 37,000,000 moves generated per sec:
>
>>perf
>37 moves: Nxd5 Nxe5 exd5 dxe5 Nb1 Ne2 Na4 Nb5 Ng1 Nd2 Nh4 Ng5 Bd2 Be3 Bf4 Bg5 Bh
>6 Be2 Bd3 Bc4 Bb5 Ba6 Rb1 Rg1 Qd2 Qe2 Qd3 Kd2 Ke2 a3 b3 g3 h3 a4 b4 g4 h4
>Generate moves:
>Iterations: 1000000 Time: 1.001
>Iterations/sec: 999001.0 Moves/sec: 36963037.0
>Generate, make, unmake moves:
>Iterations: 1000000 Time: 5.859
>Iterations/sec: 170677.6 Moves/sec: 6315070.8
>>
>
>>Too slow approach maybe.
>
>Possibly. In fact I believe that it may be possible to generate moves faster by
>not using a bit-board approach at all... :-/ I'm thinking about trying it
>sometime.
>
>Cheers, Tim.
My figures (on Athlon 1.4) are a mess: 9000000 and 2540000 moves/sec.
Thanks,
Matthias.
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.