CPU usage at 505 in WInboard Engine

[mjlef]

One person testing my chess program reports that in WinBoard, using PolyGlot, my program is taking up 50% of the CPU time when the other program is search (my engine does not ponder yet, so it should just be sitting in an idle loop waiting for input). Does this happen with anyone else? I do not see it it the Shredder or Arena interfaces.

Mark

[Pradu]

sitting in an idle loop waiting for input)

You don't poll for intput in a loop right?

Code: Select all

while(!hasInput());

This will use up CPU. Mabe try fgets.

[mjlef]

The program is in Pascal, and there seems no simple OS-independat way to determin if stdin has input waiting. I use two threads..one for the engine, which waits for a signal from the other thread, which just reads the input.

[Tord Romstad]

The program is in Pascal, and there seems no simple OS-independat way to determin if stdin has input waiting.

Does it have to be OS-independant? Wouldn't it be possible to have separate versions of the IO code for each OS you want to support? It is probably a very small part of the program, after all.

I use two threads..one for the engine, which waits for a signal from the other thread, which just reads the input.

That's fine, but if your IO code runs in a loop waiting for input when the engine is not thinking, I don't think you can avoid using 50% of the CPU. You have to use something resembling fgets, think. If nothing else works, perhaps it would be possible to call the C fgets() function by using some kind of foreign function interface? Surely it must be possible to call C functions from Pascal?

It's nice to see that people are still writing strong chess programs in other languages than C/C++. Too many people think C/C++ is the only way to go.

Tord

[mjlef]

Tord,

I can try linking to a small C routine like fgets. But I think the problem might be not there, since the existing Pascal input routines hang until they get something, and I assume the OS is clever enough to swith to other processes at that point. I think I need some kind of OS dependant code in the search thread which passes control to other proceses for some fixed time (maybe 1/100th of a second or so). I had to do that in a Windows GUI for another program many years ago.

BTE, looking at Glaurung gives me many ideas. Maybe I will catch up with you eventually! I am testing some of the ideas in there now, to see if NOW agrees with them (NOW matched nearly all fo them from past testing). Should NULL searches be done while in the PV (in the past, NOW did better allowing them). Should other reductions be allow in the PV? If way ahead should checks be included in the qsearch? When I have tested these things in the past there has not been a clear advantage either way. I am using the Shredder GUI for very fast (like 1 minute) games. It seems to have the least overhead of all the GUIS I have tried, so it can play game faster than say Arena.

Mark

[Tord Romstad]

Tord,

I can try linking to a small C routine like fgets. But I think the problem might be not there, since the existing Pascal input routines hang until they get something, and I assume the OS is clever enough to swith to other processes at that point. I think I need some kind of OS dependant code in the search thread which passes control to other proceses for some fixed time (maybe 1/100th of a second or so). I had to do that in a Windows GUI for another program many years ago.

Perhaps you could have a look at how some of the open source Delphi chess programs handle this?

BTE, looking at Glaurung gives me many ideas.

Great! I'm glad somebody is able to make use of it. The source code is a rather popular download (about 600 downloads for version 1.2 so far), but I am not sure how many people actually look at the code.

Maybe I will catch up with you eventually!

I hope you will. Glaurung is a very simple program, really. I think its main strength is that it has few serious bugs.

I am testing some of the ideas in there now, to see if NOW agrees with them (NOW matched nearly all fo them from past testing). Should NULL searches be done while in the PV (in the past, NOW did better allowing them). Should other reductions be allow in the PV? If way ahead should checks be included in the qsearch? When I have tested these things in the past there has not been a clear advantage either way.

I have the same experience. Most of the time, when I try out some new idea, the tests are unconclusive, and I end up trusting my intuition. There is no doubt that my intuition is frequently wrong, but as long as it is right more than 50% of the time it should result in slow, but steady progress in the long run.

I am using the Shredder GUI for very fast (like 1 minute) games. It seems to have the least overhead of all the GUIS I have tried, so it can play game faster than say Arena.

That's rather surprising. I don't use Windows, but on my Mac, the Shredder GUI actually feels rather slow. It also doesn't support engine matches, so in practise I hardly ever use it. I use XBoard or my own new GUI for running my test matches.

Tord

[mjlef]

I am using the Shredder GUI for very fast (like 1 minute) games. It seems to have the least overhead of all the GUIS I have tried, so it can play game faster than say Arena.

That's rather surprising. I don't use Windows, but on my Mac, the Shredder GUI actually feels rather slow. It also doesn't support engine matches, so in practise I hardly ever use it. I use XBoard or my own new GUI for running my test matches.

Tord[/quote]

Hmmm, that sounds neat. None of the GUIs I have tried seem ideal for us programmers. Is this somehting you will be releasing? Will it gave feature search capabilities ( would love to say be able to search for positions where scores differ by say 2 pawns or more for 2 moves in a row).

