Hi It was pointed out to me that the latest version of Fuego, being 1.1 SVN r2029, would be much stronger than the 'official' one from 03-11-2011. Also, taking into account the fact that this almost five year old version is becoming very hard to compile, I decided to see what the latest version could do.

You can download it at this link:

http://asmoda.net/files/fuego_1_1_r2029_win32_win64.zip

(Setup instructions are the same as the ones in the other thread about the older version 1.1.)

Below is a first impression below. For a short technical explanation, see the spoiler at the bottom.

Compared to the 2011 version, I can say only one thing: wow. Just wow.

The 2011 version plays exceedingly strange as soon as its out of its opening book, especially when configured at lower power, such as one thread and 512MB of RAM. In that config it just seems to smack stones onto the board in some random fashion. I had this version (in its low power config) play against the web engine Cosumi, and it acutally lost by 2,5 point. GNU Go at level 3 can reliably defeat Cosumi with 20+ points. (On my computer at least.) When I played against Fuego in this config myself, I easily took a huge lead, and got so bored that I threw away a huge group of almost 20 stones... and *STILL* only lost by 4.5 point.

When configured at higher power levels (6 threads, 8GB of RAM), it gets better, but it doesn't come close to Pachi. Pachi 11.0 can defeat Fuego 1.1 easily, and Pachi plays much more logical. (I must say that I do have Pachi's pattern files set up; I did not yet test Pachi at low power without patterns.)

Now, the current version, Fuego 1.1 r2029 (downloaded from Sourceforge SVN), is a enormous step forward. This version has a huge 8MB+ executable (patterns built in?) and it plays MUCH more like Pachi does. Even at low power, 1 thread, 512MB, it plays very, very well, and to me (an SDK-player at this moment, after about a year of playing) it plays quite logical and not in the haphazard 'smack stones across the board' way as the 2011 version does. I can only imagine what a high-powered 6 thread, 8GB setup can do. When I played a game against it, I thought I was doing quite well; I also thought a group in the middle of the board was OK, until Fuego decided to attack it. I couldn't save it, and lost a 20 stone group. I didn't throw it away because of carelessness as I did against the 2011 version; Fuego attacked and killed it.

I think I'm going to set up both Fuego and Pachi, using three threads, ponder on, 4GB RAM, and run them against each other. With these settings, they can both run on the same computer, simultaneously. I don't know if 6 threads, ponder off would be better or worse than 3 threads, ponder on. (In a chess program, the second option is usually better.)

I think this version is a huge improvement over the 2011 version. The only gripe with it that I have is that scoring in Drago still doesn't work, and in GoGUI it becomes very hard to see which stone is played after the board gets full. I think I'm going to try and contact the author and see if he can fix this, or add Drago-compatible scoring. (I'll also try the other way around with Pachi, and report to the author that Pachi doesn't score correctly in GoGui.)

To answer this post

Here is my settings.cfg



The number of playouts is the uct_param_player max_games

Thanks for the info about the difference between the 2 versions, i will try with time limit only.

Thanks. Where have you found parameters such as "uct_param_player max_games" and "uct_param_player ignore_clock" ? I hadn't encountered this setting, but maybe I've missed it somewhere.

You have indeed set the number of playouts to a certain level, and because the clock is ignored, Fuego keeps going and going. Imagine how long a move would take on a 486 from the beginning of the 90's

I would indeed just set the maximum time you are comfortable with while waiting for a move, and let Fuego handle the playout itself. Setting playouts to a fixed number without time limit (similar to setting the move depth in a chess engine) is only useful if you want to make sure a program plays exactly at the same strength on computers of different speed.

(I like Drago best for this sort of thing, because you can set things like that while starting a game. In GoGui, you have to make different settings files or command lines for each setting.)

I found the parameters in this thread

For the playouts, it allows me to know the strength of the program using the facebook paper. For example, with 100k playout, Pachi is between 1d and 2d KGS.

But now that the new version of Leela is available with a level of about 3d, I found a new toy to play with (and it has a gtp version too)

I don't understand. Now Leela implements Deep Learning and a neural network as well. CrazyStone also implemented this within a very short time. Don't those people have to STUDY on how something works, or am I just exceedingly stupid?

I do see the OpenBLAS library, which Pachi also uses if you compile it with support for the Caffe neural net framework. Maybe the author of Leela is also using Caffe as an addition to his UCT/MCTS engine.

If so, then I don't like this, to be honest. I see the same thing happening as what happened in the chess world about 12 years ago. An exceedingly strong program became open source (Fruit, version 2.1), which defeated all engines at that time, even when running on less powerful hardware. Within no-time, every engine of note had either blatantly ripped most of Fruit's algorithms for themselves, or the 'new version of engine X' was now based on Fruit, with some code of the former engine mixed in.

