Lc0: Kiudee setting is very strong

[Laskos]

Do we have now new LC0 default settings?

The tuned settings were done using a mix of short time controls using the T58 (58613) network. These settings should be approximately optimal for all time controls with <20k nodes / move. Even though the CPuct scaling curve is not uniquely determined on slower time controls, it can perform reasonably well on time controls up to <100k nodes, but is likely slightly suboptimal there (though it seemed to perform quite well for T60 on CCC's time control). For 1M+ nodes: no guarantees

I am currently in the process of writing a distributed tuning framework for lc0, which we then could utilize to tune slower time controls than before. These parameters will then likely be better candidates as new defaults, than the currently circulating ones.

Are these setting unique to RTX cards? Would I benefit from trying them on a GTX card?
Thank you
Peter

Yes, node count is important, not the GPU. Anything in the range of 1k - 1000k nodes per move benefits from Kiudee settings, and with most of the nets (well, not too weird ones).

[kasinp]

Do we have now new LC0 default settings?

The tuned settings were done using a mix of short time controls using the T58 (58613) network. These settings should be approximately optimal for all time controls with <20k nodes / move. Even though the CPuct scaling curve is not uniquely determined on slower time controls, it can perform reasonably well on time controls up to <100k nodes, but is likely slightly suboptimal there (though it seemed to perform quite well for T60 on CCC's time control). For 1M+ nodes: no guarantees

I am currently in the process of writing a distributed tuning framework for lc0, which we then could utilize to tune slower time controls than before. These parameters will then likely be better candidates as new defaults, than the currently circulating ones.

Are these setting unique to RTX cards? Would I benefit from trying them on a GTX card?
Thank you
Peter

Yes, node count is important, not the GPU. Anything in the range of 1k - 1000k nodes per move benefits from Kiudee settings, and with most of the nets (well, not too weird ones).

Thank you, your explanation helps. I will certainly give it a try.
Peter

[bmp1974]

There was an earlier suggestion to include changing "Shortsightedness" value. It is suggested in the Github to use a value of 0.02. Someone had tested with 0.05 with good result.

[Kiudee]

There was an earlier suggestion to include changing "Shortsightedness" value. It is suggested in the Github to use a value of 0.02. Someone had tested with 0.05 with good result.

I did a tune of only ShortSightedness. The parameter interacts with the other parameters like CPuct, etc, which is why I will do a proper joint tune later. The result of the isolated tune is here:


A value of 0.05 is significantly worse than 0.02 or the other optima and cannot be recommended.

[Kiudee]

Do we have now new LC0 default settings?

The tuned settings were done using a mix of short time controls using the T58 (58613) network. These settings should be approximately optimal for all time controls with <20k nodes / move. Even though the CPuct scaling curve is not uniquely determined on slower time controls, it can perform reasonably well on time controls up to <100k nodes, but is likely slightly suboptimal there (though it seemed to perform quite well for T60 on CCC's time control). For 1M+ nodes: no guarantees

I am currently in the process of writing a distributed tuning framework for lc0, which we then could utilize to tune slower time controls than before. These parameters will then likely be better candidates as new defaults, than the currently circulating ones.

Are these setting unique to RTX cards? Would I benefit from trying them on a GTX card?
Thank you
Peter

The settings are not unique to RTX cards - in fact it was tuned on a GTX 1080.

[corres]

...
I am currently in the process of writing a distributed tuning framework for lc0, which we then could utilize to tune slower time controls than before. These parameters will then likely be better candidates as new defaults, than the currently circulating ones.

I wait curiously the result of your works but I am afraid there are no universally "best" parameters because the effectiveness of parameters depend not only from Leela and the used net and hardware but the behavior of the opponent also.
You can determine "best" parameters for CCC final where the GPUs, the used net and the opponent (Stockfish, mainly) are given but we, common Leela and net user have different GPUs, different nets and we use Leela against different opponents. So I think we should be satisfied if you can find in some measure "better" but universal parameters instead of the "best" parameters.
Basing on my experience the most of the default parameters of Leela are rather good for general using.

[Kiudee]

...
I am currently in the process of writing a distributed tuning framework for lc0, which we then could utilize to tune slower time controls than before. These parameters will then likely be better candidates as new defaults, than the currently circulating ones.

I wait curiously the result of your works but I am afraid there are no universally "best" parameters because the effectiveness of parameters depend not only from Leela and the used net and hardware but the behavior of the opponent also.
You can determine "best" parameters for CCC final where the GPUs, the used net and the opponent (Stockfish, mainly) are given but we, common Leela and net user have different GPUs, different nets and we use Leela against different opponents. So I think we should be satisfied if you can find in some measure "better" but universal parameters instead of the "best" parameters.
Basing on my experience the most of the default parameters of Leela are rather good for general using.

I agree that for many parameters you can find specific values optimal for a very specific time control. That being said, for default parameters it still makes sense to provide a configuration, which works well for a wide range of time controls (we can’t expect a typical user to be an engine tuning expert, who (1) knows with which parameters to fiddle and (2) knows that thousands of games are necessary to find a better configuration).
In general, we try to design parameters which naturally adapt to the given time control. The cpuct scaling curve (as defined by cpuct, cpuctbase and cpuctfactor) tries to accomplish exactly that: increasing cpuct when more and more visits are coming in. And many people forget that a lower cpuct is not only an improvement in the root node, but does improve the quality of the evaluations in the complete tree (thus it even improves the search for LTC). Still, I think that the scaling curve is not yet optimal for time controls with 100k+ nodes per move.

[cc2150dx]

Off topic:

Is "Fpu" the same as "FpuValue" ? because I don't see "Fpu" in the uci options. Thanks

[Laskos]

Off topic:

Is "Fpu" the same as "FpuValue" ? because I don't see "Fpu" in the uci options. Thanks

Yes, the same.

[mig2004]

I had a run in my LTC chess engine ladder, (90 min 45 sec/per move) using latest Lc0 version as of jan 28, with blass backserver (no gpu).

Lco works very well up to middle game, approx up to move 35, then it loses eggregiously afterwards. I suspect configuration using blass must be quite different. Any suggestions for blass-based configuration?