Oh-oh, max_tree_size in the code is unsigned long, which is 4 bytes in Windows: https://msdn.microsoft.com/en-us/library/s3f49ktz.aspx. So my setting of 4096 effectively turns into 0. I'll patch the code to unsigned long long, and will report the results

This is for Visual C++. It could be that CLANG and GCC, when creating native Windows code, keep themselves to the Visual C++ standards. In that case, you're right; long is only 4 bytes, 32-bit, and thus you'll have problems with tree sizes over 4GB.

It's weird that I can't get Pachi to compile with GCC. It creates loads and loads of errors. I don't even have to try with Fuego, because it needs Boost; and the Boost documentation clearly states that MinGW is not officially supported.

Woow... wait. Illegal instruction? I've enabled all optimizations, so the compiler throws in everything it's got, including SSE2, 3, 4.x and so on. If you have a really low-end (or really old) CPU, the compiler may be using instructions your CPU doesn't have, and then it will crash.

Damn. I didn't even think about that. To correct this issue, I would have to go back and recompile everything, adding a version that doesn't use anything newer than SSE2 (and find out how that works, exactly).



Strange. I enabled all optimizations there as well. However, Fuego uses g++ instead of cc as it's a C++ program. Maybe, by chance, the Fuego/g++ combination doesn't yield any illegal instructions for your CPU.



Ah. I uncommented that, because it specifically says that very large playouts can cause problems if this is left commented.



Then that at least explains the problem why it doesn't compile with a native Windows-compiler. The headers are different than the Linux compilers running under Cygwin.

===============

While I would like a native Windows version, because it's a bit faster in theory (no compatibility layer necessary), I don't want to have to change the code each time I'd go and compile a new version... I did it with the Boost 1.49 build scripts and Fuego 1.1, to them to compile under the most recent version of GCC, but it was too much work to keep repeating.

Fortunately, Fuego 1.1_r2029 compiles cleanly after one tiny addition to the Makefile.

Or, you'd need to clone the repo, change the code by including if-defs, and then update your repo each time a change is commited... or get the changes merged into trunk.

However, I did report some issues with both Fuego and Pachi under Drago and GoGui respectively, and reported them to Drago's author as well, and never received a reply as of yet.

native mingw does the same thing as Visual C++: unsigned long is 4 bytes even in 64-bit version (and that is perfectly standards-compliant...) I'll [eventually] do the patch for pachi and will submit it upstream; I think the proper type for max_tree_size is size_t but it opens some kind of Pandora box. I'll also do the patch for unfortunate DOUBLE naming.

Re fuego: while there's (seemingly functional) boost for msys2, compiling Windows-native version involves:

- trickery with autotools, including libtoolize and editing of configure.ac
- trickery with generated configure to bypass one known boost bug

And it still does not help, because Fuego uses POSIX API unavailable on Windows (fork & friends).

Avysk, could you post a screenshot of CPU-Z, found at http://www.cpuid.com/softwares/cpu-z.html ?

Maybe I can see something there that would explain why my version of Pachi doesn't run on your CPU. It's not a powerful model, but it's a fairly new one, that supports stuff like SSE4.

I can compile a standard i686 version, or one optimized specifically for older CPU's such as Core2 or Pentium4, but it will lose speed compared to one that is optimized for the newest generations.

This is the CPU in my computer at work:



It is older than your CPU, but it starts 'my' Pachi 32-bit and 64-bit just fine.

He has a Bay Trail Celeron, which doesn't support AVX and AVX2. Your Haswell does.

Sure, my low-end Celeron doesn't support all the instructions your CPU does.



Well, if nobody else complains, you don't need to recompile the whole thing -- my own Windows-native version works fine for me (except max_tree_size cannot be bigger than 4095, but that I'll fix in the code).

But if you put your version somewhere in a public place, it's worth making a note that it may not run on every CPU.

Pull request with DOUBLE fix for pachi: https://github.com/pasky/pachi/pull/41

Checks are failing due to misconfigured Travis CI job, it seems.

