Pachi 11.x for Windows, 32/64-bit (14 june 2016)

[avysk]

Do you have your own version of Cygwin installed and included in your path? If you are just starting Pachi, without the DLL's in the folder, it'll start searching for them in your path. If you have a different version of Cygwin installed than I have, it will crash. It is indeed complaining about an incompatible version of Cygwin. This probably has something to do with the configuration of your Windows environment and/or DLL/version mixups.

No, of course not. And I added DLL included in your archive to the folder, of course. And I've searched for this DLL in my system, just in case, and didn't find it, of course.

Note: Pachi has been downloaded 31 times as of today, and I have received no problem reports as of yet. Fuego, especially version r2029, of which no official binary exists (let alone a 64-bit version) outside of mine, is just as popular though.

Still crashes for me. Could that be explained by low-end laptop and CPU used in it (Celeron N2840)? See:

(gdb) run
Starting program: /c/Users/alexey/Applications/pachi_11_0_win32_win64/64-bit/pachi.exe
[New Thread 1444.0x24a8]
[New Thread 1444.0x25bc]
[New Thread 1444.0xd94]
[New Thread 1444.0x2580]

Program received signal SIGILL, Illegal instruction.
0x0000000100421eb5 in time_parse ()

edit: when compiling Pachi using GCC under MinGW64/MSYS2, I get the same errors as when using the older MinGW64/MSYS from MinGW.org:

Let's do sanity check:

1. git commit I'm compiling is 31612b51d2be48358c0b8eac21f2e6cb546d5683
2.

$ cc --version
cc.exe (Rev5, Built by MSYS2 project) 5.3.0

While I did install "clang" package, I don't think it compiles with it by default;

$ clang --version
clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:\msys64\mingw64\bin

3. What did you change in Makefile? My only changes are uncommented "WIN=1" and added "WIN_HAVE_NO_REGEX_SUPPORT=1" right under that; then I just run 'make' and it works.
4. You do run msys2 by "mingw64" shortcut, not just run shell?
5. Last but not least: Windows 10 Home.

make[1]: Entering directory '/c/users/marcel/desktop/pachi-master/random'
[CC] random.c
<command-line>:0:8: error: expected identifier or '(' before numeric constant

Hmm. See:

alexey@DUVEL MINGW64 /c/Users/alexey/Source/Repos/pachi/random
$ make clean && LANG=C V=1 make
rm -f *.o *.a
cc -I.. -c random.c
ar r random.a random.o
C:\msys64\mingw64\bin\ar.exe: creating random.a

alexey@DUVEL MINGW64 /c/Users/alexey/Source/Repos/pachi/random
$ cc --version
cc.exe (Rev5, Built by MSYS2 project) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Notice that it's not compiled with clang.

[avysk]

Note: Pachi has been downloaded 31 times as of today, and I have received no problem reports as of yet. Fuego, especially version r2029, of which no official binary exists (let alone a 64-bit version) outside of mine, is just as popular though.

Your fuego 64-bit build works for me, no crashes.

[avysk]

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

[avysk]

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

Looks like "DOUBLE" is an unfortunate naming choice; it clashes with some internal headers. Replacing it in Makefile and in the code with something else (say "DBLE") allows compilation to proceed. I'll report on the results, as it's still compiling.

[avysk]

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

Looks like "DOUBLE" is an unfortunate naming choice; it clashes with some internal headers. Replacing it in Makefile and in the code with something else (say "DBLE") allows compilation to proceed. I'll report on the results, as it's still compiling.

Compiles as a charm, works, does NOT solve my problem with playing instantly with large tree_size...

[avysk]

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

[Babelardus]

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.

[Babelardus]

Still crashes for me. Could that be explained by low-end laptop and CPU used in it (Celeron N2840)? See:

(gdb) run
Starting program: /c/Users/alexey/Applications/pachi_11_0_win32_win64/64-bit/pachi.exe
[New Thread 1444.0x24a8]
[New Thread 1444.0x25bc]
[New Thread 1444.0xd94]
[New Thread 1444.0x2580]

Program received signal SIGILL, Illegal instruction.
0x0000000100421eb5 in time_parse ()

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).

Note: Pachi has been downloaded 31 times as of today, and I have received no problem reports as of yet. Fuego, especially version r2029, of which no official binary exists (let alone a 64-bit version) outside of mine, is just as popular though.

Your fuego 64-bit build works for me, no crashes.

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.

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

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

Aha, uncommenting "DOUBLE=1" in Makefile (which I didn't) breaks random.c compilation for me; it works otherwise. And it can be explanation why my version does not handle tree size as big as 4Gb; need to check the code.

Looks like "DOUBLE" is an unfortunate naming choice; it clashes with some internal headers. Replacing it in Makefile and in the code with something else (say "DBLE") allows compilation to proceed. I'll report on the results, as it's still compiling.

Compiles as a charm, works, does NOT solve my problem with playing instantly with large tree_size...

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.

[avysk]

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).

[Babelardus]

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:

cpu.png (26.88 KiB) Viewed 12676 times

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

[Garf]

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.
...
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.

[avysk]

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

My CPU

cpuz.png (30.78 KiB) Viewed 12643 times

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.

[avysk]

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.

[Babelardus]

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.

[Babelardus]

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.
...
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.

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.