Leela Zero – Go engine with no human-provided knowledge
github.com
github.com
But at the same time I feel sad for the state of science where working code is still not considered part of the paper, so the code is almost never published, let alone published as Free Software for other scienists (and hobbyists) to tinker with it, to fix it, to improve it, and to adapt it.
For example, why isn't it possible for everyone interested to let Leela Zero play against AlphaGo Zero, on their own hardware (or their university's hardware)?
Even worse is that a friend of mine who is a researcher in neuroscience/BCI has found that many of the papers couldn't be reproduced at all with flawed or incorrect conclusions. Since they typically don't publish their code, its very difficult for others to check the correctness.
Publishing spreadsheets is perhaps an even more urgent issue than publishing other types of code.
And of course the underlying data (anonymized) in case of statistical elicitation, but that's another topic. (Open Access, Open Data and Free Software are very closely related, though).
Of course, there is a non-trivial performance trade-off with more cycles but more objects fits in cache, etc.
Some quick googling gave for example this source which seems to hint that under some situations it is not worth it at least https://stackoverflow.com/questions/4240974/when-is-it-worth...
Lastly, it seems like being quite harsh to call the code being of poor quality because of something like that. Unless it really is very important to get the extra memory, just the maintenance cost of packing things efficiently might make it not worth it. Even production code bases such as the JVM will happily use a single byte (or even more?) to store a boolean, and such things probably occur all over the place.
It might make some didactic sense, but it makes fewer and fewer sense as times go by when you can ship the actual code and shows actual results
In this case the author is DeepMind/Google, so they know how to code and how to distribute it.
However we need not only the code but also the network. Leela Zero is code but more importantly an effort to spread the effort of training the network among many people. Each one volunteers some hw (CPU/GPU) and contributes a part of the training runs. The README states that the estimated training duration on commodity hardware would be 1,700 years. We're not that patient :-)
In any case, you'd still be running a competition between nodes for fastest/best solution, with lots of duplicated effort and consumed resources. That is the key part of crypto consensus afaiu, and regardless of "backend task", there's always going to be waste in this architecture.
That's the ideal situation when everyone plays by the rules. To make that scheme work as a "crypto"currency, you'll also have to make sure that breaking the rules doesn't bring a benefit. E.g. the validation examples can't be known beforehand, otherwise someone could just overfit to them to get a higher score with less work. But I think it might be possible to make it work.
Not all gradient updates improve performance
Hard to make, easy to verify.
This may be a lot harder than you think.
How do you decide that one AI plays better than another? By playing lots of games. These games must be random, i.e. not known beforehand, otherwise the new AI could cheat.
But then, every cryptocurrency node would use a different set of game settings for validation. Which means that some (unlucky) nodes may reject the new AI while others accept it. The result are regular net splits, making it very hard to establish an keep the global consensus that is absolutely needed for a stable cryptocurrency system.
The core issue here is that validation must be 100% deterministic. Each node must run exactly the same calculations for validation, otherwise the consensus network is doomed.
Im assuming all games played against the incumbent; seeds are basically proof of wins. I guess you could still cheat though by copying the incumbent, get a 50-50 ratio of games, and then just find enough winners to make it 49-51.
https://github.com/emdoyle/chess_ai
That's my repo, if anyone wants to help me make it faster or possibly fix parts of it (hard to be sure the MCTS and NN are faithfully replicated) I would welcome pull requests!
Also I gitignored my tensorflow serving stuff but it's basically required to be able to serve the models and communicate via RPC to get predictions (the RPC client is visible in the repo).
At the moment, it seems like it's outputting moves, but it'd be lovely to have a nice graphical representation.
That's why I'm very worried about neural nets stuff : you can share any code you want, the secret sauce (the weights) will be easy to hide. GPL don't quite apply here.
It's probably true of hundreds of other applications, but somehow, I have the feeling it's different with AI 'cos the data "embody" the behavior much more.
You can license your trained network data GPL if you choose. Applies fine.
You are right that the valuable IP is in the data, but this is no different to Doom without the WADs, or MAME without ROMS.
Oh well...
As much as the hardware advances are important, maybe there will be better ways to train networks with limited hardware
(training even a small CNN with limited resolution inputs on a CPU is slow)
Seems just the CPU or even GPU aren't really suited for this kind of task
Generate the data to do that in the first place: 2000 TPU, each about 45 TFLOPS (or 2-4 x a GTX 1080 Ti).
Whenever I do a google search I use "baduk" instead. I think most people writing about go are smart enough to throw that word in there somewhere.
We're seeing the reversal of PC revolution and most people don't seem to notice or care.
Google achieved such high computational power from building custom chips. No one in the 90s could have afforded the custom ASICs that ran "Deep Blue", and certainly no one except Disney in the 90s could afford the giant cluster of computers used to compute "Toy Story".
The story of "PC Revolution" is always Big Company spends billions on custom ASICs -> hardware companies take notice -> NVidia releases "Volta" which emulates the TPU in 2018. (https://devblogs.nvidia.com/parallelforall/inside-volta/)
Soooo yeah. We're actually really, really close to consumer-level TPUs. Within a year or two. Google's secret sauce is being replicated by hardware companies now, and consumers will likely reap the rewards.
There's always a few years of delay between state-of-the-art custom machines and wide-spread adoption of consumer hardware.
-----------
Despite their success in these games, I'm personally not really sold on the broad applicability of Neural Networks. But hey, I'm willing to be proven wrong. There's a lot of experimentation being done and the "TPU" architecture is definitely very interesting (and the way "Tensors" map to simple linear-algebra problems is really what makes all of this possible).
I really wouldn't be too gloomy about Google's headstart. They did invent the TPU architecture after all, its only fair that they get to play with it for a few years before the mass market consumers can.
Some notes:
* OpenCL code is stored in strings: https://github.com/gcp/leela-zero/blob/master/src/OpenCL.cpp
* OpenCL Build Flags are: m_program.build("-cl-mad-enable -cl-fast-relaxed-math -cl-no-signed-zeros -cl-denorms-are-zero");
Which is telling: I've been struggling with -O2 on my AMD R9 290x, but it seems common knowledge that the AMD OpenCL optimizer is basically unusable. No -O2 to be found here. I guess that's how people have been dealing with that issue...
Of course if Alpha Go Zero had some proprietary secret sauces that they omitted from the paper and that are needed for things to converge or whatever, you are right.
[1] I mean if you look at the code, most of it is a fast Go engine, and code to compute a residual network stack on the GPU. These aren't things that the DeepMind paper has to spell out.