I wonder if the author reacts to that. I've sent him an e-mail that Pachi couldn't compile under MinGW (but i didn't know yet why), and also told him that the regex library needed to be removed from the makefile. I also sent him my version of Pachi for Windows, but I haven't had a reply as of yet.

It also doesn't support a lot of other things I see. I'll create a version fit for Core2 Duo. Those have been introduced 10 years ago. I hope there aren't too many Pentium 4's around anymore

That screenshot is from my computer at work. The lowest end CPU I have in use now is a Skylake in my notebook, on which Pachi was compiled. It seems GCC uses some features from that CPU that are not generally available.

edit: I see. Pachi has "-march=native" set in the Makefile. I added all compilations myself using a batch script, but 'native' already uses every feature the compiler supports. I'll tone it down to 'core2' to tone it down and allow it to run on older CPU's. I'll add the new EXE to the archives after they're verified to work on my old Core2Duo laptop and Core2Quad desktop.

The zip-archive in the first post has been updated.

Pachi was compiled on a very new CPU, with all optimization options enabled. Therefore it would not run on older CPU's, or lower-end CPU's with less features. Starting this version on such a CPU would crash the engine.

There are now three versions of Pachi included:

pachi_modern_cpu.exe (For the newest cpu's. Might not run on yours.)
pachi_older_cpu.exe (Optimized for Core2Duo, which is now 10 years old.)
pachi_generic_cpu (i686, 32-bit only; this should run on basically everything since the Pentium2 or so.)

If the version of Pachi in the previous archive runs fine on your computer, and you don't intend to use it on an older/lower end computer, there is no need to redownload the engine.

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

whats the difference between the 3 opening books fuego/pro 6dan/pro only???

Size of the opening encyclopedia.

The Fuego book is the one that originally came with Fuego.
The Pro Only book contains openings played in professional games.
The Pro6dan book contains the same openings as Pro Only, plus openings played by KGS players, where both players where 6 dan or higher.

You have to choose one of the books, and put it in Fuego's main folder. Delete 'book.dat' if there is one there already, and then rename the book you chose to 'book.dat'.

i won't use them in fuego. i love pachi thanks for the explanation

They also work in Oakfoam. I'm compiling the different versions of that engine now

Maybe I'll also create opening books using some of the freely available databases. Something like: "Openings before 1900", "Openings between 1925 and 1950", "Openings by <famous player>", or something like that

Pachi's repository has just been updated. The version number is now 11.99; maybe we're very close to a version 12 now You can download the latest Windows versions here:

Pachi 11.0 Retsugen, official release: http://asmoda.net/files/pachi_11_0_win32_win64.zip
Pachi 11.99 (bèta), 14-06-2016: http://asmoda.net/files/pachi_11_99_201 ... _win64.zip

All instructions in the first post still apply.

Note: I have compiled all versions for SSE3 CPU's. They should run on anything since the Pentium 4 Prescott from 2004. I've tested several versions, and creating versions specifically optimized for newer CPU's is of no use, at least not for Pachi. The engine doesn't get any faster. Even 64-bit does not make a speed difference in that regard. 64-bit DOES break the 2GB memory barrier limit of the 32-bit version though, which does make the engine stronger and able to use larger patterns and opening books.

PS: This is still a Cygwin version. Though I got this version to compile without errors under MSYS2/MinGW (which could make the engine faster, due to removal of the Cygwin layer), that version just froze up as soon as it was its turn to move.

I have a problem:

i use sabaki and pachi. pachi stops playing moves after about 40-45 moves.

i have an Intel Xeon E3-1230v3 and 32GB Ram. Any ideas? i reduced threads for pachi to 1 and tree size down to 400.
i tried the newest 11.99 but still same issue.

besides that i love the "natural" playing style of pachi. is there any info how one can set pachi on a specific rank of strength?

I have not tried Sabaki yet. Pachi outputs a lot of information besides its moves. Maybe Sabaki doesn't handle that correctly yet, in some way.

Pachi works fine in Drago; at least the 11.0 version does. I'll have to test the 11.99 version more to see if it works until the end of the game.

I'll play some full games in Drago again, using both Pachi 11.0 and 11.99 as soon as I can, and see if it completes them.

Pachi does have some problems; the 32-bit Windows version that is on the official site is crash prone, and when compiled using MinGW as a native Windows program, it always hangs on the first move. I have tried several Pachi versions/revisions, and several MinGW versions. Maybe I'll try a different compiler to see what happens there.

As of yet though, I have had no problems with the Cygwin version, apart from the fact that Pachi is not 100% compatible with GoGui's scoring commands, as noted earlier. You'll have to click the "Score" menu, and then indicate dead groups, with 11.0; I have not yet fully tested 11.99.



I don't know of any, except limiting time to the absolute minimum, and/or taking handicap stones.

Did you try just from the command line? There's some problem with end-of-line characters when pachi is compiled Windows-native and run without "-d 0" option. What I saw is that it outputs the board and right next to it (not on the next line) the move; and GUIs are not able to grok it.

Reducing memory or threads does nothing to resolve this issue. I just played a blitz game against Pachi 11.0 from this thread. Settings where 6 threads, 16 GB of RAM, largest opening book, and patterns. That constitutes Pachi at nearly full strength on this system. (I could give it 7 threads and 24GB of RAM if I wanted to.)

I set Pachi to play at 5 seconds per move, and didn't take much more time myself. My cunning plan was to take all four of the corners, extend as much as possible along the sides taking territory there as well, and then try to wreck the middle. It didn't work as planned: I didn't get the lower left corner, and lost by 18.5 points :p For completeness sake, I'll post the game here.

If Sabaki isn't able to finish a game, there is some incompatibility between it and Pachi, just like there is between GoGui and Pachi with regard to scoring.