The last one of the Big Three open source Go programs, at least in my mind I often see Fuego compared to Pachi on the internet, and as there wasn't a 64-bit version for Windows that could use more than 2GB of RAM (this is the limit of the 'offical' 32-bit build on Sourceforge), I decided to try and make one.

While I succeeded, I can't say it was a fun experience

If you want to read about that, you can open the spoiler at the bottom.

You can download the program here:

http://www.asmoda.net/files/fuego_1_1_win32_win64.zip

Install it into GoGui in the usual way.

I don't recommend Drago because of a scoring problem. Though Fuego will play the game fine, it handles scoring differently than Pachi or GNU Go. It doesn't score the the game when finished, and Drago gives you no option to do so, as it closes down the engine when done. GoGui keeps the engine loaded and has a "Score" option that is compatible with Fuego.

At the end of the command line in GoGui, add this:

--config settings.cfg

This file, found in Fuego's folder, contains the following settings:

uct_param_search number_threads 1
uct_max_memory 536870912
uct_param_player ponder 0
uct_param_search lock_free 1
uct_param_player reuse_subtree 1

Set "number_threads" to the number of threads you want Fuego to use. My 4-core i7 with HyperThreading likes 6 threads, for a load of 90%.

Set "max_memory" to the number of bytes you want Fuego to use. Calcuate as follows:

1048576 * Megabytes

Set "ponder" to 1 if you want Fuego to think during your turn, and 0 if you don't want that.

You can leave the last two settings alone. "lock_free" only needs to be disabled for very old computers, and "reuse_subtree" is good to have enabled according to the documentation.

Opening books: The Fuego folder contains the smallest opening book. If you want a bigger one, delete "book.dat" from the folder where fuego.exe is located. Copy the desired book from "\books" to the Fuego folder, and rename it "book.dat".

Have fun with the 64-bit version that can use >= 4GB of RAM. AFAIK, there hasn't been one before

"It's readily apparent that Fuego's code hasn't been updated for about 5 years"

Fuego's code is always updating, and the recent version is "Commit r2029", which is updated several days ago.

"this is not the most beautiful build of a program ever created"

You can try to use Mingw to make a more beautiful build of Fuego!

On the Sourceforge website, the version from 13-3-2011 is still the latest:

https://sourceforge.net/projects/fuego/files/fuego/1.1/

Is there a newer version somewhere? If so, I'll have a look into it.

edit: found it. It's here:

https://sourceforge.net/p/fuego/code/HEAD/tree/

I might try this, but I assume the tarball is still the offical version. I could download the code from the repository and see if it works. (It's the same with Pachi: the code in the repository is newer than the official current and stable tarball.)

edit2: I've been looking through the commits over here. It looks like 2, and recently 1 person are renaming classes, removing support for older compilers, and moving code around to different files. In essence, they are refactoring (very slowly). The interesting commits were 1984, "Removing Boost Filesystem v2", 1989, "Bump up minimum Boost version to 1.50", and 1991, "Fix warnings with CLANG and Boost 1.58."

It looks like these two people have been spending the last 3 years to make Fuego build with more recent versions of compilers and Boost. It might be worth a shot to see if that code works, but to be honest, I view it as alpha, maybe bèta code until the tarball is updated.



Fuego requires Boost 1.49 or older, because it needs FileSystem v2. I don't know if I can still build such an old Boost version with the most current MinGW. Even under current versions of Cygwin, which pretends to be Linux, Boost requires several hacks in its build scripts to get it to compile and build.

I was actually lucky to get it to build at all, even in Cygwin. The Boost documentation says that version 1.48 is the last one to include Filesystem v2, but version 1.49 is the first one that will compile with GCC versions above 4.6. (Boost 1.48 and lower can't compile the threading library anymore due to changes in the compiler.)

Fortunately, the documentation was wrong and 1.49 actually includes Filesystem v2, or I would have needed to mix Boost 1.48 and 1.49 libraries in one program, something which is not recommended.

With regard to recent versions of MinGW: I've had a lot of problems building Pachi with MinGW (even when following your instructions), while it readily compiled and built on Cygwin. Under MinGW, the build script was missing parts of the toolchain: cc not found, ld not found, and if pointed to the MinGW versions, it would generate loads of errors.

Now that I have a working 64-bit version of Pachi, Fuego and GnuGo, and know how to build them on Cygwin, I might have a look into MinGW again, to see if I can build a Windows-native version of each that doesn't require the Cygwin compatibility layer. It might gain a few percent of speed.

Babelardus, you are doing awesome work! Much appreciated!

Hi, Thanks for the files.

According to this thread, the current svn is much stronger.

In your link, there is a window file from 2013 with version number 1.1.4

Very cool! What kind of impact can I expect from increasing the RAM usage? I've got 16GB on my lappy and 64GB on the home workstation.

Thanks It's my way of giving small bits and pieces back tot the open source software world. While I would love to write a big program or even my very own Chess or Go engine from scratch, I don't have the time (and in case of Go, don't have the knowledge). Therefore I do small things, such as creating builds of programs, translating some files, and/or reporting bugs.



I have checked this out, and compiled the latest version of Fuego from source. It is indeed MUCH stronger.



I cannot say. I haven't tested this yet. The extra memory probably acts like a transposition table, in which the program stores all positions it has already analyzed, together with the results. Then it doesn't have to reanalyze them again when it encounters them in subsequent searches, because it knows the results already. That gives a very large speed boost, which helps the program look further ahead in the same thinking time, and thus it becomes stronger.

How much stronger? You would need to test two versions of Fuego against one another, one with 2048MB RAM (limit for a 32-bit program), and the other with 12 or 16GB of RAM and see if the one with the most RAM wins consistently. If so, you'll need to add handicap stones for the program with 2048MB, and then you can see how many stones of strength the extra RAM provides.

edit, update: The description in the first post said that this version was large address aware. While this is true (the flag is set), it doesn't work. At least not for the Fuego/Cygwin combination. As soon as the program actually tries to claim more than 2GB RAM, the engine will crash. Don't set the memory setting higer than 2147483648. It's better even to keep it at or below 1879048192 to leave some headroom (256MB) for Fuego itself, beside its search tree. If you want more than 2GB, use the 64-bit version.

links don't work
does anyone have a 64-bit version?