Komodo 12.2.1

[lkaufman]

Komodo 12.2.1 is now available at komodochess.com. It is free for anyone entitled to Komodo 12.2. Just download 12.2 from the website, and you should get the executables named 12.2.1.
Version 12.2.1 fixes several problems with version 12.2. Version 12.2 would not run on some older machines. Some redundant code was removed, although the benefit was too small to measure. The MCTS version was sometimes displaying mate scores for the wrong side in the Fritz GUI, which could affect testing if that GUI was used. The final scores displayed when a move was made in MCTS mode were completely wrong (regardless of GUI), this should not have affected move choice, but could possibly affect GUI adjudications if any. All of these problems are fixed in 12.2.1. We also made one change to an internal parameter value, which should show a noticeable depth gain (in normal mode) but probably only a tiny elo gain (1 or 2 elo). We have fixed all known bugs, and don't anticipate any further bugfix version of 12.2. Finally, we reduced the default for MCTS Hash from 320 to 128 Mb, so that those with relatively little RAM will be less likely to run into problems. Even 128 is sufficient for play at practical time limits with normal machines. For MCTS analysis or for longer time control games on machines with many cores this number should be raised.
All testers should use 12.2.1 from now on. There is no need to redo any tests of the normal 12.2. As for the MCTS version, any tests on the Fritz gui should be redone, otherwise they are probably ok. Our own tests show a few elo gain for the MCTS version running on four threads, but perhaps most of this was due to statistical margin of error.
We appreciate the input from many users who reported these issues. Komodo is not a big enough business to be able to test every release under every possible circumstance. We would rather get everything right the first time with each release, but I imagine that most of our subscribers would prefer that we spend our time improving Komodo rather than testing every possible way something might have gone wrong with each new release.

[kasinp]

It brings me no pleasure to report a new and I believe serious bug:

Under Fritz GUI, engine match, Komodo 12.2.1 does not release one of the threads and continues to use the CPU *on opponent’s time* with NO PONDER selected.

This behavior does not start immediately; it appears to kick in at some point, but always during the first game of the match. When it begins, I have not seen it go away, i.e. it persists for the remainder of the match.

I have not seen this behavior before and I do run hundreds of 3+2 games daily, under identical conditions. I tested Komodo 12.2.1 this morning on several 8 thread POPCOUNT CPUs, and to be sure also on a 28-thread BMI2 machine. Same symptoms:

On opponent’s time, with the other engine reporting 50% CPU usage, on an 8-thread machine Komodo at some point starts showing 12.5% CPU usage and does not fully release one thread from that point on. On its own time Komodo reports the expected 50% CPU.

Tested under both Fritz 16 and Fritz 14 GUI.
PK

[mjlef]

It brings me no pleasure to report a new and I believe serious bug:

Under Fritz GUI, engine match, Komodo 12.2.1 does not release one of the threads and continues to use the CPU *on opponent’s time* with NO PONDER selected.

This behavior does not start immediately; it appears to kick in at some point, but always during the first game of the match. When it begins, I have not seen it go away, i.e. it persists for the remainder of the match.

I have not seen this behavior before and I do run hundreds of 3+2 games daily, under identical conditions. I tested Komodo 12.2.1 this morning on several 8 thread POPCOUNT CPUs, and to be sure also on a 28-thread BMI2 machine. Same symptoms:

On opponent’s time, with the other engine reporting 50% CPU usage, on an 8-thread machine Komodo at some point starts showing 12.5% CPU usage and does not fully release one thread from that point on. On its own time Komodo reports the expected 50% CPU.

Tested under both Fritz 16 and Fritz 14 GUI.
PK

I have not seen any measurable thread usage when not pondering in Komodo. Naturally there has to be a partially active thread to await command from the chess GUI. But I would like to ask some questions so I can get the same setup you are using. I will send you a private message with the email and we can get more information.

Mark

[mjlef]

It brings me no pleasure to report a new and I believe serious bug:

Under Fritz GUI, engine match, Komodo 12.2.1 does not release one of the threads and continues to use the CPU *on opponent’s time* with NO PONDER selected.

