Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Draw Detection by Move Repetition Procedure -- Comments

Author: vladan

Date: 04:54:15 08/02/04

Go up one level in this thread


On August 02, 2004 at 04:01:50, Gerd Isenberg wrote:

><snip>
>>
>>Hi Gerd,
>>
>>Thanks for the very useful comments.
>>
>>The exceptions you mentioned are important but very rare (<1% in practical
>>play). I have already thought on similar problems before. The fact is that the
>>most of the draw-repetition positions are generated by the check sequences with
>>chains consist of even number of moves, or by moving different pieces. But,
>>anyway, we will try to find elegant solution for those exceptions
>>
>>Your details about the LOOP command are very interesting, I think I have written
>>thousands of LOOP commands in Axon!
>>
>>
>>best regards,
>>
>>Vladan
>>
>>(Axon programmer)
>
>Hi Vladan,
>
>yes, for qsearch one may safely ignore such rare position repetitions.
>They are not likely to happen in perpetual checks.
>
>The problem with Athlon's LOOP instruction is that it is implemented as vector
>path instruction blocking other otherwise parallel available resources.
>
>Athlon32
>LOOP disp8          E2h VectorPath 8
>DEC CX/ECX          49h DirectPath 1
>JNE/JNZ disp8       75h DirectPath 1
>
>
>AMD64
>LOOP disp8          E2h VectorPath 9/8
>The first latency value (9!) is for 32-bit mode.
>The second is for 64-bit mode.
>
>DEC ECX             49h DirectPath 1
>JNZ/JNE short disp8 75h DirectPath 1
>
>Another possible optimization is about rep stosw.
>
>----------------------------------------------------------------------------
>Software Optimization Guide
>for AMD Athlon™ 64 and AMD Opteron™ Processors
>
>8.3 Repeated String Instructions
>
>Optimization
>
>Avoid using the REP prefix when performing string operations, especially when
>copying blocks of memory.
>
>Rational
>In general, using the REP prefix to repeatedly perform string instructions is
>less optimal than other methods, especially when copying blocks of memory. For a
>discussion of alternate memory-copy methods, see “Appropriate Memory Copying
>Routines” on page 112.
>...
>
>Inline REP String with Low Counts
>If the repeat count is constant and low (less than eight), expand REP string
>instructions into equivalent sequences of simple AMD64 instructions. Use an
>inline sequence of loads and stores to accomplish the move. Use a sequence of
>stores to emulate rep stos. This technique eliminates the setup overhead of REP
>instructions and increases instruction throughput.
>
>----------------------------------------------------------------------------
>
>E.g. one may use six mmx-stores to zero 48 bytes (should be 8-byte aligned):
>
>lea    eax, [chain_list]
>pxor   mm0, mm0 ; zero
>movq   [eax+0*8], mm0
>movq   [eax+1*8], mm0
>movq   [eax+2*8], mm0
>movq   [eax+3*8], mm0
>movq   [eax+4*8], mm0
>movq   [eax+5*8], mm0
>
>Cheers,
>Gerd



Hi Gerd,


yes, in real life draw detector works pretty safe.

The same type of pieces could generate “virtual” chains. 2 or more queens, rooks
and knights. Bishops are safe because they move using opposite color fields.
(Hm… theoretically a new bishop could be promoted, and one could play with 3 or
more bishops; in real game it is very, very rare…).

I have already have the solution using external piece information generated by
the Axon’s move generator. I would think a bit more if the problem could be
solved by the simpler method.


Athlon (especial 64 bit version) is hardware optimized, you must be very careful
what to use even for the simplest tasks (like string or matrix reseting).

I’ve already use similar code to reset the 8x8 sub-matrix in 12x12 matrix:


xor eax,eax

mov edi,adress_of_the_raw_1;	stosd; 	stosd
mov edi,adress_of_the_raw_2;	stosd; 	stosd
…….
mov edi,adress_of_the_raw_8;	stosd; 	stosd


Maybe 64 bit code will do the job a few clock tacts earlier…


Thank you very much Gerd for the new aspects of machine coding.

The orthodox C programmers will never understand the difference between 1
million and 2 million positions per second :)   (or Deep Blue’s 200 millions
per.sec.)


regards,

Vladan








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.