List of bugfree, opensource Linux and MacOSX engines

[Ras]

The only thing I wanted to point out is that it can sometimes happen on a heavily loaded machine that a program is unresponsive for a second or so, because it got swapped out

That would rather be an overloaded machine. RAM shouldn't be used to the point of swapping.

Also, the swappiness setting can be reduced from the standard 60 to maybe 20. That will reduce the inclination to swap. The downside is that rarely used code parts will not be swapped out either, thus the RAM won't be available for file caching. That's why 60 is good for server usage, but can be reduced for desktop.

[OliverBr]

Ok, this is strange.. What is this supposed to mean? Is there a cutechess-cli topic?

Code: Select all

240891 <OliThink 4.1.3(35):  9 -32496     11    425596  a7b8 h1a1 b8c8 a1h8 
240891 <OliThink 4.1.3(35): 70. ... a7b8
240891 >OliThink 4.1.3(34): time 292
240891 >OliThink 4.1.3(34): a7b8
240891 <OliThink 4.1.3(35): whisper -32496(9) 425596 nds 3733000 nps 114 ms 13656 evs
240891 <OliThink 4.1.3(34):  1 32495      0        27  h1h7 
240891 <OliThink 4.1.3(34):  2 32495      0        54  h1h7 
240891 <OliThink 4.1.3(34):  3 32495      0        81  h1h7 
240891 <OliThink 4.1.3(34):  4 32495      0       110  h1h7 
240891 <OliThink 4.1.3(34):  5 32495      0       139  h1h7 
240891 <OliThink 4.1.3(34):  6 32495      0       170  h1h7 
240907 <OliThink 4.1.3(34):  7 32497      0     24576  h1h7 b8c8 h7h8 
240907 <OliThink 4.1.3(34): 70. ... h1h7
240907 >OliThink 4.1.3(35): time 235
240907 >OliThink 4.1.3(35): h1h7
240907 <OliThink 4.1.3(34): whisper 32497(7) 24576 nds 4096000 nps 6 ms 23 evs
240910 <OliThink 4.1.3(35):  1 -1083      0         3  b8c8 
Terminating process of engine OliThink 4.1.3(35)
240916 >OliThink 4.1.3(34): force
240916 >OliThink 4.1.3(34): result 0-1 {White disconnects}

Why does cutechess-cli terminate the process of OliThink 4.1.3(35) during search and it did not even bother sending a "?", nor wait a couple of millisecond?

[hgm]

Here we have absolutely different opinions IMO, when the big majority of engine doesn't have issues, it's a problem of the minority when it has.

So you would also insist that there was something wrong with people that were struck by lightning, because the large majority of people do not have this problem?

I think the basic issue is whether one should accept that there is a very low level of 'background noise' that just randomly awards forfeits/crashes. And I think we would all agree that this is the case. Cosmic radiation can flip memory bits, and flipping memory bits in the code can make any program crash. Error-detecting or error-correcting DRAM just reduces the probability that such a bit-flip would remain undetected by some factor (like 256 if you do parity on every byte of a 64-bit word); it doesn't absolutely zero it.

Under such conditions a crash is not absolute proof that a program was buggy. A cosmic-radiation crash has very small prior likelihood, but OTOH the evidence of 100K games without crash is pretty strong evidence against the hypothesis that the engine is buggy.

That there are other engines that have 1M games or even 10M games without being struck by cosmic radiation just proves that cosmic bit flips have a very low likelihood. But once they happen, they must happen to someone. It is like the 'lottery paradox'. Normally, if a coinf flip produces 10 out of 10 times 'heads', you would reject the hypothesis that it is a fair count, as this hypothesis would assign a probability of 1/1024 to the observed outcome. But if person A wins a lotery with 1M participants, you don't reject the hypothesis that it was a fair lottery. While the chances that A would have won in a fair lottery were only 1/1,000,0000, far smaller than the 1/1024! The crux is that the alternative hypothesis that the lottery was rigged is not 'monolithic', but diversifies in a million different flavors as to in whose favor it waould be rigged. This suppresses the prior likelihood that it was rigged in favor of A by a factor 1M. This is exactly the same factor as the 'fair' hypothesis suffers from the observation that A won. So after this observation the ratio of the likelihood for fair/rigged has not changed at all. In complete agreement with the common-sense argument that "someone had to win". A posteriori knowing who the actual winner was just did not provide any evidence at all. Only when the same person would win twice in a row you would have evidence of foul play. (And I don't think only mathematicians would see that!) In this metaphor "being rigged in favor of A" translates to A being buggy, and winning the lottery = crashing. So you would only reject the hypothesis that the engine has no bugs (i.e. the cosmic-ray lottery being fair) if the same engine crashes twice, while most others don't.

P.S. crossed your last message, which I still have to read.

[hgm]

Ok, this is strange.. What is this supposed to mean? Is there a cutechess-cli topic?

Code: Select all