I like a couple of the graphical things in the Shredder GUI. It shows a graph of scores uisng colored bars, so you can visually see how one program compares the position to the other. There is a simple line showing time used per move (NOW's is practically staright...something I need to work on to have the program spend more time when in trouble). These graphs are very useful in very fast games. I can see, for example, that Rybka gives a big bonus for say R&B&Ps versus N&B&Ps. More than the traditional "2 pawn" difference.

Mark

[Guenther Simon]

Hmmm, that sounds neat. None of the GUIs I have tried seem ideal for us programmers. Is this somehting you will be releasing? Will it gave feature search capabilities ( would love to say be able to search for positions where scores differ by say 2 pawns or more for 2 moves in a row).

I like a couple of the graphical things in the Shredder GUI. It shows a graph of scores uisng colored bars, so you can visually see how one program compares the position to the other. There is a simple line showing time used per move (NOW's is practically staright...something I need to work on to have the program spend more time when in trouble). These graphs are very useful in very fast games. I can see, for example, that Rybka gives a big bonus for say R&B&Ps versus N&B&Ps. More than the traditional "2 pawn" difference.

Mark

Jeff, all GUIs I know can show such a graph, yes also Winboard
4.27x(I bet it has the least overhead also BTW, except pure xboard
of course). WB also has tools which allow to search for what you
described in your first paragraph(searching for a score difference
for x moves). Most known is called Toms Game Analyzer.

Regards,
Guenther

[Tord Romstad]

I use XBoard or my own new GUI for running my test matches.

Hmmm, that sounds neat. None of the GUIs I have tried seem ideal for us programmers. Is this somehting you will be releasing?

Yes, I will, and I hope to have an early beta version ready for testing very soon. You probably won't be able to use it, though: It's for Mac OS X only. It's possible that there will be a Linux port later, but a Windows port wouldn't be possible without rewriting almost every single line of code.

I started working on a GUI last year, which can still be downloaded from my Glaurung page. Unfortunately I had to stop working on it while it was still in a rather buggy and unfinished state, because I replaced my PowerPC Mac with one of the new Intel Macs, and it turned out that the development tool I used didn't work on Intel Macs.

A couple of weeks ago, I decided to start from scratch again. Progress is extremely slow, partly because I have to use Objective-C, a programming language I don't have much experience with, and partly because of the very nice weather in Oslo this summer.

Here is a screenshot of how it looks right now:

http://www.glaurungchess.com/beta/Glaurung.png

Those who have seen my old GUI will notice that the graphics is mostly the same, but all code is completely rewritten.

Will it gave feature search capabilities ( would love to say be able to search for positions where scores differ by say 2 pawns or more for 2 moves in a row).

I like a couple of the graphical things in the Shredder GUI. It shows a graph of scores uisng colored bars, so you can visually see how one program compares the position to the other. There is a simple line showing time used per move (NOW's is practically staright...something I need to work on to have the program spend more time when in trouble). These graphs are very useful in very fast games. I can see, for example, that Rybka gives a big bonus for say R&B&Ps versus N&B&Ps. More than the traditional "2 pawn" difference.

Thanks for the feature suggestions - I'll keep them in mind. The challenge is to find a way to include them without messing up the interface too much. My main goal is to have a GUI which is stable, fast, and easy to use, without having tons of features which 99% of the users never use.

Tord

[Volker Pittlik]

...It's possible that there will be a Linux port later...

Wow, Christmas in July

Volker

[Steve Maughan]

I am using the Shredder GUI for very fast (like 1 minute) games. It seems to have the least overhead of all the GUIS I have tried, so it can play game faster than say Arena.

That's rather surprising. I don't use Windows, but on my Mac, the Shredder GUI actually feels rather slow. It also doesn't support engine matches, so in practise I hardly ever use it

The PC version of Shredder Classic is written in C/C++ whereas the MAC / Linux versions are Java - hence the speed difference. I use Shredder Classic and I agree with Mark, it's the best from a developers perspective, although it isn't perfect. Tord - if you ever switch to the dark side I'd recommend you pick up a copy of Shredder Classic.

Best regards,

Steve

[Tord Romstad]

...It's possible that there will be a Linux port later...

Wow, Christmas in July

The two are almost the same, at least in the Scandinavian languages ("Christmas" = "jul", "July" = "juli").

I'm afraid I can't do a Linux port myself, though. I will release the source code and hope that somebody else can help me port it to Linux. Technically, a Linux port shouldn't be very difficult to do. The program is written using Objective-C and Apple's Cocoa toolkit, and there is a mostly Cocoa-compatible GUI library called GNUStep for Linux. The main problem is that there are rather few programmers who know the Objective-C programming language.

Tord

[Tord Romstad]

I use Shredder Classic and I agree with Mark, it's the best from a developers perspective, although it isn't perfect. Tord - if you ever switch to the dark side I'd recommend you pick up a copy of Shredder Classic.

Yes, it's not too bad. In fact I have some superficial experience with it: I used the Shredder Classic GUI in Windows during the tournament in Mainz last year. This year, I plan to use my own GUI.

Tord