Zangdar - petit sorcier deviendra grand

[j.t.]

Well, This is new, but I don't go the XXRL list every day.

The CCRL lists are usually updated on weekends.

[mvanthoor]

How do the guys at CCRL knows that a new version is there ?

If you are lucky, one of the CCRL members is interested in your engine for whatever reason (new engine, special techniques used, not often seen programming language, ...) and they follow it. To make sure the CCRL team sees your new release, you can post it here:

Engine release topic 2022

Take into account that if you post releases very quickly, the CCRL-team may decide to skip one or more releases. Also, if you post a release while one of your earlier releases is already running in an tournament, they'll probably not cancel the tournament but skip the release. Personally I'd post a release, wait for it to appear in the CCRL-list (mostly takes 1-2 weeks), and then wait another 4 to 6 weeks at least with the next release you would like to see tested. There are many engines, and many releases, and the CCRL-members don't have the computing power to test engines on a hyper-active release schedule.

Obviously you can release as often as you'd like, but then you can never be sure which release CCRL is going to test.

[pedrojdm2021]

I tried to compile under Linux with this command:

Code: Select all

gcc -o zangdar *.cpp

I get many "undefined reference" errors.

Code: Select all

/usr/bin/ld: /tmp/ccS9xrk6.o: in function `__static_initialization_and_destruction_0(int, int)':
Attack.cpp:(.text+0x58f): undefined reference to `std::allocator<char>::allocator()'
/usr/bin/ld: Attack.cpp:(.text+0x5a8): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'
/usr/bin/ld: Attack.cpp:(.text+0x5b7): undefined reference to `std::allocator<char>::~allocator()'
...

gcc is for C.

for C++ is with g++.

This worked for me, in windows.

g++ -o zangdar.exe *.cpp

[Roland Chastain]

This worked for me, in windows.

g++ -o zangdar.exe *.cpp

Thanks. It works under Linux too.

[Carbec]

Hello,

After a long pause, I decided to continue the developpement. I now use magic bitboards.
I looked how several engines are coded, but its far from obvious to go inside a source.
I also looked the videos from BBC, which explained a lot of stuff :

Finally, I took the library libchess : https://github.com/kz04px/libchess
It works very well, it's fast. The code is relatively understandable.

So, I am now adaptating my ancient code to this library.
next stage : UCI commands, so I can use an interface to see how it plays.

[Carbec]

Hello,

After a bit of optimisation, Zangdar achieve about 100 Mnodes/sec, which is very superior than my old program (20 Mnodes/sec).
UCI protocol is now implemented, I could play a game or two against it with Arena.
Now Is the time for optimisation. Moves ordering, better alpha-beta, .. and so one.

[hgm]

Sounds suspect. Typically 2 Mnps is about as fast as you can go (single threaded).

[Carbec]

Hello,

Here is the output :

Code: Select all

 T:\Echecs\Programmation\Zangdar\build-Zangdar-2-Desktop_Qt_6_4_0_MinGW_64_bit-Release\release> .\Zangdar-2.01.01.exe cli
Entrez une commande : [help] gen 7

  8 r n b q k b n r
  7 p p p p p p p p
  6 . . . . . . . .
  5 . . . . . . . .
  4 . . . . . . . .
  3 . . . . . . . .
  2 P P P P P P P P
  1 R N B Q K B N R
    a b c d e f g h

Castling : KQkq
EP       : -
Turn     : w

sec      = 31.213
sec time = 31.213
Total           : 3195901860
Million Moves/s : 102.4
resultat        : OK

This is perft , with bulk counting, on depth 7.
Or perhaps I didn't make the right calculation for the number of moves per second ?
The time is really 31 seconds.

[Aleks Peshkov]

Code: Select all

set hash 1g
go perft depth 7
info depth 7 perft 3195901860 nodes 22122501 time 2554 nps 8661903 hwrites 900381 hhits 1024852 hreads 1925233 hhitratio 532

It is more clear to count actual played nodes per second, not perft number per second.

[Carbec]

Hello,

I encountered a strange thing. I have an array like this : uint64_t table[64][64]. I initialise it with a function somewhere in the code.
So when I learned about constexpr initialisation, i thought "great". But in fact, I didn't had any improvement, but a very slight decrease
in speed.
The code is like this :

Code: Select all

constexpr  std::array<std::array<Bitboard, 64>, 64> table= []()
{
     std::array<std::array<Bitboard, 64>, 64> result = {};

... calculation...
    for (int i = 0; i < 64; ++i) {
        for (int j = 0; j < 64; ++j) {
            }

        }
    }

    return result;
}();


[[nodiscard]] constexpr Bitboard get_table(const int sq1, const int sq2) {
    return table[sq1][sq2];
}

I seen this sort of initialisation in several codes (see the posts about sliding pieces algo).
Is this general, or particular for my array (2-dimension) ?

Thanks