This behavior does not start immediately; it appears to kick in at some point, but always during the first game of the match. When it begins, I have not seen it go away, i.e. it persists for the remainder of the match.

I have not seen this behavior before and I do run hundreds of 3+2 games daily, under identical conditions. I tested Komodo 12.2.1 this morning on several 8 thread POPCOUNT CPUs, and to be sure also on a 28-thread BMI2 machine. Same symptoms:

On opponent’s time, with the other engine reporting 50% CPU usage, on an 8-thread machine Komodo at some point starts showing 12.5% CPU usage and does not fully release one thread from that point on. On its own time Komodo reports the expected 50% CPU.

Tested under both Fritz 16 and Fritz 14 GUI.
PK

I can confirm this is a bug in both Komodo 12.2 and Komodo 12.2.1. After playing a match for a while, something happens and Komodo does seem to keep a thread running when it is not its time to move. This is unfair to the other engine it is playing. I am investigating and will release a fix once I see what happend.

I email CEGT and CCRL to let them know to stop testing Komodo until we can fix this. I am not seeing the issue yet on single thread runs, but I want to test more before claiming those are OK.

Sorry about this and thanks for reporting it quickly. A fix will be coming once I see what is wrong.

Mark

[schack]

Did the reporting of NPS change with 12.2? I'm seeing huge initial reports - tens of millions of positions on a i3 4030U in CB14.

[pohl4711]

Did the reporting of NPS change with 12.2? I'm seeing huge initial reports - tens of millions of positions on a i3 4030U in CB14.

Yes in FritzGUI the NPS displayed by Komodo 12.2.1 are complete nonsense, too, when analyzing a position with more than 1 thread.

[CositasBuenas]

It's working just fine with Aquarium by ChessOK.

[ThatsIt]

No such problems here under Shredder-Classic, 3'+1" ponder=on, x64 1CPU, MCTS-Version.

Best wishes,
G.S.
(CEGT team)

[mjlef]

It brings me no pleasure to report a new and I believe serious bug:

Under Fritz GUI, engine match, Komodo 12.2.1 does not release one of the threads and continues to use the CPU *on opponent’s time* with NO PONDER selected.

This behavior does not start immediately; it appears to kick in at some point, but always during the first game of the match. When it begins, I have not seen it go away, i.e. it persists for the remainder of the match.

I have not seen this behavior before and I do run hundreds of 3+2 games daily, under identical conditions. I tested Komodo 12.2.1 this morning on several 8 thread POPCOUNT CPUs, and to be sure also on a 28-thread BMI2 machine. Same symptoms:

On opponent’s time, with the other engine reporting 50% CPU usage, on an 8-thread machine Komodo at some point starts showing 12.5% CPU usage and does not fully release one thread from that point on. On its own time Komodo reports the expected 50% CPU.

Tested under both Fritz 16 and Fritz 14 GUI.
PK

I can confirm this is a bug in both Komodo 12.2 and Komodo 12.2.1. After playing a match for a while, something happens and Komodo does seem to keep a thread running when it is not its time to move. This is unfair to the other engine it is playing. I am investigating and will release a fix once I see what happend.

I email CEGT and CCRL to let them know to stop testing Komodo until we can fix this. I am not seeing the issue yet on single thread runs, but I want to test more before claiming those are OK.

Sorry about this and thanks for reporting it quickly. A fix will be coming once I see what is wrong.

Mark

A quick update. We found the issue and fixed it but want to test it a lot before releasing.I want to thank PK for finding it and he is helping test the fix as well. Again, sorry for the bug. Testers running 1 thread can keep their results, since this issue only existed for 2 or more threads. We will inform testers and anyone on the Komodo notify email list about the update, and I will announce here when the update is ready.

Mark

[Ozymandias]

Komodo is not a big enough business to be able to test every release under every possible circumstance.

From what I'm seen in these threads and past Komodo bug fixes, it doesn't seem to be a problem with the business size, but rather with the amount of active testers you've got. As long as the team keeps refusing testers, I don't think another explanation can be given, other than it happens because you let it happen.