Booot 6.4 release

[booot]

Hello Alex!


I noticed that most Pascal engines use Window API for input/output. I never really understood the reason. In my programs, I simply use the standard "ReadLn" and "WriteLn" and it works, under Linux and under Windows. There must be a reason to use Windows API (since it's what everybody do), but I don't see it.

Hello Roland!
The main reason is to check the current stdin buffer status while searching (pondering) from time to time and to make decision when it is a time to read command from buffer and react on it. Simple readln will wait all the time till someone gives something . Anyway i set the goal for myself to make next release (will be soon) with Linux (Mac?) version. Still do not know my abilities to aim it .

Alex.

[Roland Chastain]

Hello Alex!


I noticed that most Pascal engines use Window API for input/output. I never really understood the reason. In my programs, I simply use the standard "ReadLn" and "WriteLn" and it works, under Linux and under Windows. There must be a reason to use Windows API (since it's what everybody do), but I don't see it.

Hello Roland!
The main reason is to check the current stdin buffer status while searching (pondering) from time to time and to make decision when it is a time to read command from buffer and react on it. Simple readln will wait all the time till someone gives something . Anyway i set the goal for myself to make next release (will be soon) with Linux (Mac?) version. Still do not know my abilities to aim it .

Alex.

Thank you for the answer. If I find time, I will study your code to try to better understand.

[Ras]

Simple readln will wait all the time till someone gives something

One clean technique for that is to have a dedicated input thread which can block on input.

[Roland Chastain]

Simple readln will wait all the time till someone gives something

One clean technique for that is to have a dedicated input thread which can block on input.

Yes, this is what I do in my programs. I have a ReadLn in the main thread, and call my BestMove function in another thread.

Code: Select all

{$IFDEF MSWINDOWS}
{$APPTYPE CONSOLE}
{$ENDIF}

...

procedure SendToUser(const AText: string; const AFlush: boolean = TRUE);
begin
  WriteLn(output, AText);
  if AFlush then
    Flush(output);
end;

type
  TProcessus = class(TThread)
    protected
      procedure Execute; override;
  end;

var
  LPos: TPosition;
  LMoveTime: cardinal;

procedure TProcessus.Execute;
var
  LMove: string;
begin
  LMove := BestMove(LPos, LMoveTime);
  SendToUser(Format('bestmove %s', [LMove]));
end;

...
  
begin
  ...
  while not EOF do
  begin
    ReadLn(LUserCmd);
    ...
    if Copy(LUserCmd, 1, 2) = 'go' then
    begin
      ...
      LProcessus := TProcessus.Create(TRUE);
      with LProcessus do
      begin
        FreeOnTerminate := TRUE;
        Priority := tpNormal;
        Start;
      end;
    end else
    ...
  end;
end.

[MOBMAT]

Interesting. Could you explain how you use it for that purpose? Is there a special option for that, or do you simply send a position and ask for the best move?

I have a big file of test positions which I try to solve for mate. Some are just downright impossible and are designed to find the "best" move and not necessarily a mating move (I'm holding out for a quantum computer!).

I first use the latest Dev version of Stockfish to do initial analysis with PVMulti set to 3. This helps in identifying if the best move is the only best move, only winning move, only drawing move, etc. Once I have a candidate move, I monitor Stockfish's progress. If the score doesn't go up very far after a minute, I know the position is more than likely not an easy mate candidate. If Stockfish's score quickly rises, and usually gets to a Syzygy win score, I then change the PV to 1 and let Stockfish atempt to find a true mate score. I let it search long enough to feel the score is accurate. Of course sometimes, for easy mates, it finds the score in less than a minute.

I then load up another engine for verification. I've tried just about everything including BlackDiamond, MateFinder, etc. Booot 6.3.1 seems to find mates faster than most and this is without EGTBs!

When Booot 6.4 was released, I gave it a try, but it plays a lot slower (but perhaps stronger) than 6.3.1 and in my mate tests never was faster.
The only UCI options available for Booot are the number of threads, which I set to 4 on my machine and the hash, which i set to 16284Mb.
If Booot has problems solving, I'll try another engine, but so far It seems to be the fastest for me.

If I get a score from both engines that seems correct, I note the score with the position (dm = xx) and move onto another position.
If the position is too tough, I annotate it so that I can search for it later for follow up.

That is what I do, your mileage may vary!

[Krzysztof Grzelak]

I still have a problem with this engine, a message pops up.

[Krzysztof Grzelak]

I still have a question about the engine Booot 6.4.

Please write as someone knows how much RAM support and threads

[fastgm]

Booot 6.4_x64_popcnt
uci
id name Booot 6.4_x64_popcnt
id author Alex Morozov
option name Hash type spin default 128 min 16 max 65536
option name Ponder type check default false
option name Threads type spin default 1 min 1 max 64
uciok

[Krzysztof Grzelak]

Thank you for your response fastgm.

The applications I use are Cutechess GUI v1.1.0.f.1.0. I have a processor AMD Ryzen Threadripper 1950X and 128 GB DDR4 memory ram.

[Krzysztof Grzelak]

Roland Chastain have you even tested Booot 3.4.