KataGo V1.3

[And]

in default_gtp.cfg file if searchnumSearchThreads = 6 or 8, works (tuning does not occur, the message "gtp ready" appears, genmove b - ok). if = 12, 16, 32 the test starts, tuning does not occur, the message "gtp ready" appears, genmove b - the KataGo stops working. that is, the same error is not.
deleted dummy file tune6_gpuGeForceGT610_x19_y19_c320_mv8.txt, set searchnumSearchThreads = 1, same error as at the beginning.
set searchnumSearchThreads = 32, g170e 20 block s3.35G - tuning ok

[And]

30 block network works without problems for more than 12 hours (match engines). Auto tuning does not work. can I edit the opencltuning file obtained for a 20 or 40 block network, and what needs to be replaced? Could this lead to an error or performance degradation?

[lightvector]

in default_gtp.cfg file if searchnumSearchThreads = 6 or 8, works (tuning does not occur, the message "gtp ready" appears, genmove b - ok). if = 12, 16, 32 the test starts, tuning does not occur, the message "gtp ready" appears, genmove b - the KataGo stops working. that is, the same error is not.
deleted dummy file tune6_gpuGeForceGT610_x19_y19_c320_mv8.txt, set searchnumSearchThreads = 1, same error as at the beginning.
set searchnumSearchThreads = 32, g170e 20 block s3.35G - tuning ok

30 block network works without problems for more than 12 hours (match engines). Auto tuning does not work. can I edit the opencltuning file obtained for a 20 or 40 block network, and what needs to be replaced? Could this lead to an error or performance degradation?

Given that you found 6 or 8 threads works, but 12 threads or more threads doesn't work, when using the 30 block networks (even if you skip the tuning), I'm going to guess that running the 30 block net is simply right on the borderline of what your GPU can handle.

I'm surprised the tuning, of all things, would cause it to fail as well, since the tuning allocates an amount of memory a little smaller than actual usage - it tunes using operations equivalent to a batch size of 2, in theory. But maybe there's something about the way the tuning is implemented that makes it more resource intensive, perhaps the fact that it also tries a lot of sub-optimal computational configurations too in the process of trying to find the best one?

Anyways, you just said that the 30 block networks works fine for you for smaller numbers of threads if you just use the 20 or 40 block net's tuning file. It's probably not optimal, but I don't see the point in trying to fiddle with it more if you can't run the tuning and the net anyways is borderline almost unable-to-be-handled by your GPU. You can try the 40 block network instead if you like. The 40 block net should be *less* resource intensive than the 30 block net regarding resource limits despite being more blocks, since the convolutions it does are smaller (256 channels, instead of 320).

Other than that, I think there's nothing for you to do here. If you want to run the 30 block with large numbers of threads (large batch size), I guess you might simply need a better GPU.

[And]

thanks! for some reason I'm interested in the 30 block network. on another computer I have a GTX 1650. but part of the time I’m at a computer with a GT 610. if I understood correctly, I can use the opencltuning file of 20 blocks network

[ez4u]

@lightvector As you continue your training, which of the new nets seems stronger the 30-block or the 40-block? What seem to be the differences between them?

[lightvector]

They're very similar. The 30 block net has more parameters. Unsurprisingly, it seems to persistently be about 20 Elo ahead in my internal tests with equal search.

But highly noisy, sometimes it appears behind due to measurement noise in the number of games I'm using in internal tests or because by random luck in fact not as far ahead at that point I sampled. This is more sort of an "on average" thing across many different points in training across the last month.

But it's also slower to evaluate, which cancels out that advantage. So probably on most hardware the 40 block net will be better than the 30 block. For users on weaker hardware, likely even the 20 block net will still be better than either of those - it's trailing by about 120 Elo right now, but still improving due to continued training on the big-nets data, and will get much deeper search than the big nets which will probably more-than-compensate that on weaker hardware and/or for lower numbers of playouts.

[MagicJade]

Hi,LightVector!
Just one simple question: does "kata" mean anything?
Is it from Japanese or Greek? someone told me it
could be a girl's name!

[lightvector]

New neural nets released!
https://github.com/lightvector/KataGo/r ... 1.3.5-nets

And just for fun, a special version for bigger board sizes:
https://github.com/lightvector/KataGo/r ... 3.5%2Bbs29

[And]

lightvector it's just a holiday !!! I am very very very grateful to you !!! I almost stopped hoping for the game on big boards in the foreseeable future

[And]

Auto tuning for version 29x29 15,20 and 40 blocks does not work. but networks work with renamed files from version 19x19! 30 blocks does not work in any way (GT610)
maybe I’m lucky to choose working values for 30 blocks empirically
I don’t know how and why it works. therefore perhaps this is not worth repeating!

[And]

how to make a game 29x29 of two networks to get a sgf file? Is there a way around the 25x25 restriction for sabaki? or some kind of script to play directly using the gtp? can I launch a game from two networks on the command line?

[lightvector]

The only way to get around the 25x25 restriction for a particular GUI program or match-playing software is to request that program or match-playing software to implement a way to handle coordinates for larger sizes compatible with the way KataGo extended the GTP protocol for coordinates. The way I had KataGo implement seemed like by far the most natural way to extend the protocol for coordinates, and is the same as a common choice that board editing GUIs or even spreadsheets like Excel/Google Sheets use to label more coordinates - namely, after Z, you get AA, AB, AC, .... but I'd also be open for adding minor hacks to do a different format if necessary to be compatible with something else.

It's slightly unfortunate that the designer(s) of GTP did not look forward to try to be future-proof and include a specification for how to go past 25x25, or choose a coordinate format in the first place that would be more general and doesn't suffer from limited range, such that we now have this problem. But I've also of course written software where a seemingly minor choice had to be made early and it turned out not to be the right one later, but was stuck with it - it's also hard to be future-proof sometimes.

[bernds]

The only way to get around the 25x25 restriction for a particular GUI program or match-playing software is to request that program or match-playing software to implement a way to handle coordinates for larger sizes compatible with the way KataGo extended the GTP protocol for coordinates. The way I had KataGo implement seemed like by far the most natural way to extend the protocol for coordinates, and is the same as a common choice that board editing GUIs or even spreadsheets like Excel/Google Sheets use to label more coordinates - namely, after Z, you get AA, AB, AC, .... but I'd also be open for adding minor hacks to do a different format if necessary to be compatible with something else.

I think KataGo gets to set the standards these days. I've implemented this scheme in q5go and it seems to work. Code is available on github, and I'll make a new binary release one of these days.

[And]

bernds excellent! please also add support up to 37x37. this is interesting, see for example https://senseis.xmp.net/?LargeBoards

[And]

25x25 KataGo g170 6 block s1.75 (1 visits) - leela 11 (default, about from 50000 to 100000 visits) 1:0