On-line engine blitz tourney June

[D Sceviour]

Do you not have a mechanism to iterate over the legal moves in Schooner?

No. It is doubtful an iteration over the legal moves would show anything for the current problem of non-reproducible errors. The FWS function has already shown there is nothing wrong with the move generator. I will add Perft on the list of things to add, but FWS reveals the same conclusions and more. The suggestion for adding Perft is welcome.

[D Sceviour]

A log file was set up to record the information for the root position PV move and the ply 1 PV move. That should be enough to expose any one-move blunders and sufficient to not slow down the program with too much output. A thread may not be helpful because it would probably have to interfere with mutex. A drop in 50 elo was predicted beforehand. A test last night with Arena produced 52 games at blitz 5 1. Unfortunately, the test program won 46-6 so it did not seriously blunder yet. It produced 209 Mb of log files.

More header information is needed to track the game output. The setup uses:

"feature name=1 reuse=0"

Arena (and maybe other xboard based GUI's) only sent the name once, and after that it re-sent the name as "user". This gives a log file that can be named something like:

debug_user_06-19-2017_04_29_33.log

where the numbers represent the date and time the log file was created. Obviously more information is needed to track the game header information. Is there a way to obtain more header information from the GUI such as the tournament round number and the player names?

[D Sceviour]

[d]8/5pk1/p5p1/4p2p/7P/1p3qP1/2n5/1N3QK1 b - - 1 45

The following bug occurred in Kingslayer-Schooner. Here is the output from the debug file:

Code: Select all

5893454 <first : 8 1704 0 10838  c2e3 f1f2 f3d1 g1h2 e3g4 h2g2 g4f2 b1c3 d1e1 c3b1
5893456 <first : 9 1672 0 15561  c2e3 f1f2 f3d1 g1h2 e3g4 h2g2 g4f2 b1c3 d1e1 c3b1 e5e4
5893463 <first : 10 1774 1 30375  c2e3 f1f2 f3d1 g1h2 e3g4 h2g2 g4f2 b1a3 d1e1 a3c4 f2e4 c4e5
5893475 <first : 11 1723 2 57657  c2e3 f1f2 f3d1 g1h2 e3g4 h2g2 g4f2 b1c3 b3b2 c3d1 f2d1 g2h2 b2b1q
5893491 <first : 12 1830 4 96367  c2e3 f1f2 f3d1 g1h2 e3g4 h2g2 g4f2 b1a3 d1e1 g2f3 e5e4 f3g2 e4e3 g2f3 b3b2
5893522 <first : 13 1854 7 166027  c2e3 f1f2 f3d1 g1h2 e3g4 h2g2 g4f2 b1a3 d1e1 a3c4 f2e4 g2f3 e4g3 f3g2

This cannot be duplicated in the subsequent analysis. It would be nice to have a guess (even a bad guess) as to what to look for and why it does this. This frustrating non-reproducible type of error occurs in maybe one in 100 games. Normal asserts and light debug code show no problems arising that would make it play unbearable moves. Nor was there any memory crash or segmentation violation. I am considering opening a new log file to record non-standard events. Suggestions as to what to include might be helpful. Perhaps restrict the saved information only for the PV moves, otherwise the hard drive might fill up too quickly. For the log file maybe include:

(1) game information header
(2) generated move list to see if moves like f1f3 are even in there.
(3) position structure information for each move

One problem found after logging unreproducible errors was in a bitscanforward subroutine. It was written simply as bsfq rax,rcx for the 64-bit version. However, it cannot be assumed the rax register is overwritten by bsfq. Random numbers occasionally appear in the rax register once in a billion instructions. In the given game example above, this might have created a false to_square for the Queen moves since bsfq is used to determine the to_square in the move generation phase. The problem can be fixed with a minimal clearance:

xor rax,rax
bsfq rax,rcx

The same method applies to the bsrq instruction. Whether this will solve all the problems with unreproducible errors has yet to be seen. Another method found on the internet is to include the 64-bit extended instruction. Can anyone confirm if cltq works for the bsrq instruction?

bsfq rax,rcx
cltq

[jdart]

it cannot be assumed the rax register is overwritten by bsfq

That is true, but your proposed fixes will not work, I believe. The rax register is the dest for bsfq. The only case in which rax will not be set by the instruction is the case in which the source operand is zero. So you need to do a test for that case before calling the bsf instruction.

Clearing eax first is questionable because zero is a possible valid result for bsfq when the first bit is set. But then you will also get zero when no bits are set. You could though distinguish between these two cases by testing the ZF flag after bsfq.

--Jon

[D Sceviour]

The only case in which rax will not be set by the instruction is the case in which the source operand is zero.

Not true. It is possible the bsfq instruction only sets the bit in rax up to a value of 64. It does not overwrite the entire register. I wish I could demonstrate with an example but it is difficult to duplicate. On the other hand, could there be something wrong with my hardware? I will use more assert(number) to verify there is no bsfq(0) problem. It should not be a problem because the bsfq instruction usually follows a while(number).

[jdart]

That is not how it is documented to behave. I think your sporadic crash has another cause.

I have never had this issue with bsfq and I use it as an assembly language
bitscan (guarded by the test for 0).

--Jon

[AlvaroBegue]

Why are you guys calling these things in assembly? I use built-in functions like __builtin_ctzll and I don't have to worry about such low-level details as what bits in rax are set by some instruction. I thought everyone would be using built-in functions these days.

[D Sceviour]

That is not how it is documented to behave. I think your sporadic crash has another cause.

I have never had this issue with bsfq and I use it as an assembly language
bitscan (guarded by the test for 0).

--Jon

Intel's Processor Diagnostic Tool showed PASS. Hardware is not the problem.

https://downloadcenter.intel.com/downlo ... ostic-Tool

[D Sceviour]

Why are you guys calling these things in assembly? I use built-in functions like __builtin_ctzll and I don't have to worry about such low-level details as what bits in rax are set by some instruction. I thought everyone would be using built-in functions these days.

The problem with built-in function is they are too big. They are subroutines that push and pull stuff off the stack. The stack pointer has to be reset. They might include error and bound tests. They might perform thread locks. Tight hand coded routines are preferable for things like a move generator. Why use a hundred instructions when one will do?

[jwes]

Why are you guys calling these things in assembly? I use built-in functions like __builtin_ctzll and I don't have to worry about such low-level details as what bits in rax are set by some instruction. I thought everyone would be using built-in functions these days.

The problem with built-in function is they are too big. They are subroutines that push and pull stuff off the stack. The stack pointer has to be reset. They might include error and bound tests. They might perform thread locks. Tight hand coded routines are preferable for things like a move generator. Why use a hundred instructions when one will do?

I am not sure which compiler you are using, but VS 2015 just generates the intrinsic. The line

Code: Select all

k = _tzcnt_u64(tmpb);

generates

Code: Select all

tzcnt       rax,qword ptr [tmpb]  
mov         dword ptr [k],eax  

even in debug mode.