Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blowing up my compile times for dubious benefits

claytonwramsey.github.io

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Blowing up my compile times for dubious benefits

#11

Post by harerazer »

JoshTriplett wrote: post #10
harerazer wrote: post #4

While 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 mo…

This makes a lot of sense and gives context to the assumption that we only need to handle the case where an opponent's piece is in the way. Would be great if the author took the 2 sentences to explain this near the beginning of the article.

Re: Blowing up my compile times for dubious benefits

#12

Post by weinzierl »

The bitboard approach is similar to how graphics cards used to organize their memory in the heyday. It wasn't one big buffer per screen with one or more consecutive bytes representing on pixel and one pixel after another. There were as many buffers as required by the bit depth, e.g. one for black and white, two for 4-colors and so on. Every bit was a pixel, so the top left corner was the MSB of the first byte of any buffer. We called this bitplanes.

Re: Blowing up my compile times for dubious benefits

#15

Post by Sharlin »

wyldfire wrote: post #13

Mathematical representation of A-bar / A' - this is the complement of the set A? That should probably be `~A` and not `!A` for the bitboard operation. The logical negation would not give you the desired results, instead you want the bitwise negation (`~A`).

The article should have clarified it, but this is Rust so !A is correct (having a real boolean type, and no implicit casts to int, you don’t need a separate bitwise and logical not. Conceptually, ! always does a bitwise not, which in the case of a single-bit value is also the logical not.)

Re: Blowing up my compile times for dubious benefits

#18

Post by JonChesterfield »

evmar wrote: post #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?

It is better to write obscure compile time code in the metalanguage than to write a separate program which generates the same result, even if the separate program would generate something than can then be spliced in at compile time anyway.

Well, "better". "Industry practice" might be more accurate. Also "necessary" if your build system is garbage and/or your team is frighted of code generators but not meta-programming.

Re: Blowing up my compile times for dubious benefits

#19

Post by JonChesterfield »

thehappypm wrote: post #9
harerazer wrote: post #5

Earlier quoted context omitted.

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

write rust syntax into that file and feed it into the build to delete misc fears about costs or failure modes of loading files

Re: Blowing up my compile times for dubious benefits

#20

Post by wongarsu »

thehappypm wrote: post #9
harerazer wrote: post #5

Earlier quoted context omitted.

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

In rust you can also pre-compute (optionally at build time in the build.rs) and load the file at compile time. Either using std::include_str to get a string with the file content (and then parse at startup without needing the separate file) or you generate a valid rust file and use std::include and still get all the potential compiler optimizations from knowing the values of these constants.

But honestly, the const code for generating the values doesn't look thaaat bad. It's bad by rust standards, but not far from what equivalent C code would look like.

Post reply on HN