Gigantua: 1.5 Giganodes per Second per Core move generator

[tcusr]

Why is Perft7 50% slower in terms of nps than kiwipete? Because of the many many Enpassants. These get "if constexpr" compiled away if no target exists.

what do you mean "the if constexpr are compiled away"? if constexpr only works with constants values and the en passant moves are run time values
also, i still don't understand if this is a perft tool or a chess engine. (if it was an engine you would have to save the moves in a move list and order them and this would defeat the purpose of your fast move generator)

[dangi12012]

what do you mean "the if constexpr are compiled away"? if constexpr only works with constants values and the en passant moves are run time values
also, i still don't understand if this is a perft tool or a chess engine. (if it was an engine you would have to save the moves in a move list and order them and this would defeat the purpose of your fast move generator)

Its a quick perft - which can be made a lot faster by implementing hashtables. The basis for a monte carlo engine. If stockfish visits one node and evaluates that position. In the same time a monte carlo engine with an ultra fast movegen can simulate the move + 50 resulting games in the same time - I think performance *COULD* be competitive.

Many people dont use templates for Whitemove and have If(Whitemove) all over the place. Big mistake.
Few? If any (I have only seen my engine) people use templates for very rare moves like castling. Also BIG performance mistake. Castles are rare. Even better once they happen its not possible to castle again. Enpassants are valid for only one move

Define a class like that:

Code: Select all

class BoardStatus {

public:
    const bool WhiteMove;  const bool HasEPPawn;
    const bool WCastleL; const bool WCastleR;
    const bool BCastleL; const bool BCastleR;

    constexpr BoardStatus(bool white, bool ep, bool wcast_left, bool wcast_right, bool bcast_left, bool bcast_right) :
        WhiteMove(white), HasEPPawn(ep), WCastleL(wcast_left), WCastleR(wcast_right), BCastleL(bcast_left), BCastleR(bcast_right)
    {

    }
    
    constexpr BoardStatus SilentMove() const {
    return BoardStatus(!WhiteMove, false, WCastleL, WCastleR, BCastleL, BCastleR);
}
}

And use it like that:

Code: Select all

template<class BoardStatus status>
MoveFunc(Move& move, Board& board){
     MakeMove<status.SilentMove()>(move, board);
}

Also add the other constexpr functions like Kingmove and Pawnpush which may or may not affect the other flags. Whitemove is always toggled.
Please note how status.SilentMove() is executed as a template parameter at compiletime. When a pawn is pushed there is a constexpr template parameter: status.Pawnpush()

This means the compiler will have to emit every function 64x. But thats the price of performance. I measured it. Its a lot faster. That (and among other things) is why my executable has 12MB but its the fastest perft i have seen in the world in 2021. (excluding gpus and fpgas)

[j.t.]

Many people dont use templates for Whitemove and have If(Whitemove) all over the place. Big mistake.
Few? If any (I have only seen my engine) people use templates for very rare moves like castling. Also BIG performance mistake. Castles are rare. Even better once they happen its not possible to castle again. Enpassants are valid for only one move.

I just want to note that the reason people do that is because it is easier and in a chess engine (that has as a goal to play chess as good as possible) movegen speed is not a priority. The biggest performance eater in a chess engine is usually the evaluation. The overhead for checking for enPassant or castling is minimal, probably the same for having sideToMove not as some compile-time const.

Also, I see you like compile time execution and code generation, so I want to suggest Nim as a programming language, which has really nice compile time support.

[Uri Blass]

Many people dont use templates for Whitemove and have If(Whitemove) all over the place. Big mistake.
Few? If any (I have only seen my engine) people use templates for very rare moves like castling. Also BIG performance mistake. Castles are rare. Even better once they happen its not possible to castle again. Enpassants are valid for only one move.

I just want to note that the reason people do that is because it is easier and in a chess engine (that has as a goal to play chess as good as possible) movegen speed is not a priority. The biggest performance eater in a chess engine is usually the evaluation. The overhead for checking for enPassant or castling is minimal, probably the same for having sideToMove not as some compile-time const.

Also, I see you like compile time execution and code generation, so I want to suggest Nim as a programming language, which has really nice compile time support.

I agree that the reason people do it is because it is easier.
I disagree that speed of move generation is not important and I believe that with a different design the biggest performance eater can be move generation.
For example you may have a lazy cheap evaluation of piece square table changes that you may use only when you are close to the leaves of the search tree.

[j.t.]

I agree that the reason people do it because it is easier.
I disagree that speed of move generation is not important, and I believe that with a different design the biggest performance eater can be move generation.
For example, you may have a lazy cheap evaluation of piece square table changes that you may use only when you are close to the leaves of the search tree.

Sure, different engine designs could cause the move generation speed to be much more important. However, I don't believe that this will be the case for a good/very good engine. I just took a look at Stockfish, and 80% of the time is spent in the NNUE eval, and just about 5% for everything that has to do with movegen. Even in my engine with a semi-decent hand-crafted eval, which should be considerable faster than a neural network, the time spent for generating moves (and applying moves to a position) is significantly below 10%. Of course, this may be different for engines that use a very bare-bones eval (like only PSQT), but even then you'll need to loop over all pieces on the board, and intuitively I think that's already enough to make the movegen take less than 50% of the whole time. Regardless of whether my intuition is correct or not, this will be not the case for most chess programmers, as most engines have a more complex evaluation than just piece square tables.

I didn't mean that a fast move generator is not important for a chess engine, I meant that a fast move generator is enough, and a really fast move generator doesn't help.

[dangi12012]

I didn't mean that a fast move generator is not important for a chess engine, I meant that a fast move generator is enough, and a really fast move generator doesn't help.

I think you are right about normal engines. But if you make a monte carlo engine the fast movegen is EVERYTHING. If stockfish looks at a position and the monte carlo engine can simulate 50 games for that move and generate heuristics from that - the relative play strenght *COULD* be similar.
This movegen comes into that ballpark without hashing. Since for my machine at least its 40M nps for 28 cores and stockfish and (1.5Billion * 28) nps for this movegen.

Also monte carlo engines dont need to know the rules of the game. They just need the outcome. Alphazero is a monte carlo engine with a policy network to guide the search towards promising moves.

So my plan is to make this into a full engine next. But first. Codeprojet - Github release - Low hanging performance improvements + Hashtable + Multithreading need to be implemented!

[j.t.]

...!

Monte-carlo playouts instead of some kind of evaluation (NN or handcrafted) could be interesting indeed, I am looking forward to your experiment. I think monte-carlo engines still need to "know" the rules, they just don't need to know how to guess how good a position is. However, there are some projects that try to create game playing programs that actually don't know the rules of the game they're playing.

What would also be interesting to see with the speed you're providing, if monte-carlo playouts could be done at the leave nodes of an alpha-beta search, instead of a monte-carlo-tree-search (like Alpha Zero does).

[dangi12012]

Quick Update:
Release is on Github now.
Performance version 1.1 is out. I cleaned up the sourcecode and made some tweaks movegen is 10% faster now!

Perft Start 7: 3195901860 3037ms 1052.19 MNodes/s
Perft Kiwi 6: 8031647685 4915ms 1634 MNodes/s

Perft aggregate: 18999768562 12891ms 1473.86 MNodes/s

https://github.com/Gigantua/Gigantua/releases/tag/v1.1

[spirch]

free tip

github is for hosting code not only binary

[Uri Blass]

free tip

github is for hosting code not only binary

It seems that the author does not want to release the source code and release only the binary.

He does not have to release the source code but I see no reason to misleading information by link with the words source code(zip) that as far as I see does not include source code of the program but only some explanation in english.