JProfiler, Perft and performance observations

[osvitashev]

I decided to run Perft function with JProfiler.
Overall, Perft runs at about 3 million nodes/second on my machine, which is pretty slow, but i realize that Java is supposed to be slower than C++. For comparison, kz04px/libchess which is written in C++ runs at about 50 million nodes/second.
Here are some observations:

• LinkedList.add and LinkedList.addLast together contribute to 30% of both CPU and memory allocation time. Perhaps LinkedList is not the best choice for storing legal moves and move history, due to the memory being allocated incrementally?
• Long.valueOf takes about 10% of CPU and memory allocation time. Seems like there might be some extra conversion between java primitive and object wrapper.
• MoveBackup and EnumMap take up about 10% or resources each. Perhaps, EnumMap has too much of a footprint for a structure which essentially only stores four boolean flags.
• Board.doMove takes about 15% of resources. Here, i am not sure what can be improved, at the moment.

I might take a stab at these at some point. Below are JProfiler screenshots. Let me know is i am on a totally wrong track.

[dcolazin]

I'm currently doing some perft on a i3-10110U. The times of a perft(6) are the following:

• stockfish 10: 600-670ms
• stockfish 17: 900-1000ms
• lichess-compression (naive depth first, warm jvm): 7700-8000ms
• lichess-compression (avoiding object instantiation, warm jvm): 780-800ms
• bhlangonijr-chesslib 1.3.3 (warm jvm): 29000-35000ms

Source code of lichess-compression can be found here https://github.com/lichess-org/compression

Without going deeper on the actual movegen algorithm, object instantiation should be avoided in such thigh loop.

Sadly, the interfaces of bhlangonijr-chesslib are not well suited for the required optimizations:

• Move fields are immutable, so objects cannot be reused;
• MoveBackup management can be externalized from Board, to reuse objects;
• Move object does not contain data (for example, piece moved) that needs to be recalculated from bitboards/occupation array;
• Board bitboard implementation might be rationalized, but improvements are not significant compared to previous issues;
• avoid using EnumMap in Board and MoveBackup.