Blowing up my compile times for dubious benefits
claytonwramsey.github.io
Blowing up my compile times for dubious benefits
1–10 of 28 posts
Re: Blowing up my compile times for dubious benefits
#2While i enjoyed the article, the title and opening sentence really deserve credit for being genuinely fun to read.
Re: Blowing up my compile times for dubious benefits
#3> to make all the constants known at compile time, everything has to be written in a const function. This means: No allocations [...] No for loops
These constants are relatively unchanging relative to the rest of your program. Why not write a code generator (without the above weird restrictions) to compute them once and save the result?
Re: Blowing up my compile times for dubious benefits
#4While this post has a good amount of substance, I found it rather hard to understand due to small mistakes (or hidden assumptions, or something else?). All of which seem easily fixed/clarified, but these sorts of things are unnecessary friction for readers.
Edit: Thanks to Jasper for stating the big hidden assumption made by the author - that he is only considering the case of being blocked by enemy pieces, not one's own pieces. This is motivated by the fact that one can use the same side occupancy board to trivially remove all moves that are illegal due to self-blocking. This resolves many of the technical issues, although again, it should be be made explicit. The typos/silly errors and pedagogical mistakes remain.
Some examples:
- According to the first bitboard (and the convention stated in the OP), A2 has index 8, not 1.
- In the second bitboard, the rook on e4 should be able to move to e1,a4,e8,h4.
- max of 9 relevant occupancy bits for a bishop - how? A bishop on e4 for example would have to check b1,c2,d3,f5,g6,h7 and a8,b7,c6,d5,f3,g2,h1 for a total of 13 bits. Similar mistake for a the rook.
- The so called "original" masked occupancy bitboard was not mentioned previously
- That same bitboard has variables b1,b2,b3,b4,b5 on it, a notational collision with the squares b1-b5. - The variables b1-b5 are in the wrong place (presumably they were meant to be on c3,d4,e5,f6,g7 since the bishop is on b2, and again there is the question of why not h8 and the other missing squares).
- Magic number comes out of nowhere. What is it doing? Presumably the purpose is to extract the relevant positional bits to be the most significant ones while keeping the order, done through the multiplication + bitmasking, but this should be explicitly stated. We also have no idea how it is derived.
- What are the "collisions" actually collisions of? It would be nice to see an example of this.
Re: Blowing up my compile times for dubious benefits
#5> to make all the constants known at compile time, everything has to be written in a const function. This means: No allocations [...] No for loops These constants are relatively unchanging relative to the rest of your program. Why not write a code generator (without the above weird restrictions) to compute them once and save the result?
I was also confused by this. I was wondering if he was going to use #embed or something of the like.
Re: Blowing up my compile times for dubious benefits
#6While this post has a good amount of substance, I found it rather hard to understand due to small mistakes (or hidden assumptions, or something else?). All of which seem easily fixed/clarified, but these sorts of things are unnecessary friction for readers. Edit: Thanks to Jasper for stating the big hidden assumption made by the author - that he is only considering the case of being blocked by enemy pieces, not one's…
> - In the second bitboard, the rook on e4 should be able to move to e1,a4,e8,h4.
It's trying to find the set of legal moves. Or, rather, it's trying to find the set of illegal moves that it can exclude from the subset of possible moves. The only thing determining whether a move is legal is whether there's a piece in the way of that move, aka whether a piece is occupying a square, that's what the bitboard check is about. If E1 is occupied, the set of legal moves is the same as if it is unoccupied, so it is irrelevant to check the bitboard for E1. I agree the article could be clearer about this.
Re: Blowing up my compile times for dubious benefits
#7While this post has a good amount of substance, I found it rather hard to understand due to small mistakes (or hidden assumptions, or something else?). All of which seem easily fixed/clarified, but these sorts of things are unnecessary friction for readers. Edit: Thanks to Jasper for stating the big hidden assumption made by the author - that he is only considering the case of being blocked by enemy pieces, not one's…
> - In the second bitboard, the rook on e4 should be able to move to e1,a4,e8,h4. It's trying to find the set of legal moves. Or, rather, it's trying to find the set of illegal moves that it can exclude from the subset of possible moves. The only thing determining whether a move is legal is whether there's a piece in the way of that move, aka whether a piece is occupying a square, that's what the bitboard check is ab…
I'm clearly misunderstanding something here. Assuming the rest of the board is empty, if e1 is occupied, the rook can't move to e1, whereas if it isn't occupied, the rook can move to e1, so there is at least one position in which we must check e1. What am I misunderstanding here?
Re: Blowing up my compile times for dubious benefits
#8Earlier quoted context omitted.
> - In the second bitboard, the rook on e4 should be able to move to e1,a4,e8,h4. It's trying to find the set of legal moves. Or, rather, it's trying to find the set of illegal moves that it can exclude from the subset of possible moves. The only thing determining whether a move is legal is whether there's a piece in the way of that move, aka whether a piece is occupying a square, that's what the bitboard check is ab…
I'm clearly misunderstanding something here. Assuming the rest of the board is empty, if e1 is occupied, the rook can't move to e1, whereas if it isn't occupied, the rook can move to e1, so there is at least one position in which we must check e1. What am I misunderstanding here?
Oh, I was assuming it was occupied by an enemy piece, and would capture it. You're right that if it was occupied by an allied piece, it's not a legal move.
Re: Blowing up my compile times for dubious benefits
#9> to make all the constants known at compile time, everything has to be written in a const function. This means: No allocations [...] No for loops These constants are relatively unchanging relative to the rest of your program. Why not write a code generator (without the above weird restrictions) to compute them once and save the result?
I was also confused by this. I was wondering if he was going to use #embed or something of the like.
I’m not a Rustacean, but it seems much easier to pre compute, store in a file, then load the file at startup
Re: Blowing up my compile times for dubious benefits
#10While this post has a good amount of substance, I found it rather hard to understand due to small mistakes (or hidden assumptions, or something else?). All of which seem easily fixed/clarified, but these sorts of things are unnecessary friction for readers. Edit: Thanks to Jasper for stating the big hidden assumption made by the author - that he is only considering the case of being blocked by enemy pieces, not one's…
> - max of 9 relevant occupancy bits for a bishop - how? A bishop on e4 for example would have to check b1,c2,d3,f5,g6,h7 and a8,b7,c6,d5,f3,g2,h1 for a total of 13 bits. Similar mistake for a the rook.
If I'm understanding correctly: it's trivial to use a mask with the occupancy bitmap for white/black to eliminate moves atop your own pieces, and generate captures for moves atop your opponent's pieces. The sliding move handling needs to look up whether a piece is in the way of your destination. So, the sliding move handling doesn't need to handle spaces on the edge of the board, because they'll never be in the way of another square.