GnuGo is one of the strongest Go programs around, perhaps even the strongest (soon).I am not sure why what I did has caused a problem ... it seemed so very natural to me. ;^)
There is a big problem with that, and that problem appeared with SlugGo.
The problem with the strongest Go program being Open Source is that winning a Computer Go contest simply becomes a matter of who is the richest person, not who has the best program.A few years ago a top line PC might cost up to $10,000. I know that I spent over $8,000 on one of my PCs when I was in college and I did not go full top-end. The 24 Mac Minis that went into the cluster I took to the Cotsen Open cost $14,000. You can add another $3500 for the dual G5 tower and then there is the networking and UPS stuff ... not really expensive items. That is far short of requiring extreme wealth. I believe that if I had held it back to only 16 processors the difference in playing strength would not have been noticeable. Even though we have run experiments using up to 72 cpus (and one where we doubled up the processes so that it could be considered the equivalent of 144 if you ignore the wall clock hit), we cannot see any increase in playing strength over what we can get with something like 16 to 32 cpus with the present SlugGo algorithms. It will take more research to find useful algorithms to use the extra power. If anything, SlugGo shows that it is the algorithms more than the number of computers that really matter. It took the application of much money and time to show it, but that is what I see.
Not trying to split semantical hairs, but it is hard to rip off something that is created for the purpose of free distribution.If I rip of GnuGo's engine
and buy a Tyan quad Opteron blade and put dual-core CPU's in it and modify GnuGo so that it uses multithreading well, I have a "winning" 8-CPU cluster that can be conveniently carried on handles by two people, it's not even heavy. I will most probably win the contest without doing much real programming.Reprogramming any large single threaded program, such as GNU Go, to be multithreaded to run well on multiple cpus requires more than just real programming. It requires expert real programming and lots of it. It took us 2 years to get our wrapper around GNU Go to this stage. Others have suggested that we take on the task of rewriting only just the core of GNU Go move generation to run more efficiently on the parallel cluster. I don't see a clean way of taking on a partial rewrite of GNU Go, and I am very afraid of how long it would take to do it right.
Not that I propose we force people to use standardized hardware, but it sure is a dilemma.Computer Go is young, and networked clusters are getting faster and cheaper all the time. The big breakthrough in chess strength relative to humans came when amazingly large amounts of hardware (for the time) were applied to the problem. After that it became more of an evolutionary software problem. I think it natural for Go to follow a similar path. The present hardware configuration of SlugGo will soon be obsolete, particularly that of our traveling cluster, and others will develop the desire to try cluster computing. I doubt that the fact that I tried it first is the sign that computer Go is now and forever more the domain only of those with the biggest wallet or the biggest machine. I do not know if it is even true today. SlugGo has not played enough other programs to know.
The danger is that some guy with a lot of cash will forever win all competitions because a clever team (the GnuGo team) delivers the strongest program, and the only ingredient neccessary to remove all excitement about who will win the tournament is *money* for the fastest PC.