Is it important for move representation to be small ?

[AlvaroBegue]

I do keep the board as an array of 64 ints, in addition to the bitboards. Since I undo moves, I very rarely copy boards, so having this convenient representation is almost free.

[Don]

I do keep the board as an array of 64 ints, in addition to the bitboards. Since I undo moves, I very rarely copy boards, so having this convenient representation is almost free.

As far as I can tell it is also free in Komodo. Actually, we got a big speed boost because it was stupid not having this representation, I had to decode what was on a square the hard way. But I did experiments where I made the state 4x larger and the slowdown was extremely trivial, so I am not so paranoid about adding something to the state that might be useful. I think any modern processor copies the 64 bytes I added really fast, especially when it's already copying the rest of the state and of course I get the gain in speed from not having any undo logic whatsoever.

[OneTrickPony]

Thanks all for answers, this is very helpful.

[lucasart]

I do keep the board as an array of 64 ints, in addition to the bitboards. Since I undo moves, I very rarely copy boards, so having this convenient representation is almost free.

I never copy the board, just load positions, play/undo moves and that's it. I suppose the only use case for copying the board is in SMP, as each search thread must have its own board to play with.

[Don]

I do keep the board as an array of 64 ints, in addition to the bitboards. Since I undo moves, I very rarely copy boards, so having this convenient representation is almost free.

I never copy the board, just load positions, play/undo moves and that's it. I suppose the only use case for copying the board is in SMP, as each search thread must have its own board to play with.

You could be right about this, but as I have stated I cannot see in a profile that making a move is taking much time. I am not quite the performance freak I was in the old days and prefer having clean code so having special case code for copying in one situation and making in another goes against the grain and KISS programming principles and goes against the grain for me. But I would do it if I could get 1/2 percent speedup of course, but I cannot.

So this must be a big win for you to go for the extra complexity. How much do you estimate that it gives you? How much did copy/make slow you down when you tried it?

[lucasart]

I do keep the board as an array of 64 ints, in addition to the bitboards. Since I undo moves, I very rarely copy boards, so having this convenient representation is almost free.

I never copy the board, just load positions, play/undo moves and that's it. I suppose the only use case for copying the board is in SMP, as each search thread must have its own board to play with.

You could be right about this, but as I have stated I cannot see in a profile that making a move is taking much time. I am not quite the performance freak I was in the old days and prefer having clean code so having special case code for copying in one situation and making in another goes against the grain and KISS programming principles and goes against the grain for me. But I would do it if I could get 1/2 percent speedup of course, but I cannot.

So this must be a big win for you to go for the extra complexity. How much do you estimate that it gives you? How much did copy/make slow you down when you tried it?

I don't know. I've never tried to copy the board for playing moves. It always felt natural and logical to me that there's one board, and I play and undo moves on that board. If I was to do it your way now, it would be a major rewrite, and considering that my board code is really optimized, I can't be bothered. Anyway, there are far more important things in an engine than board and movegen code. As you say, if done correctly and assuming a fully featured engine with a decent eval, these parts are quite small on the profiling.

[Don]

I do keep the board as an array of 64 ints, in addition to the bitboards. Since I undo moves, I very rarely copy boards, so having this convenient representation is almost free.

I never copy the board, just load positions, play/undo moves and that's it. I suppose the only use case for copying the board is in SMP, as each search thread must have its own board to play with.

You could be right about this, but as I have stated I cannot see in a profile that making a move is taking much time. I am not quite the performance freak I was in the old days and prefer having clean code so having special case code for copying in one situation and making in another goes against the grain and KISS programming principles and goes against the grain for me. But I would do it if I could get 1/2 percent speedup of course, but I cannot.

So this must be a big win for you to go for the extra complexity. How much do you estimate that it gives you? How much did copy/make slow you down when you tried it?

I don't know. I've never tried to copy the board for playing moves. It always felt natural and logical to me that there's one board, and I play and undo moves on that board. If I was to do it your way now, it would be a major rewrite, and considering that my board code is really optimized, I can't be bothered. Anyway, there are far more important things in an engine than board and movegen code. As you say, if done correctly and assuming a fully featured engine with a decent eval, these parts are quite small on the profiling.

It feels natural to you because that is how humans execute a move on the board, but I have discovered that my intuition about what takes a lot of time and what doesn't is pretty unreliable. It gets processed by the brain in terms we are used to experiencing in real life. The idea of copying 200 bytes just makes you cringe doesn't it? Part of that is probably because it would take a minute or so for you to COUNT to 200 as opposed to picking up a piece and moving it on a board!

I find that I have to fight my instincts which were developed from the days I programmed a 4k RAM computer. The UCI protocol is a case in point, some people cringe at the thought of passing a 50 move string to a chess engine and I have heard some people imply that it was a very slow I/O bound process. It's I/O bound for sure, but it doesn't prevent me from being able to play 50 games per second at low depth on a quad - so it's probably not as slow as some might think. In comparison to doing a 1 ply search for example the protocol time is trivial. Having been brought up in the days of 300 baud acoustical modems, my very first initial thought when I read the UCI protocol was that it was just crazy! But then I remembered that you can watch streaming video's over the incredibly slow internet and I came to my senses!

Anyway, enough of that. As it turns out it really doesn't matter as you say.

Don