Decent ones do. .NET's JIT has historically (before ryujit especially and tbh I haven't looked at .NET much in the past decade) not been decent, general statements about decent compilers never applied to it. It has been playing catch-up lately but apparently it still has a ways to go.

It surprises me that it runs on the CPU at all, honestly.

[flagged]

Yep if you want it done quickly, the GPU is the way to go. Especially once you get to 4K resolution and beyond.

See here:

https://aras-p.info/blog/2026/10/01/Fast-blur-with-animated-...

If we look at the example of the FFT blur filter, sure O(n) looks easier and independent of the blur size, but you have an overhead in needing FFT and iFFT. It can be faster for some sigmas, but not for all. So you need different variants depending on sigma and a smooth transition between them.

Then you can start approximating - for large sigmas just using every 10th pixel would work. Looks like MS Teams background blur is doing this, you get a blurry background with aliasing - yay!

Once you add SIMD variants and look at CPU caching behaviour, you build versions for different CPUs. Instead of filtering the whole image for one dimension you might finish blocks locally.

You've now got a dozen variants that need testing and maintenance on different architectures.

I'm reminded of my colleague preaching requirements engineering - what was the goal gain?

Why would you want them in AOT, though? It's great for startup time and native interoperability, but it might be slower in general due to machine specific optimizations.

And 8% milk would taste bad and ruin most recipes.

I don't know why we're comparing completely different categories of number though. In a business context getting a project done a few percent faster, or more accurately one step done a few percent faster, barely affects revenue at all. And saving CPU time matters even less.