DiscoCheck 4.0.0 (release candidate)

[PK]

I have figured out a way to crash DiscoCheck in a console mode:
write "go" as the first command or first "uci" and then "go". "uci" -> "position startpos" -> "go" doesn't crash, so it's a matter of uninitislized position. certainly not performance-critical , but IMHO it's better either to initialize position at startup or output a message insulting the user than to crash.

[zullil]

I have figured out a way to crash DiscoCheck in a console mode:
write "go" as the first command or first "uci" and then "go". "uci" -> "position startpos" -> "go" doesn't crash, so it's a matter of uninitislized position. certainly not performance-critical , but IMHO it's better either to initialize position at startup or output a message insulting the user than to crash.

Believe it or not, this has be discovered before. See

http://talkchess.com/forum/viewtopic.ph ... 26&t=42277

[lucasart]

Just like to say this is more a discussion to establish and fix bugs, especially related to portability. So testers, please don't spend your CPU time on DiscoCheck yet

Jim's compile is functionally correct: it has the right node count. But I find it a bit slow (although I don't know what computer he's using). He gave me some detailled advice in the programming forum, and I'll try to do some cross compiling, and see if I can get fast executables for Windows.

Thanks Lucas.
Please let us know when we can start testing the new version with confidence.

Actually you can start with Jim's compiles. I've tested all of these, and they are both functionally correct (node count check) and run at the expected speed:

Linux

Code: Select all

./32:
discocheck-400-32-ja

./64:
discocheck-64-ja
discocheck-64-popcnt-amd-ja
discocheck-64-popcnt-intel-ja

32-bit version seems to have a bug when displaying the resulting time of the bench command. But that is a cosmetic detail that will not affect game play. The error is most likely in my code. Anyway, it's functionally correct and also fast.

64-bit versions are all good. Use the popcount (AMD or Intel depending on your CPU) if it works, otherwise the normal one (only recent CPUs have the "popcount" instruction).

Windows
OK I installed Wine 32 and 64-bits, so I could test them on my Linux machine. I didn't properly test them in a GUI, just ran the "discocheck bench 12" command.

Code: Select all

./32:
discocheck-32-ja.exe

./64:
discocheck-64-amd-popcnt-ja.exe
discocheck-64-intel-ja.exe
discocheck-64-ja.exe

I didn't notice much speed difference between the various 64-bit compiles. Might be because of the additional Wine loading time. Jim can confirm, but I reckon you should use the amd or intel one (depending on your CPU), and if it fails the default one (meaning your CPU doesn't have popcount instruction).

I have yet to try the Android one on my phone

[lucasart]

I have figured out a way to crash DiscoCheck in a console mode:
write "go" as the first command or first "uci" and then "go". "uci" -> "position startpos" -> "go" doesn't crash, so it's a matter of uninitislized position.

It's not a bug: it's a feature

Actually, I'm not kidding. You should not assume that an UCI engine initializes its "state" to the start position. Such a behaviour, although common, is not specified by the UCI protocol as written by Stefan MK. In fact the very notion of "state" is in contradiction with the philosophy of the UCI protocol, unlike the Xboard protocol (which relies completely on state, one of the many reasons why I hate this protocol).

IMHO it's better either to initialize position at startup or output a message insulting the user than to crash.

I like the idea of insulting the user. In fact, I can just gratuitously insult the user anyway, when DiscoCheck starts. How about that:

Code: Select all

< uci
uci
> id name DiscoCheck 4.0.1
> id author Lucas Braesch
> option name Hash type spin default 32 min 1 max 8192
> option name Clear Hash type button
> id info I hate you, stupid user. I hope you lose all your pieces and cry like a baby
> id info And if you're reading this, you must be a command line geek, as most GUIs don't relegate such messages
> id name Yeah, yeah, try to sue me: the GPL has a legal provisions against it (exclusion of liability)
> uciok

PS: I hope I'm not offending anyone. Please take this with a pinch of salt.

[lucasart]

Here's another *feature* of DiscoCheck. If you try to allocate more memory than you have, std::bad_alloc is thrown and caught nowhere, and the program crashes horribly, insulting the user in the process

Code: Select all

setoption name Hash value 8192
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

[geots]

Just like to say this is more a discussion to establish and fix bugs, especially related to portability. So testers, please don't spend your CPU time on DiscoCheck yet

Jim's compile is functionally correct: it has the right node count. But I find it a bit slow (although I don't know what computer he's using). He gave me some detailled advice in the programming forum, and I'll try to do some cross compiling, and see if I can get fast executables for Windows.

Thanks Lucas.
Please let us know when we can start testing the new version with confidence.

Actually you can start with Jim's compiles. I've tested all of these, and they are both functionally correct (node count check) and run at the expected speed:

Linux

Code: Select all

./32:
discocheck-400-32-ja

./64:
discocheck-64-ja
discocheck-64-popcnt-amd-ja
discocheck-64-popcnt-intel-ja

32-bit version seems to have a bug when displaying the resulting time of the bench command. But that is a cosmetic detail that will not affect game play. The error is most likely in my code. Anyway, it's functionally correct and also fast.

64-bit versions are all good. Use the popcount (AMD or Intel depending on your CPU) if it works, otherwise the normal one (only recent CPUs have the "popcount" instruction).

Windows
OK I installed Wine 32 and 64-bits, so I could test them on my Linux machine. I didn't properly test them in a GUI, just ran the "discocheck bench 12" command.

