2026-07-27 · Fast DEFLATE compression in Lean

Transcript

Transcript. Paraphrased; sources in notes.md.

HostJuly 27th, 2026. Welcome back to the show. Today we are looking at some interesting shifts in the low-level landscape, starting with a surprising claim about Lean, moving into the wild world of trillion-parameter AI architectures, and wrapping up with a deep dive into the guts of Rust SIMD. Fred, you look like you have been waiting to jump on this Lean story before we even started.

GuestI have seen some wild claims in my time, Daniel, but saying a formal proof engine makes code run faster than idiomatic Rust is a bold way to start a Sunday. I want to see the benchmark trace. I want to see if they are cheating on the compiler flags or if they found some magic.

HostWell, the author is making a point about formal methods, specifically using Lean, which is a theorem prover that doubles as a programming language. They claim their DEFLATE implementation, which is a common compression algorithm, beats miniz_oxide, a standard pure-Rust library, because the proof acts as a safety harness. It apparently lets AI agents generate code that would be too risky for a human to write or maintain without a proof checker.

GuestA safety harness for AI-generated code. That is just a fancy way of saying they are outsourcing the audit to a solver. Look, I like the idea of formal verification, but the second someone says their implementation is faster than a highly tuned, unsafe-free Rust crate, I start looking for the hidden overhead. Over on Lobsters, a user called typesanitizer actually felt the need to clarify that the title of the original post was a bit clickbaity. When the author themselves admits the premise is sensationalized, you have to wonder if the performance delta is even real or just a specific micro-benchmark that favors their approach.

HostIt is a good reminder to check the source material. Speaking of ambitious designs, we have a piece on what the author calls catapulting in AI architecture. They are theorizing about human-sized LLMs, or HLLMs, which would be massive, potentially over 100 trillion parameters. The argument is that if you use high-regularization and cyclical learning rates, you can move away from memorization and get these models to actually reason, like humans, by forcing them into a stable learning regime.

GuestTrillion-parameter models? We are already struggling to keep current ones from hallucinating their own training data, and now they want to scale it up by two orders of magnitude? The claim is that over-parameterization makes the loss landscape smoother, but every time I hear about smoothing the landscape, I just hear about more compute being wasted on a model that probably still does not know how to handle basic arithmetic without a calculator plugin. I am curious, Daniel, where is the efficiency here? You are just throwing more memory at a problem we have not solved at the current scale.

HostThe author argues that current LLMs are brittle because they are under-parameterized for the complexity of human-like generalization. They think the catapulting regime is the key to moving from statistical mimicry to genuine capability. It is a very academic take on model architecture.

GuestIt is the ultimate nerd-sniping problem. Sure, in a perfect mathematical world, a 100-trillion parameter model might converge on some sort of divine truth, but in the real world of GPUs and electricity bills, it sounds like a recipe for a very expensive, very large random number generator.

HostLet us ground things back in reality with the final topic. We are looking at `std::simd::swizzle_dyn` in Rust. The author walks through why generic SIMD operations in Rust struggle to perform when the shuffle mask is determined at runtime, noting that the standard library does not handle these dynamic shuffles nearly as well as hardware-specific intrinsics allow.

GuestNow, this is something I can actually sink my teeth into. SIMD is notoriously painful. When you try to make it generic, you end up hitting the lowest common denominator, which usually means falling off a performance cliff. If you want a fast swizzle, you need to know exactly what hardware you are running on, and the abstraction layer in Rust is clearly failing to map that to the silicon efficiently.

HostIt is a classic struggle between the ergonomics of a safe, high-level language and the raw, unyielding nature of hardware registers.

GuestI have actually hit this exact wall with a SIMD-heavy filter I was writing, where the overhead of the abstraction was costing me more cycles than the actual data processing. I ended up just dipping into assembly because no matter how much you try to teach the compiler, sometimes you just have to tell the hardware what to do directly. When you read through that post, the author is basically saying the current implementation is a disaster because it tries to be too clever with generic logic instead of just letting the CPU do its job.

HostIt sounds like we have a theme today of humans trying to build abstractions that the hardware or the math is not quite ready for, from AI training regimes to formal verification of compression.

GuestExactly. Everyone wants to build a taller tower, but nobody wants to check if the foundation is actually solid. I am going to spend my afternoon looking at that Lean repository, just to see if I can find where they hid the trade-off. I suspect it is in the memory layout, but I will be happy to be proven wrong.

HostI will let you get to your debugging then. Thanks for joining me, Fred, and thanks to everyone over on Lobsters for the discussion threads that made today's episode possible. Join us tomorrow for more.