Author: Ross Boyd
Date: 12:57:20 01/10/05
Go up one level in this thread
Hi Karl-Heinz, There is only one reason why 1.33 scored better than 1.33B... it CHEATED! I'll explain how and why.... Firstly, 1.33 and 1.33B are IDENTICAL. Same speed, same eval, same search. The only difference between them is that 1.33B has two bug fixes. 1. Searches exceeding 4 Giganodes would crash 1.33... so it was a simple fix. 2. When pondering was OFF and 1.33 was waiting for input it was not always giving the CPU back to its opponent. It had an input loop that called Sleep(0) which only released the CPU to processes operating at the same priority. (Normal priority). Some engines, Spike for instance, have a search thread which is on a low priority. So Spike would get very little CPU while TRACE waited for input. Spike may not have been the only engine that was affected in your tournament. Judging by the results I would say several engines were affected by TRACE. So 1.33B was released to fix TRACE's cheating. Now she fully surrenders the CPU by calling Sleep(1) when she loops waiting for input. Note also, that 1.33 was the only release which 'cheated'... and I should mention that the cheating was NEVER intentional. BTW, this behaviour is not a problem on dual CPU's or when pondering is ON or when games are played on separate PCs. But the bottom-line is... DON'T use 1.33 at all. Use 1.33B or greater for all tournaments. Hope that explains it, cheers! Ross PS. I have 1.34 in the pipeline which looks promising compared to 1.33B.
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.