Code: Select all

./32:
discocheck-32-ja.exe

./64:
discocheck-64-amd-popcnt-ja.exe
discocheck-64-intel-ja.exe
discocheck-64-ja.exe

I didn't notice much speed difference between the various 64-bit compiles. Might be because of the additional Wine loading time. Jim can confirm, but I reckon you should use the amd or intel one (depending on your CPU), and if it fails the default one (meaning your CPU doesn't have popcount instruction).

I have yet to try the Android one on my phone

Before anyone notices it and worries, Jim forgot to add the word "popcount" to the intel 64-bit exe. BUT no need for him to worry with adding it, because if it says "intel" in the exe name description- you can be sure popcount is there.



Best,

george

[lucasart]

This is odd, I don't have the same node counts here. Can you run this command, and see what node count comes out ?

Code: Select all

./discocheck bench 12

Thank you

Hi Lucas,

Code: Select all

signature = 7429915
time = 10.6312
0
0

Thanks for the test, and sorry for the late feedback on this. This confirms that your compile is incorrect. I have no idea what is wrong with the GCC you got from Apple, but all I know is that they try hard to force people to use Clang/LLVM, so I wouldn't be surprised if it's buggy.

But in theory Clang claims to be GCC compatible. And my code doesn't have any non ISO C++ compliant features, other than the few built-in GCC intrinsics (the ones from Jim Abvlett, for lsb() and msb()). So it would be interesting to see if clang can compile it on your Mac.

I've tried to install Clang/LLVM on my Linux machine, but that stupid compiler can't even compile its own C++11 standard library

Code: Select all

In file included from ./src/movegen.cc:15:
/usr/include/c++/4.6/chrono:666:7: error: static_assert expression is not an integral constant expression
      static_assert(system_clock::duration::min()
      ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don't know what's wrong with the Ubuntu Clang package. Perhaps with new versions C++11 support will come, but in the meantime I'll stick with GCC, and I'll try Clang when it's ready for C++11.

PS: Clang+LLVM is the future, and will eventually take over from the dinosaur that is GCC. But it's not ready yet, although moving forward quite fast. Already FreeBSD uses Clang as the default compiler for the kernel since Nov 2012. And there is an ongoing project to make Clang capable of compiling the Linux Kernel (probably work is both on Linux side removing GCC hacks, and on Clang side implementing subtile functionalities correctly). It will take a long time, but maybe one day you'll have a full Linux distro compiled with Clang

[zullil]

This is odd, I don't have the same node counts here. Can you run this command, and see what node count comes out ?

Code: Select all

./discocheck bench 12

Thank you

Hi Lucas,

Code: Select all

signature = 7429915
time = 10.6312
0
0

Thanks for the test, and sorry for the late feedback on this. This confirms that your compile is incorrect. I have no idea what is wrong with the GCC you got from Apple, but all I know is that they try hard to force people to use Clang/LLVM, so I wouldn't be surprised if it's buggy.

I compiled again with the same gcc version 4.7.2 (MacPorts gcc47 4.7.2_2). It is the inclusion of the flto flag that causes the problem.
If I remove that flag, then my binary gives

Code: Select all

signature = 7217665
time = 11.2843
0
0

[lucasart]

I've tried to install Clang/LLVM on my Linux machine, but that stupid compiler can't even compile its own C++11 standard library

Code: Select all

In file included from ./src/movegen.cc:15:
/usr/include/c++/4.6/chrono:666:7: error: static_assert expression is not an integral constant expression
      static_assert(system_clock::duration::min()
      ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It seems that other people had the same problem and the bug is fixed:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1081905
Now it's up to the Debian/Ubuntu bureaucracy to validate it and put it in the bloody repo... This typically takes a while, and I hate waiting

Anyway, I will eventually have a fully functional Clang/LLVM running on Linux and C++11 capable. So I'll be able to compile DiscoCheck with both GCC and Clang, which will help MacOSX users, who typically use Clang. I'm not a Mac user, but if I understand correctly, people typically use Xcode (IDE) which comes with Apple's Clang (Clang with Apple bugs added).

[ZirconiumX]

I've tried to install Clang/LLVM on my Linux machine, but that stupid compiler can't even compile its own C++11 standard library

Code: Select all

In file included from ./src/movegen.cc:15:
/usr/include/c++/4.6/chrono:666:7: error: static_assert expression is not an integral constant expression
      static_assert(system_clock::duration::min()
      ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It seems that other people had the same problem and the bug is fixed:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1081905
Now it's up to the Debian/Ubuntu bureaucracy to validate it and put it in the bloody repo... This typically takes a while, and I hate waiting

Anyway, I will eventually have a fully functional Clang/LLVM running on Linux and C++11 capable. So I'll be able to compile DiscoCheck with both GCC and Clang, which will help MacOSX users, who typically use Clang. I'm not a Mac user, but if I understand correctly, people typically use Xcode (IDE) which comes with Apple's Clang (Clang with Apple bugs added).

This is why I use Arch Linux. Things are in the repo within a couple of days. Last update for it was 14th Jan.

In all of my tests, Clang has performed FASTER than GCC.

I've yet to try DragonEgg - which is GCC with LLVM backend (and yes, it can use both at the same time for extreme optimization)

Congrats on releasing DC4 - and to think that DC1 was 1947 Elo - you've made a huge amount of progress.

At that rate of development Stockfish might have a new challenger.

Matthew:out