Winboard Forum

Hi,

I try to interact with the fritz gui and have a problem left:

The fritz gui shows the "thinking" (pv, nodes, nodes/s, ...) of spike many seconds too late. In Blitz it does not show any thinking at all.

I have the "thread" soloution of input/output handling. Thus one thread that waits for input and an other thread that searches and writes the output. It seems that non thread programs don?t have this problem (example fruit 1.5).

I don?t have any problems with arena. It is not a "flush buffer problem", I have set the buffer to 0. I tried "WriteFile", puts, fprintf, printf for output, none solved the problem.

The following "work-arounds" works. I don?t like these work-arounds:

1. Giving the search-thread a lower priority.
2. Writing much more info-strings. If I write an info string every 10 milliseconds, it will show its thinking approximately every 2 seconds.
3. Doing a Sleep(10) after each output.

Any idears how to fix this problem?

Tanks! Volker

Slow Chess also experiences the same problem from the Fritz GUI.
One thing you can try is to switch the threads (the input and thinking threads, ie. creating the input thread with createthread, and using the main process for the thinking thread.)
After doing this the thinking lines appeared almost like normal. But still the Fritz GUI is late on displaying the thinking by a few percent (either that or the Fritz GUI runs Slow a couple percent slower than any other GUI.) I probably should have done this for the released Slow Chess, but I wondered if it was possible to get completely normal behaviour in the Fritz GUI then never got back to this issue.

Thank you for your advice, but I don?t like the main thread searching. The reason is, that perhaps I will build a parallel version of spike. Then the thinking threads must be created.

Maybe I will add a "Fritz-GUI-Compatibility-Option" in UCI that lowers the thread priority.

Greetings Volker

Hi,

I found the soloution myself . I didn?t expect the fritz gui to start the process with priority normal, but the main thread with priority below normal.
Jon brought me to this idea, thus I checked the main thread priority from spike under fritz gui this afternoon. It is below normal.

Now in Spike we read the thread-priority of the main thread and set the priority of every additional created thread to the same priority. This works fine for fritz gui and for arena (that starts the treads with priority normal).

Greetings Volker

Have you tried analyzing a couple positions in the Fritz GUI then in another GUI? No matter what I do I always end up with slower analysis in the Fritz GUI, like what takes 15 seconds instead takes 16 or 17 in the Fritz GUI, or what takes 30 seconds takes 32 or 33. I'm not sure whether or not it's just the Fritz GUI being slower to display the analysis.

I wonder if anyone knows if this is true for all other programs, or just some, or just Slow Chess.

Hi Jon,

Jon Kreuzer wrote:Have you tried analyzing a couple positions in the Fritz GUI then in another GUI? No matter what I do I always end up with slower analysis in the Fritz GUI, like what takes 15 seconds instead takes 16 or 17 in the Fritz GUI, or what takes 30 seconds takes 32 or 33. I'm not sure whether or not it's just the Fritz GUI being slower to display the analysis.

I wonder if anyone knows if this is true for all other programs, or just some, or just Slow Chess.

Afaik this is true for all engines that are not connected as chessbase native engine. E.g. Ingo Bauer told once at CCC (or somewhere else) that Shredder 9 UCI is some % slower in Fritz GUI then in ShredderClassic. Matthias Feist (ChessBase) told me at Graz that it has something to do with how he loads the engine in the GUI... I think I was a bit to much sleeping to fully understand it, but I remember that it did sound logical...

Greets, Thomas

Monarch displays the exact same behavior in Fritz GUI as you describe. And I do have one thread for the thinking and another for polling the input. So I've tried, with no success, to change the priority of the thinking thread. I'd appreciate it if anyone can point me in the right direction. Here's Monarch relevant code:

Code: Select all

int main()
{
   engine_initialized = FALSE;
   uci_set_author();

   create_uci_engine_thread();
   listen_for_uci_input();
   destroy_hash();

   return TRUE;
}

Code: Select all

void create_uci_engine_thread()
{
   thread_handle = (HANDLE)_beginthreadex( NULL, 0, &engine_loop, NULL, 0, &threadID );
}

All help appreciated!

Thanks,

Steve

Maughan:
I'm not an expert, but to set the thread priority to the same as the main thread (using Win32 programming,) I believe this will work.

hThread = (HANDLE) _beginthread (ThinkingThread, NULL, NULL);
SetThreadPriority (hThread, GetThreadPriority ( GetCurrentThread () ) );

Thomas:
Thanks for the info. I don't like the idea of the Fritz GUI running UCI engines slower than any other GUI. If I was still doing chess programming I'd look into it more myself. (I'd test if SlowChess is really around 4-8% slower, or it's at least partially a display issue, if setting the thread priority makes a difference, and if other engines are that much slower.)

Thats what I do too,

mThread = (HANDLE)
_beginthreadex(0, 0, &GlobalPlay, &mSearch, 0, 0);
int aPriority = GetThreadPriority(GetCurrentThread());
SetThreadPriority(mThread, aPriority);


With the thinking tread priority "below_normal" it is quite clear why you loose some percent of time. Everything in fritz-gui has higher priority than your caluclations.

I still have some problems when playing fritzs vs. spike with ponder on on one cpu. (just a test of interface problems). After a game or two spike waits for fritz gui to do something and fritz gui waits for spike to move. Haven?t found the reason for this. This is not a big problem, but it shows that the interface to fritz gui does not work perfectly.

Without pondering this is no problem.

Greetings Volker

Thanks guys - it works a treat! It was really bugging me that Monarch was not running smoothly under Fritz.

Thanks!

Steve