Life In 19x19

Ah seems you're right - appears there is a non-cuda version in your link.

You still need to build a newer version of Lizzie if you want more than just winrates and move suggestions though

The most confusing part is to compile the cudahelpers.cu into an obj file. I made a batch file to run in command prompt with this contents:

NVCC cudahelpers.cu -c --cudart shared -gencode arch=compute_30,code=sm_30 -gencode arch=compute_30,code=compute_30 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_53,code=sm_53 -gencode arch=compute_53,code=compute_53 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_70,code=compute_70

Then you just need to put all the source code as defined in the cmakelist.txt into a project with the cudahelper.obj and compile in VS2017 IDE. Of course you also have to download any packages needed.

Version 1.2-beta is now available with precompiled Windows OpenCL binaries
https://github.com/lightvector/KataGo/releases

OpenCL and Windows support are new, so there maybe be some further bumpiness in getting it working, so let me know if you run into problems or have questions. Happy to fix the inevitable bugs that arise.

For anyone in the boat of "compiling myself is way too scary"/"I don't have an nvidia GPU"/"The CUDA version didn't work for me", maybe this is all working now? I hope!

Enjoy!

@splee99 - not exactly sure what your compile set up looks like, but I didn't ever have to manually invoke nvcc compiling for CUDA, was there some issue you ran into, or maybe you were on a sufficiently much older version that something was fixed between then and now? I compiled the CUDA version attached in the release more-or-less by following the same instructions I posted to the latest readme at https://github.com/lightvector/KataGo#windows

Parameters for sabaki, 1.2-beta opencl:

manage engines...
katago
d:\katago\katago.exe
gtp -model d:\katago\model.txt -config d:\katago\gtp_example.cfg

can set the time, for example time_settings 0 10 1

in the folder d:\katago place the network file for example from https://github.com/lightvector/KataGo/releases g104-b15c192-s297383936-d140330251.zip, unpack, use model.txt

This Shin Jinseo game illustrates a situation in which KataGo arrives at the correct positional evaluation very quickly compared to pure zero bots, such as LZ.

http://www.go4go.net/go/games/sgfview/84421

On Reddit (https://www.reddit.com/r/baduk/comments ... nt/eu0xgjz) uberdude shows that even with large numbers of playouts LZ has trouble. However, even at a couple thousand playouts KataGo is able to see that white has a crushing advantage.

MiniGo and Elfv2 were much better at quickly evaluating the position correctly, so not all zero bots fail as badly as LZ here. I've not studied ladder problems much in recent networks, but a while ago I noticed a trend that (locally speaking irrespective of the truth of what's on the diagonal) Elfv1 tended to not see ladders or assume they didn't work, whilst 15b LZ tended to assume ladders do work. So in cases the ladder DOESN'T really work as here LZ will fail badly, and in cases the ladder DOES work Elf fails badly. I don't know about MiniGo.

That's definitely pretty strange. I have noticed that on low playouts certain versions of LZ seemed to assume ladders work, but never realized there was a pattern. I've been really liking KataGo 1.1 for analysis, since I end up playing handicap games a lot on kgs.

It's more complex these days. In a recently discussed game LZ definitely looked the opposite corner where it had a few stones, got convinced the ladder doesn't work and pulled out. A nice step forward (except this ladder worked, but search couldn't see this since policy didn't suggest the - assumed to be broken - ladder moves).

How can I check performance, for example, visits or n/s? interesting to compare OpenCL and cuda

And wrote:How can I check performance, for example, visits or n/s? interesting to compare OpenCL and cuda

Download them both, try them out on a variety of positions to adjust how many threads you should use for best performance for each one, and see how long searches with different numbers of visits takes?

in sabaki katago plays on any boards up to 19x19. even 2x2! using one network! unfortunately more than 19x19 does not work, probably a restriction in the release (using sabaki you can play on boards up to 25x25)
Perhaps the strongest program for the game 13x13 and 9x9?

And wrote:How can I check performance, for example, visits or n/s? interesting to compare OpenCL and cuda

Unsure if there is a way. I benchmarked by bringing up a complex middlegame position in Sabaki for each engine and then literally timing playouts per second using a stopwatch. You can set a large playout limit for each engine, and then tell it to generate a move.

Note that you must optimize the number of threads manually for KataGo, since I believe the default is one. This is a bit complicated, since as lightvector points out the engine becomes weaker as threads increase. There will be an inflection point where speed gains become small and are no longer overcoming the loss of strength due to increasing threads further.

I settled on 16 threads for my hardware. At this setting KataGo was close to twice as fast generating playouts as the 40-block LZ network. That is similar to Elfv2, which makes sense given that they are both 20-block networks.

hoa803 Thanks, I'm interested in a test like in Lz (--benchmark). By the way, in gtp.log I found information about visits

Marcel Grünauer wrote:KataGo vs Leela Zero at time parity of 10 sec/move:

KataGo vs ELFv2 = 1 : 9
KataGo vs LZ-157 = 4 : 6
KataGo vs LZ-130 = 9 : 1

For reference, LZ-125 beat Zhao Baolong 2p; he said he might win one or two in a hundred games if he can exploit a ladder weakness. But KataGo has special ladder support, so it's still strong enough for us amateurs. And it can deal with handicap stones.

Are you using only one search thread? If so, I would expect better results if you increase the number search threads KataGo is allowed to use. I should probably make the default larger, although given the wildly different specs on different user's systems, it's hard to pick a particular good number in advance. If you have a strong GPU, the number ideal of search threads can actually be significantly more than the number of cores that your CPU has, since it's more about making sure the GPU is well-fed and the CPU cores will often be idle waiting on the GPU anyways.

hoa803 wrote: I benchmarked by bringing up a complex middlegame position in Sabaki for each engine and then literally timing playouts per second using a stopwatch. You can set a large playout limit for each engine, and then tell it to generate a move.

Sorry about the stopwatch.

I'll add a utility to the next release version that should auto-time the bot on a set of hardcoded test positions with different number of threads and report the speed for each, so that it's easier to choose a number of threads. Or maybe, to even auto-tune it, although that might take a bit more work (OpenCL parameters are auto-tuned and stored already, but the way search threads are handled is slightly different).