In 2006, the same happened. Some Russians reverse-engineerd Rybka, and re-implemented some of its algorithms in the existing engine Ippolit. Again, in no-time, most engines capitalized on this, some even combining Fruit and Ippolit code within one engine.

I think that I'm not too far off the mark if I state that most, of not all of the strongest open source chess engines are descendants of either Fruit, Ippolit, or both.

It seems that, in the Go world, engines are now using Fuego-style opening books (Fuego, Pachi, Oakfoam), Pachi-type patterns (Pachi, Fuego has part of them built in, and possibly Leela... which now uses patterns as well), and are adding neural networks using Caffe. This will, eventually, make all open source engines grow closer and closer together. Also, 'new' engines will appear that are basically descendants of Fuego, Pachi, or both... and then we'll have the same situation as in the chess world. The engine with the best optimization in the evaluation function will be the strongest.

In the chess world, if you already have a Chessbase program such as Fritz (any version since the one that supports UCI, which was 7, on top of my head), there is no need to ever buy a new program. Stockfish is open source, free, and about 100 ELO ahead of any other engine except for Kommodo.

The first papers showing that DCNN are effective for Go date back to the end of 2014 (https://arxiv.org/pdf/1412.3409v2.pdf). There is a lot of documentation out there that explains how DCNN works and how it's implemented as it's the most hyped AI approach of the last few years.



You are jumping to conclusions. The following article explains the relevance of BLAS for Deep Learning:
https://petewarden.com/2015/04/20/why-g ... -learning/

OpenBLAS is the best free BLAS library. It's also one of the only ones that works well on Intel *and* AMD machines.



Leela was using patterns in 2008 already. There's a thread describing how it works on the computer-go mailinglist: https://www.mail-archive.com/computer-g ... 06250.html

Given that you seem to know about computer chess, you might find the following interesting:
https://www.mail-archive.com/computer-g ... 10532.html (The author of Leela explains the author of CrazyStone how nullmove works in Go)

There was also this, from the same author:
https://chessprogramming.wikispaces.com/Stoofvlees

So, this is much older than I thought. Then it makes sense that so many engines 'suddenly' implement it.



I must admit that I know very little about Go programming and related things such as pattern recognition; on the other hand, my knowledge about (classic) chess programming is quite extensive. While I do know about genetic algorithms, my knowledge of neural networks is sparse.

Thank you for making this available. I am on Mac OSX and have tried using your 32 bit build of r2029 under wine. Unfortunately it did not work - wine error (maybe a problem of compiling with recent optimization options, like for pachi ?).

So I have tried to compile the source natively under OSX, but since I am not used to svn, I was not able to get the complete source code of this version.

Anyway will be better to have a Mac OS 64-bit version...

The source is here: https://sourceforge.net/p/fuego/code/HEAD/tree/
svn checkout svn://svn.code.sf.net/p/fuego/code/trunk fuego-code
gives me an incomplete source (missing a lot of configure files etc.)
How can I get the full source code of this version ? Thanks

With regard to running Fuego in Wine: I haven't tested it. It's a bit of a weird construction; Fuego is a Linux program in a Windows executable. It runs because of the Cygwin compatibility layer... and now you're trying to make a 'fake' Windows program run on the Mac using another compatibility layer. Chances of this working are low indeed.

By the way, Fuego is not optimized. It boots and runs on my old Core2Duo/Quad CPU's. The one thing I wonder about is why r2029 is SO MUCH SLOWER than the old 1.1. The old 1.1 runs 16.000 simulations a second; r2029 runs only 600 simulations a second, and is still much stronger. I wonder if r2029 gets faster if I compile it with extra optimizations. I'll try that; though the old 1.1. wasn't optimized either.

With regard to the source code:
You did everything correctly. Fuego doesn't include any configuration and compilation scripts. To get those, you'll have to install Autotools. Then run 'autoreconf --install' (at least, in Cygwin and under Linux), and then you can compile. You must also have the Boost libraries available. The latest Fuego compiles against Boost 1.61 without problems.

I can be of no further assistance on the Mac, as I don't have a Mac available, but here is some information that may be of use to you:

http://fuego.sourceforge.net/mac-install.html

I have checked it on Mac OS X 10.11.5 using macports for compiling boost. Fuego also compiles like a charm. I then used GoGui and started a game, everything fine. But I'm too lazy now to take a look at all the options.

If you have a working 32-bit and 64-bit version of Fuego for MacOSX, could you post it somewhere so I can download it? I'd like to add it to the archive above.

I've been trying to compile Fuego with MSYS2/MinGW. While MSYS2/MinGW is not officially supported for Boost, version 1.61 compiles perfectly. After passing the directory to ./configure, the configure scripts are also created without errors, but then, when compiling the actual Fuego program, it runs for a while and then starts spitting errors about the fork and pipe functions. Even though Fuego uses Boost's Thread library, it *still* uses the fork() function among others, which is not available on a program in a Windows-native compiler. There is a very old page available on compiling Fuego with MinGW, but that is for the 2011 version; the fork() function probably wasn't included in that version yet.

edit: While Fuego doesn't compile due to the above errors, I have been able to get Oakfoam 0.20 to compile. It is very similar to Fuego; it uses Boost, it uses Fuego-style opening books and configuration file and it has similar commands. Oakfoam is either a fork of a version of Fuego, or heavily inspired by it.

I have been able to create a 64-bit version. If I have some time this weekend, I'll see if I can create a highly optimized version and core2duo version for 64-bit and 32-bit, and a generic version for really old CPU's, in 32-bit, like I did with Pachi.

PS: Currently, there is no precompiled (Windows) version of Oakfoam 0.20. I'll test it, try some setup stuff and after I create the versions above, I'll add it to the webspace.

I also have to get that website up somewhere soon, so I can put all those versions online and write some 'how to compile' instructions. The one thing I'm possibly NOT going to try, is to create an optimized/older/generic version of the old Fuego. It took too much time to get the old Fuego and Boost 1.49 to compile under recent versions of Cygwin. It wasn't really difficult, just time-consuming.

32-bit didn't link (boost?!), but I guess you only need 64bit for MacOS . Here you go: http://www50.zippyshare.com/v/dkejhrSq/file.html

Thanks. I'll put it up in its own archive. When adding it to the website later, I'll have to add that this is a contributed version, and that I cannot test it personally. If you have instructions on how to use it/where to put it on the Mac, that would be helpful. Has everything been linked statically in to the executable? I don't see any libraries. What is the "fuego_test" file?

Maybe this is extremely obvious, but did you recompile Boost as 32-bit, and then compile Fuego? You might actually need to first compile Boost as 32-bit, then compile Fuego, and then remove the Boost 32-bit versions of the library and redo for 64-bit (or the other way around, of course).

(Are there still Macs that run only 32-bit? There still is a 32-bit version of Windows 10... god knows why. Everybody who bought a computer since 2006 would have a 32-bit CPU, and to be honest, if I were MS, I'd just have ditched every CPU older than the Core2Duo.)

Frankly speaking, I don't have that much time for it. The 64bit version should be fine. But it's dynamically linked. I just tried to build a statically linked version but the autoconf/automake magic failed.

If it's dynamically linked, it won't run on Macs on which the Boost libraries are not installed, unless you provide them along with the program. I have done that with my versions. The problem on my part is that I can't create or test any Mac versions myself.

I know. That's why I mentioned it. But various flags produced errors. I tried:

./configure LDFLAGS="-static"
or
./configure --enable-static
or
make SHARED=0 CC='gcc -static' CXX='g++ -static'

etc

This is correct; I also can't statically link the C++ runtime libraries on Windows.

Fuego r2029 seemingly has some bugs. It plays 'nicer' Go than version 1.1, due to its new patterns, but I don't know yet if it's really stronger than the old version, because it's so slow. Versio 1.1. runs at a speed of about 16.000 playouts per second on my machine, while the new version that I've compiled runs at 600 games/seconds. That's almost 27 times slower. I've been able to recompile and optimize it to run at 800 games/second, but stil...

I've tried compiling with -O2, -O3, compiled against Boost 1.61, 1.51, and several versions in between, also tried compiling Boost with different optimizations (and obviously, everything as 'release'), but r2029 stays extremely slow compared to the older 1.1.

For the old 1.1 version I didn't do anything special with regard to optimizations. I just compiled Boost 1.49 and Fuego 1.1 with -03 and all options enabled for SSE3 CPU's.

That version has it's own problems though. Because Boost 1.49 is the last version to provide the Filesystem v2 library, and the first version that compiles under GCC 4.6 and newer, it's (almost) impossible to get Fuego 1.1 to compile with anything else but Boost 1.49 under a new compiler, and that *still* requires hacking both Boost's build scripts and Fuego's code.

[deleted]

I compiled a fresh win64 version you can find here:

http://dracsoft.com/zips/fuego-svn-2034.zip


Build instructions.