Komodo 12.3 is out

[Eelco de Groot]

Also please note that although 12.3 MCTS is still nearly a hundred elo below normal 12.3, it can already defeat 12.3 if both are in MultiPV = 2 (or more) mode. For this reason, I have switched to using the MCTS version myself when analyzing games or openings.
"Version 12.3 will probably be the last one that combines regular and MCTS Komodo, they will soon become distinct programs, although subscribers will still get both. My personal view is that the future looks very bright for Komodo MCTS, as it is still in its infancy or perhaps early childhood".

THIS...might just convince me to subscribe once again!

As I use Komodo 11.3.2 (or other engines) ONLY for analyzing games or openings I am curious as to how you or others do this. Stockfish 10 really isn't that suitable for such things as far as I can see.

I've an ordinary Desktop i7-6700 @3.4GHz with 16 GB RAM...like to use this computer for some minor things while analyzing over the course of an evening, so I generally limit engines under Chessbase 15 to 2 threads, 2-3 Multi-PV.

I do not remember seeing on the Komodo website (have not visited it in a while) anything about how to get the most out of Komodo MCTS for game or opening analysis...do you or anyone else have some tips or could you point me somewhere which would be of assistance?

Thanks!

The main tip is that with MCTS you can now feel free to look at all the moves you like; as far as we can tell, there is no elo loss from setting MultiPV to 2, 3, or even 218 ! With normal Komodo, MultiPV 2 costs something like 100 elo, MultiPV 3 another fifty or so, etc. Also with normal Komodo you have to pay attention to trying to finish iterations; with MCTS it makes sense to quit any time that the two best moves are not nearly equal.

One might argue this is no true MultiPV mode, as long as the PV lines don't have about the same number of visits.

OTOH, this could lead to reconsider the way how MultiPV is done with Alpha-Beta search.
It doesn't seem to make much sense to put/waste the same amount of time/calculations into inferior lines.

Thank you for this new version,
and good luck with the further development.

Also because rootnode is not very different from other PV nodes, it seems okay to do something like this in all PV nodes which would suggest no LMR etc. in PV nodes. That would be the first thing I try if I was Larry Even if it would be an ELO loss, it would open up possibilities for output with many more long sidelines like Vas already did with Rybka. If Larry still has the latest modified UCI code from Rybka, possibly not it was Rybka IV I think but maybe he could get it from Vas and it would be easy to implement then. Very difficult to get in touch with Vas I think.

[mjlef]

Larry or Mark,
I'm getting an error when trying to download 12.3. I purchased 12.2.2 so I'm eligible. My Account is, indeed, showing me the 12.3 folder. But when I click on download 12.3, I get this: Not Found

The requested URL /play/komodo-12.3-ee4a9c9a.zip was not found on this server.
Apache/2.4.18 (Ubuntu) Server at u.komodochess.com Port 80

Advise please?

CPW

PS.
I sent an email via the website as well.

I think I replied to you via email. A couple of people have had problems downloading. If anyone else does just email me and I can manually send any purchase. Since I have not seen but a couple of these reports I think this is rare and maybe related to first day release demand.

[mjlef]

Also please note that although 12.3 MCTS is still nearly a hundred elo below normal 12.3, it can already defeat 12.3 if both are in MultiPV = 2 (or more) mode. For this reason, I have switched to using the MCTS version myself when analyzing games or openings.
"Version 12.3 will probably be the last one that combines regular and MCTS Komodo, they will soon become distinct programs, although subscribers will still get both. My personal view is that the future looks very bright for Komodo MCTS, as it is still in its infancy or perhaps early childhood".

THIS...might just convince me to subscribe once again!

As I use Komodo 11.3.2 (or other engines) ONLY for analyzing games or openings I am curious as to how you or others do this. Stockfish 10 really isn't that suitable for such things as far as I can see.

I've an ordinary Desktop i7-6700 @3.4GHz with 16 GB RAM...like to use this computer for some minor things while analyzing over the course of an evening, so I generally limit engines under Chessbase 15 to 2 threads, 2-3 Multi-PV.

I do not remember seeing on the Komodo website (have not visited it in a while) anything about how to get the most out of Komodo MCTS for game or opening analysis...do you or anyone else have some tips or could you point me somewhere which would be of assistance?

Thanks!

The main tip is that with MCTS you can now feel free to look at all the moves you like; as far as we can tell, there is no elo loss from setting MultiPV to 2, 3, or even 218 ! With normal Komodo, MultiPV 2 costs something like 100 elo, MultiPV 3 another fifty or so, etc. Also with normal Komodo you have to pay attention to trying to finish iterations; with MCTS it makes sense to quit any time that the two best moves are not nearly equal.

One might argue this is no true MultiPV mode, as long as the PV lines don't have about the same number of visits.

OTOH, this could lead to reconsider the way how MultiPV is done with Alpha-Beta search.
It doesn't seem to make much sense to put/waste the same amount of time/calculations into inferior lines.

Thank you for this new version,
and good luck with the further development.

Also because rootnode is not very different from other PV nodes, it seems okay to do something like this in all PV nodes which would suggest no LMR etc. in PV nodes. That would be the first thing I try if I was Larry Even if it would be an ELO loss, it would open up possibilities for output with many more long sidelines like Vas already did with Rybka. If Larry still has the latest modified UCI code from Rybka, possibly not it was Rybka IV I think but maybe he could get it from Vas and it would be easy to implement then. Very difficult to get in touch with Vas I think.

I do not think Larry every had source code for Rybka. But anyway, if GUI writers would come up with a UCI spec for examining game trees in memory, the data is certainly in Komodo MCTS and I could the PVs available.

