kbhearn wrote:Do you have an initialiser list for ChessMoveSort? there are 256 of those every time you make a ChessMoveOrder - the constructor needs to be entirely empty including initialiser list.
Yes, for ChessMoveSort and ChessMove, I didn't realized the cost of initializer list.
But now I have to fix some problems with non initialized value for these classes.
If you keep the number of moves in a member variable (as opposed to marking the end of the move list with a special invalid move), you shouldn't be accessing uninitialized memory at any point. [EDIT: Actually, even with the special invalid move marking the end, there shouldn't be a problem, now that I think about it.]
I use unsigned int as my move type, where the bottom 16 bits actually encode the move and the top 16 bits can be used for sorting. You can then just sort moves as unsigned integers. I believe this scheme is fairly common, although I haven't spent any significant time reading other people's chess code.
Patrice Duhamel wrote:
Yes I could do this, but for smp I will need to preallocate it for each threads, nothing to copy between threads but more wasted memory.
I have global arrays for this stuff. The mother of the arrays occupies 53 MB, due to having space preallocated for up to 128 threads/127 depth. Sure is a lot of wasted space, but nobody notices it (or at least nobody told me nothing about it), nor the speed of the engine.
No memory is allocated during runtime, other than the main hash.
cdani wrote:
I have global arrays for this stuff. The mother of the arrays occupies 53 MB, due to having space preallocated for up to 128 threads/127 depth. Sure is a lot of wasted space, but nobody notices it (or at least nobody told me nothing about it), nor the speed of the engine.
No memory is allocated during runtime, other than the main hash.
Yes it's not very important, I don't know if I will stay with the preallocated array or not.
I want to improve the quality of my code from a mix of old C++ and C to something more readable in modern C++, but I don't want to loose speed.
AlvaroBegue wrote:If you keep the number of moves in a member variable (as opposed to marking the end of the move list with a special invalid move), you shouldn't be accessing uninitialized memory at any point. [EDIT: Actually, even with the special invalid move marking the end, there shouldn't be a problem, now that I think about it.]
I use unsigned int as my move type, where the bottom 16 bits actually encode the move and the top 16 bits can be used for sorting. You can then just sort moves as unsigned integers. I believe this scheme is fairly common, although I haven't spent any significant time reading other people's chess code.
If I don't initialize my ChessMove class value to zero, I don't have the same nodes count as before.
My move is in a 32 bits int, because I have src + dst + moved piece + captured piece + castling + en passant + promotion.
I usually use a stack in a global array for the move lists. That packs the moves better than having a worst-case fixed-size array on the machine stack. Plus that I often have no idea what the worst case could be. It doesn't pack the moves perfectly, though, because I usually leave a gap between the move list for one ply and the next, in order to be able to grow the list in both directions. E.g. during generation add captures to the front, and non-captures to the end, to save time during capture extraction, or to sort the best move of one IID iteration to the front of the list without having to shift the entire list down.
