TRACE 1.33B Available

[Ross Boyd]

Hi all,

A tester reported a CPU hogging problem between TRACE 1.33 and Spike 8.0a under WildCatGUI. TRACE was being most unsporting by stealing all the CPU.

Therefore, I have released a fixed version which calls Sleep(1) instead of Sleep(0) while waiting for input.

As an added bonus a bug that has haunted me for months now is fixed. TRACE is now capable of long searches greater than 4 Giganodes without any problems. Phew!

TD's and Testers take note, 1.33 and 1.33B are identical except for the above two fixes. They play identically. ie Equally badly...

You can download 1.33B now from TRACE's homepage....

http://members.optusnet.com.au/~john.boyd/

Cheers and Enjoy!

Ross

[Ralf Schäfer]

Hi Ross,

thank you for delivering a solution this fast! The reason that Spike allowed this (beside that Trace is very attracting ) was that the search-thread runs with a "lower than normal" priority, this solved a problem with the Fritz8-Gui which was reported to us by some users.

The Problem was that the thinking lines came up by the Gui right _after_ the move was made, not during the thinking. In case of pondering they immediately disappeared again for the upcoming thinking lines of ponder-search. It seemed that the Gui still could not show the information because the searching thread had to high priority.

Has someone else experienced the same behaviour with his/her engine, and even better, has someone found a solution for this?

Best
Ralf

[Alessandro Scotti]

Hi Ralf,
it is possible that, like maybe in the (infamous) "blocked-ReadFile" bug, this behavior is caused by scheduling issues in the OS kernel.
Like Ross said, if you run a thread at lower than normal priority, it's important that other engines that need to yield some timeslice use Sleep(1) rather than Sleep(0), because the latter will only yield to threads that have higher or same priority of the calling thread. However, you might experience a slight disadvantage when pondering is enabled, because when you think at "lower than normal" priority the other engine could be pondering at "normal" priority and be given more CPU. Have you experienced unequal CPU times under these conditions?