Mark

[MikeB]

oh wow komodo 12.3 is out, how thrilling

(Ecclesiastes 5:10)  A lover of silver will never be satisfied with silver, nor a lover of wealth with income. This too is futility.

I too, am thrilled. But like you, I shall also wait with baited breath for 12.4,5,6,7,8...

We are never satisfied.

Ecclesiastes - just took a deep dive into this book this past fall - written centuries ago, it's just as true today as it was written then. Vanities of vanities!

[ChiefPushesWood]

I think I replied to you via email. A couple of people have had problems downloading. If anyone else does just email me and I can manually send any purchase. Since I have not seen but a couple of these reports I think this is rare and maybe related to first day release demand.

Just checked, Mark. I haven't received any emails from you. Mind double-checking?

CPW

[hgm]

But anyway, if GUI writers would come up with a UCI spec for examining game trees in memory, the data is certainly in Komodo MCTS and I could the PVs available.

Mark

GUI developers are not likely to do anything if you do not make it clear to them what you need.

Besides, I am not sure new protocol would be needed for this. You could just define an option 'Static tree readout' that is an alternative to UCI_Analyze. As long as both are set you would not do any real searches, but just probe the hash table, and fake a search by constructing a PV (or a set of PVs, if the MultiPV setting requires so) from the probed data, and send that in reply to the go-infinite command. Users could then step through the memory tree as they would do during an interactive analysis.

If you want to provide a more dynamic view, you could define a spin option 'split depth' that would work in combination with MultiPV. It would cause the engine to send PVs that only start deviating after the number of moves this option specifies. I don't think the UCI specs require that the PVs sent in multi-PV mode all start with a different move.

[lkaufman]

May I have a question. Let's say I'mwilling to allocate 256 MB of RAM altogether for Komodo MCTS, playing 40/4 games. Is that amount enough? What is the optimal distribution of RAM among the 3 areas Komodo uses (table momory, hash, MCTS hash). In general, what is the optimal ration between them using x MB total RAM?

MCTS hash has a minimum of 128, so you have to use that default value (maybe we should reduce the minimum to 64 or less for people like yourself). That's way more than you need for blitz games. For the other 128, since Komodo uses 3x(2**X) MB, you should use 96 for regular hash, leaving 32 for table memory, which is more than enough for blitz. So in your case the decision is rather easy. If we had no minimum on MCTS hash, I would use 192 for regular hash, 48 for MCTS, and 16 for Table Memory for blitz games. I can't give a general formula as it depends on threads, time control, and available memory, but for blitz games there is no need to raise MCTS Hash, and Table Memory can safely be reduced to 32 unless you have a machine with many threads, in which case you would probably have ample memory. It's only for longer time control games that small memory is a problem.

[Nordlandia]

One question for Mark and Larry:

Now Komodo support up to 7 pieces egtb, fine. Any slowdown test inflicted by probing 7-piece compared to 6-piece tried out yet?

Scenario: whole 7-piece on ssd. What kind of slowdown in speed can we see.

Also is 7-piece ssd something on the agenda, like 2019 or onwards. Storing 7-piece on ssd is expensive but quite useful if money allow it.

I don't know if the pros of 7-piece consulting outweight the speed penalty inflicted by probing the set itself. Any thoughts about this subject?

For handicap matches, Komodo has used 5-piece egtb for avoiding engine slowdown.

[lkaufman]

One question for Mark and Larry:

Now Komodo support up to 7 pieces egtb, fine. Any slowdown test inflicted by probing 7-piece compared to 6-piece tried out yet?

Scenario: whole 7-piece on ssd. What kind of slowdown in speed can we see.

Also is 7-piece ssd something on the agenda, like 2019 or onwards. Storing 7-piece on ssd is expensive but quite useful if money allow it.

I don't know if the pros of 7-piece consulting outweight the speed penalty inflicted by probing the set itself. Any thoughts about this subject?

For handicap matches, Komodo has used 5-piece egtb for avoiding engine slowdown.

We set "Smart Syzygy" to true as default and Syzygy probe depth to 8 as default in Komodo 12.3 because they seem to work well on a good laptop with six man tb and selected 7 man tb. On a desktop with a good SSD we suspect that a lower probe depth can be used with smart syzygy and some 7 man tb, perhaps even as low as 2. We have just limited and unclear data on this point though. In the handicap matches we didn't have 6 man tb on SSD until the last match, so we didn't use 6 man tb until that match.

[MikeB]

One question for Mark and Larry:

Now Komodo support up to 7 pieces egtb, fine. Any slowdown test inflicted by probing 7-piece compared to 6-piece tried out yet?

Scenario: whole 7-piece on ssd. What kind of slowdown in speed can we see.

Also is 7-piece ssd something on the agenda, like 2019 or onwards. Storing 7-piece on ssd is expensive but quite useful if money allow it.

I don't know if the pros of 7-piece consulting outweight the speed penalty inflicted by probing the set itself. Any thoughts about this subject?

For handicap matches, Komodo has used 5-piece egtb for avoiding engine slowdown.

I know you asked Mark and Larry directly - but since you asked in an open forum, others are free to answer as well. My $.02, From my personal experience, one will have issues with 7 man syzygy in any kind of match that has bullet like time controls- even 2 min with 6 seconds. You can safely use 6 man syzygy's if you place the entire set on SSD drive for match play. The main benefit I have seen so far with 7 man syzygy is with analysis with some 7 man or 8 man positions, but, I suppose that will change once one can place a good chunk of the 7 Man TB''s on SSD drive, but for most people, that is not a realistic cost option at this time. Good question, would like to hear Larry and/or Mark's perspective on this as well.