Komodo 12.3 is out

[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.

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.

It seems that a good chunk of the benefit of 7 man TB is just the rook and 2p vs rook and p endgame plus the small KPPPkpp, which can be put on a fairly small SSD along with 6 man with no big cost of download or SSD. As long as you put only the most useful endings you can fit on your SSD, and optimize the Probe Depth, it shoud be fine for blitz games. But we will need feedback from our customers to confirm this, it's all so new.

[kasinp]

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.

Here is the surprising fact: using 7-men Syzygy with Komodo 12.3 default settings will *reduce* SSD access. I suppose hitting a 7-men position renders a bunch of 6-men probes unnecessary.

I played almost a thousand games with Komodo pre-release and 12.3 versions at 1+3, and numbers were consistent. With Probe Depth of 8 and Smart Syzygy turned off, the total number of SSD hits for 7-men was about half of the 6-men version. I used 48 most commonly found 7-men endgames (from a 15MM Chessbase db), worth 770GB of WDL files on a Samsung 960 m.2 drive (DTZ files residing on a slower drive). Given the actually less intense probing, it is not surprising that reported nps between two versions was indistinguishable. On a 14-core Xeon they were both up to 40,000nps and a typical comparison of TB hits would be 85MM for 6-men vs. only 40MM for 7-men version (reading from an actual 154-move draw at 1+3). The fact that reported depths were always just a bit less for 7-men seems to support the reason for less SSD probing. In the same example it was 43.5 plies average to only 38.6 plies average for 7-men version.

PK

[ernest]

It seems that a good chunk of the benefit of 7 man TB is just the rook and 2p vs rook and p endgame plus the small KPPPkpp, which can be put on a fairly small SSD along with 6 man with no big cost of download or SSD.

Are you sure ???

A pawn will necessarily promote, so you will absolutely need the 7 man TB where a pawn is replaced by a piece...

[kasinp]

It seems that a good chunk of the benefit of 7 man TB is just the rook and 2p vs rook and p endgame plus the small KPPPkpp, which can be put on a fairly small SSD along with 6 man with no big cost of download or SSD.

Are you sure ???

A pawn will necessarily promote, so you will absolutely need the 7 man TB where a pawn is replaced by a piece...

You *may* need them to play it out (not if the resulting position is simple enough). But not for being able to assess the value of a position in search. For that wouldn't reading the score be enough (therefore saving you having to go deeper - see my previous post). If the position is a win, then it is a win irrespective of what happens to that pawn. And that is how most hits happen I would think.

PK

[Sesse]

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.

For analysis.sesse.net, I chose to simply do it outside the regular UCI interface. The patched Stockfish opens up a HTTP/2 port that speaks gRPC, where I can query the hash table at will.

Not sure if this is going to fly with GUIs, though… But it sure is a much nicer interface for this kind of request/response probes.

[lkaufman]

I don't think that we can continue to gain five elo per month with regular Komodo. But we have been averaging close to fifty elo per month with MCTS, so even if this drops to something reasonable like twenty per month, after a year everyone should be happy!

Do you think you can sustain 20 Elo per month once Komodo MCTS reaches the current strength of regular Komodo?

If so that would make Komodo incredibly strong in very little time. The Stockfish team took basically took 10 months to gain 50 Elo going from SF9 to SF10. That's 5 Elo per month. 20 Elo per month is 4 times the rate of improvement. It would be unheard of. It would be insane.

It would be unrealistic to predict 20 elo per month gain once we catch normal Komodo, but the main point is that there is no obvious limit or sense that we are anywhere near any kind of peak. It is likely that progress will be choppy, maybe 10 elo one month, then suddenly 30 or 40 elo when we make a breakthru. We might stall out when reaching normal Komodo level, but there is no particular reason to think so, the searches are VERY different. If we find a way to use NN and GPU the sky is the limit.

[lkaufman]

I don't think that we can continue to gain five elo per month with regular Komodo. But we have been averaging close to fifty elo per month with MCTS, so even if this drops to something reasonable like twenty per month, after a year everyone should be happy!

Do you think you can sustain 20 Elo per month once Komodo MCTS reaches the current strength of regular Komodo?

If so that would make Komodo incredibly strong in very little time. The Stockfish team took basically took 10 months to gain 50 Elo going from SF9 to SF10. That's 5 Elo per month. 20 Elo per month is 4 times the rate of improvement. It would be unheard of. It would be insane.

It would be unrealistic to predict 20 elo per month gain once we catch normal Komodo, but the main point is that there is no obvious limit or sense that we are anywhere near any kind of peak. It is likely that progress will be choppy, maybe 10 elo one month, then suddenly 30 or 40 elo when we make a breakthru. We might stall out when reaching normal Komodo level, but there is no particular reason to think so, the searches are VERY different. If we find a way to use NN and GPU the sky is the limit.

[Gabor Szots]

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.

Thank you for the explanation, Larry.

[ChiefPushesWood]

I'm wondering if I can get some help getting this product, that Larry says I'm entitled to because of my purchase of Kom 12.2.2, downloaded. I've posted here and sent emails. Starting to get frustrated with the lack of response.

CPW

[Ozymandias]

If we find a way to use NN and GPU the sky is the limit.

Just using the GPU should give a 20x speed increase. That's quite the Elo jump, on its own.

Using a NN for the evaluation, when Komodo already has a fine tuned humanly coded one... I would rather look for a way to mix MCTS data with the regular version, it should be possible to allow MCTS to influence traditional evaluation.