Mar 28, 2025

@pmienk and I did some pair programming today on the fancy hashmap filter. We made two minor changes, one that was reverted after testing (with a slight refactor and to make it more obvious) and the other that slightly improved the efficiency of the filter. I mentioned that I was planning to refactor the sieve class into a static class (basically a templatized namespace) because it holds no dynamic state. I've completed that, which simplified the code and maybe gave tiny perf boost. I also updated tests, refactored, and added better runtime instrumentation to measure the filter perf. I then got into the runtime debugger and quickly confirmed that the filter was not actually having an effect (which was nice to confirm). I was not returning the right value from the header updating method. I also handled an error condition that I mentioned had been commented out. These required a minor refactor of the hashhead and hashmap templates. This made things pertaining to the filter quite a bit simpler. It's now all together and checked in, and I'm running for the first time at full milestone speed and concurrency on the maxi and with good instrumentation. Passing block 450k I've got a couple quick data points: 369 / (322040940 + 369) <= this is ratio of point searches to total point writes passing block 400k. That's 1.14 / 1,000,000 = 0.00014% . Passing 450k it's 1757 / (484908338 + 1757) or 0.00036% . And 450k the baseline time is generally around 650 seconds, and with this change (which includes 8 GiB of extra header), we're at 656 seconds. Well within typical deviations.