240891 <OliThink 4.1.3(35):  9 -32496     11    425596  a7b8 h1a1 b8c8 a1h8 
240891 <OliThink 4.1.3(35): 70. ... a7b8
240891 >OliThink 4.1.3(34): time 292
240891 >OliThink 4.1.3(34): a7b8
240891 <OliThink 4.1.3(35): whisper -32496(9) 425596 nds 3733000 nps 114 ms 13656 evs
240891 <OliThink 4.1.3(34):  1 32495      0        27  h1h7 
240891 <OliThink 4.1.3(34):  2 32495      0        54  h1h7 
240891 <OliThink 4.1.3(34):  3 32495      0        81  h1h7 
240891 <OliThink 4.1.3(34):  4 32495      0       110  h1h7 
240891 <OliThink 4.1.3(34):  5 32495      0       139  h1h7 
240891 <OliThink 4.1.3(34):  6 32495      0       170  h1h7 
240907 <OliThink 4.1.3(34):  7 32497      0     24576  h1h7 b8c8 h7h8 
240907 <OliThink 4.1.3(34): 70. ... h1h7
240907 >OliThink 4.1.3(35): time 235
240907 >OliThink 4.1.3(35): h1h7
240907 <OliThink 4.1.3(34): whisper 32497(7) 24576 nds 4096000 nps 6 ms 23 evs
240910 <OliThink 4.1.3(35):  1 -1083      0         3  b8c8 
Terminating process of engine OliThink 4.1.3(35)
240916 >OliThink 4.1.3(34): force
240916 >OliThink 4.1.3(34): result 0-1 {White disconnects}

Why does cutechess-cli terminate the process of OliThink 4.1.3(35) during search and it did not even bother sending a "?", nor wait a couple of millisecond?

Note that "disconnects" is another message than "connection stalls".

I suppose it detected a broken pipe here. (Either EOF on the read-from-engine pipe, or SIGPIPE on the write-to-engine pipe.) You cannot send anything to an engine when the pipes are broken. (Presumably because the engine process terminated; it sems unlikely the engine would close the pipes in other situations.)

Not sure why it still sends 'force'; Of course you can only detect the write pipe is broken when you write, while you are reading all the time, waiting for the engine to say something. So if the engine terminates, the read pipe would detect the EOF immediately, and trigger the game-end procedure. The 'force' might be sent just in case, and have run in the SIGPIPE error (which was then ignored, because error handling was already in progress).

[OliverBr]

Why does cutechess-cli terminate the process of OliThink 4.1.3(35) during search and it did not even bother sending a "?", nor wait a couple of millisecond?

Obviously, the process was terminated because I starting using 64 processes on a 32-core/64-thread machine for Intra-OliThink-Tournaments.
It looks like OliThink413 is not buggy after all. ^^

[OliverBr]

Note that "disconnects" is another message than "connection stalls".

I suppose it detected a broken pipe here. (Either EOF on the read-from-engine pipe, or SIGPIPE on thw write-to-engine pipe.) You cannot send anything to an engine when the pipes are broken. (Presumably because the engine process terminated; it sems unlikely the engine would close the pipes in other situations.)

Absolutely right. Our posts crossed again Obviously the number of used threads were to many.

PS: I will have to do normal work again ,) so until soon )

[hgm]

Processes / threads should not terminate just because there are many; you can run with 64 threads on a single core machine.

At some point the OS could refuse creating new processes / threads, because the process table is full. (If that is fixed size, that is. Perhaps modern Linux can expand it arbitrarily. My knowledge of Unix stems from the seventies...) But it should never terminate an existing process. And I expect it to be able to handle thousands of processes/threads.

[Ras]

Obviously, the process was terminated because I starting using 64 processes on a 32-core/64-thread machine for Intra-OliThink-Tournaments.

Linux doesn't terminate processes just because you load all cores to 100%. I'm using 8 threads (i.e. 8 games concurrently) on a 4C/8T machine, and that works.

However, this did uncover a race condition bug in Zevra 2.1.2 that did not pup up when using only 7 threads. This kind of bug can appear in all engines that have search and input thread separate, and that discard some of the input while search is active instead of buffering it for after search.

[hgm]

In the category "very weak engines", I have the JavaScript AI that powers the Interactive Diagram, so that it can be used as a demo to play against:

theme=MV firstRank=1 symmetry=mirror
Pawn::::a2-h2
Knight:N:::b1,g1
Bishop::::c1,f1
Rook::::a1,h1
Queen::::d1
King::::e1

I wonder if I should port it to C and graft it on a CECP stub, so it could get on the list. The 4-ply version would probably still move instantly, when ported to C.

[towforce]

In the category "very weak engines", I have the JavaScript AI that powers the Interactive Diagram, so that it can be used as a demo to play against:

theme=MV firstRank=1 symmetry=mirror
Pawn::::a2-h2
Knight:N:::b1,g1
Bishop::::c1,f1
Rook::::a1,h1
Queen::::d1
King::::e1

I wonder if I should port it C and graft it on a CECP stub, so it could get on the list. The 4-ply version would probably still move instantly, when ported to C.

That's surprisingly good fun for a weak player like myself!