bluuewhale

7 ms·

1. 1.▲
   I built an autoresearch loop for performance engineering (27% speedup hashtable)(bluuewhale.github.io)

   2 points by bluuewhale 6mo ago|0 comments
2. 2.▲
   by bluuewhale 9mo ago

   Author here! I wanted to share a follow-up to this post. https://bluuewhale.github.io/posts/further-optimizing-my-jav... This time I went back with a profiler and optimized the actual hot path. A huge chunk of time was
3. 3.▲
   by bluuewhale 9mo ago

   Great write-up. This kind of "debugging journey" post is gold.
4. 4.▲
   by bluuewhale 9mo ago

   Ohhh, I went digging after your comment and I think this is exactly what you were referring to: JDK-7192942 ("Inefficient calculation of power of two in HashMap"). I honestly love hearing about these hidden gem micro-optimizations
5. 5.▲
   by bluuewhale 9mo ago

   This is a really fun project! In SwissTable, the main difference is that you only get a probabilistic signal of presence (kind of like a Bloom filter), but the core idea feels very similar.
6. 6.▲
   by bluuewhale 9mo ago

   Thanks. This is actually one of the topics I really want to tackle next. If we just wrap every API call with synchronized, I'd expect heavy contention (some adaptive spinning and then OS-level park/unpark), so it'll likely bo
7. 7.▲
   by bluuewhale 9mo ago

   Thanks for the heads-up! I'm still figuring out Hugo, so I'm not sure I can fix it right away, but I'll take a look.
8. 8.▲
   by bluuewhale 9mo ago

   Thanks! Appreciate it
9. 9.▲
   by bluuewhale 9mo ago

   Thanks for the feedback. You've nailed the core idea. I'll tweak the structure a bit to make the concepts clearer up front.
10. 10.▲
    by bluuewhale 9mo ago

    Author here! Thanks for the great point. This is actually the main topic I'm working on for the next post. It's understandable to expect SIMD to win purely because it's wider, but in practice the end-to-end cost matters more