<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Bloom Filters on Shai Asher</title><link>https://slow-is-smooth.io/categories/bloom-filters/</link><description>Recent content in Bloom Filters on Shai Asher</description><generator>Hugo</generator><language>en-gb</language><lastBuildDate>Sat, 05 Sep 2026 14:46:43 +0000</lastBuildDate><atom:link href="https://slow-is-smooth.io/categories/bloom-filters/index.xml" rel="self" type="application/rss+xml"/><item><title>The Bloom Filter Optimization Saga: The "Benign" Read That Wasn't</title><link>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-the-benign-read-that-wasnt/</link><pubDate>Sat, 05 Sep 2026 14:46:43 +0000</pubDate><guid>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-the-benign-read-that-wasnt/</guid><description>&lt;h2 id="a-go-concurrency-and-memory-model-deep-dive"&gt;A Go Concurrency And Memory Model Deep Dive&lt;/h2&gt;&#10;&lt;p&gt;&lt;img src="https://slow-is-smooth.io/images/the-bloom-filter-optimization-saga-the-benign-read-that-wasnt/from-the-trenches-image.png" alt=""&gt;&lt;/p&gt;&#10;&lt;p&gt;In software engineering, some of the most insidious bugs are the ones that hide behind correct-looking code. This is a war story about a data race that slipped into a highly optimized, &amp;ldquo;thread-safe&amp;rdquo; Go Bloom filter. It’s a practical lesson in humility and a reminder that when it comes to concurrency, the Go race detector is the ultimate arbiter of truth.&lt;/p&gt;</description></item><item><title>The Bloom Filter Optimization Saga: A Deep Dive into Go Assembly and AVX2</title><link>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-a-deep-dive-into-go-assembly-and-avx2/</link><pubDate>Mon, 10 Nov 2025 11:18:02 +0000</pubDate><guid>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-a-deep-dive-into-go-assembly-and-avx2/</guid><description>&lt;p&gt;If you&amp;rsquo;ve ever wondered how high-performance Go programs achieve their incredible speeds, the answer often lies hidden just beneath the surface, in files exactly like &lt;code&gt;avx2.s&lt;/code&gt;. This file is a fascinating example of targeted, low-level optimization.&lt;/p&gt;&#10;&lt;p&gt;So, let&amp;rsquo;s break down what this code does, why it exists, and how it works its magic.&lt;/p&gt;</description></item><item><title>The Bloom Filter Optimization Saga: Anatomy of a Go Concurrency Bug - Part 2</title><link>https://slow-is-smooth.io/blog/anatomy-of-a-go-concurrency-bug-2/</link><pubDate>Thu, 06 Nov 2025 19:16:25 +0000</pubDate><guid>https://slow-is-smooth.io/blog/anatomy-of-a-go-concurrency-bug-2/</guid><description>&lt;h3 id="final-optimization-solving-the-10x-performance-hit"&gt;Final Optimization: Solving the 10x Performance Hit&lt;/h3&gt;&#10;&lt;p&gt;This brings us to the performance report. We have successfully achieved a fully thread-safe implementation, but at a high cost. The performance results file shows a catastrophic &lt;strong&gt;8-12x performance regression&lt;/strong&gt;.&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;The Root Cause:&lt;/strong&gt; The bottleneck is not the &lt;code&gt;sync.Pool&lt;/code&gt; and not the atomic operations. It is the fix for Race #2: &lt;code&gt;positions := make([]uint64, bf.hashCount)&lt;/code&gt;&lt;/p&gt;</description></item><item><title>The Bloom Filter Optimization Saga: Anatomy of a Go Concurrency Bug - Part 1</title><link>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-anatomy-of-a-go-concurrency-bug-part-1/</link><pubDate>Sun, 02 Nov 2025 19:27:14 +0000</pubDate><guid>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-anatomy-of-a-go-concurrency-bug-part-1/</guid><description>&lt;p&gt;Github Project : &lt;a href="https://github.com/shaia/BloomFilter"&gt;https://github.com/shaia/BloomFilter&lt;/a&gt;&lt;/p&gt;&#10;&lt;h2 id="when"&gt;&lt;strong&gt;When &amp;lsquo;Read&amp;rsquo; Operations Mutate State&lt;/strong&gt;&lt;/h2&gt;&#10;&lt;p&gt;I recently investigated a critical bug in the&lt;code&gt;BloomFilter&lt;/code&gt; package that was causing panics under concurrent use. The&lt;code&gt;bloomfilter_concurrent_test.go&lt;/code&gt; file said it all: every test was skipped, citing a &amp;ldquo;nil pointer dereference in storage layer&amp;rdquo;.&lt;/p&gt;</description></item><item><title>The Bloom Filter Optimization Saga: From 3 Seconds to 66 Microseconds</title><link>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-from-3-seconds-to-66-microseconds/</link><pubDate>Thu, 30 Oct 2025 19:13:00 +0000</pubDate><guid>https://slow-is-smooth.io/blog/the-bloom-filter-optimization-saga-from-3-seconds-to-66-microseconds/</guid><description>&lt;p&gt;Building high-performance libraries often involves more than just clever algorithms. It&amp;rsquo;s a journey of measurement, discovery, and sometimes, learning that your &amp;ldquo;obvious&amp;rdquo; fix made things worse. &lt;a href="https://github.com/shaia/BloomFilter"&gt;Go SIMD-Optimized Bloom Filter&lt;/a&gt;, which you can read all about &lt;a href="https://slow-is-smooth.io/blog/simd-optimized-bloom-filter-in-go-an-in-depth-exploration/"&gt;here&lt;/a&gt;, is a project that started with a 4x SIMD speedup and ended with a &lt;strong&gt;6,595x&lt;/strong&gt; overall speedup after a deep dive into Go&amp;rsquo;s profiling tools.&lt;/p&gt;</description></item><item><title>SIMD-Optimized Bloom Filter in Go: An In-Depth Exploration</title><link>https://slow-is-smooth.io/blog/simd-optimized-bloom-filter-in-go-an-in-depth-exploration/</link><pubDate>Mon, 22 Sep 2025 07:03:20 +0000</pubDate><guid>https://slow-is-smooth.io/blog/simd-optimized-bloom-filter-in-go-an-in-depth-exploration/</guid><description>&lt;p&gt;&lt;strong&gt;Project Repository:&lt;/strong&gt; &lt;a href="https://github.com/shaia/BloomFilter"&gt;https://github.com/shaia/BloomFilter&lt;/a&gt;&lt;/p&gt;&#10;&lt;h3 id="from-go-to-assembly"&gt;From Go to Assembly&lt;/h3&gt;&#10;&lt;p&gt;When we think of Go, we think of concurrency, simplicity, and &amp;ldquo;good enough&amp;rdquo; performance. But what happens when &amp;ldquo;good enough&amp;rdquo; isn&amp;rsquo;t good enough? What happens when you need to squeeze every last drop of performance out of the CPU for a critical, hot-path operation?&lt;/p&gt;</description></item></channel></rss>