It's not progressing well, but I'm still obsessed by trying to prove my idea of the "Birthday Benchmark" to test data structures / caches.
The idea is that I can test data structures by searching for duplicates in a stream of random data. If we can generate (or pre-generate) the random data fast enough to not impact the benchmark, then what we have is a way to demonstrate the read/write speed of caching. It is easily tunable by adjusting how many bits need to match. I think my best is 7 bytes, but 6 bytes runs comfortably fast.
The framework has some interesting "control group" data structures too, such as the "psychic" which is just statically looking for 0x002577309E3361C (not real example) since it happens to know that's the first repeat in the data.
However, I keep getting stuck in "analysis paralysis" around the actual development, when I know I should just knuckle down and write all the code and see what happens. I've fallen into that tricky place where my ambition is greater than my ability to actually deliver it.
In particular I want to get multi-threading synchronisation working well enough that they are demonstrably faster, and not just falling into a result where the speed-up would be the same as if threads weren't sharing the data structure at all. N threads all randomly looking for a duplicate will if not sharing data find a duplicate faster because the expected minimum time to dupe is reduced a little by more threads searching, but if actually embarrassingly parallel while sharing data, it ought to find it in 1/N the time. With synchronisation methods it ought to fall between those two extremes, and this would also be a good way to test the effective concurrency of concurrent data structures and synchronisation methods.