<p><pre><code> > Normally, when engineers try to make software faster, they work from the bottom up. They run a benchmark, look at a flamegraph, find a hotspot, and figure out how to speed up their code by 15% or 20%. The problem with working from the bottom up is that you don't know what the ceiling is. You might be 20% away from the fastest possible code the hardware can run, or you might be 100x away.
> When we started building Gravity, we flipped this question around. We asked ourselves: how fast can a database actually be? Instead of incrementally speeding up our existing query engine, we wanted to start from the physical speed limit of our hardware and file format and work backward. I like to call this “programming at light speed”.
</code></pre>
What is described as the “normal” approach to optimizing code is really more the “naïve” approach. Any serious performance optimization work would follow the approach of defining first what’s the ceiling the hardware allows and benchmark against that. And that was already true before LLMs.<p>See for example: <a href="https://www.marginalia.nu/log/a_106_native_calls/" rel="nofollow">https://www.marginalia.nu/log/a_106_native_calls/</a><p>Apologies for being nitpicky, but I felt it might be useful for other readers to contextualize that this part of the approach is not novel. Their use of Claude to generate those optimized benchmarks is interesting enough already, so I don’t feel that calling extra attention to this part in their write up is necessary.