C vs. C#: racing VLC's Gaussian blur (martinfinkel.com)

69 pointsby martz3 days ago16 comments

theanonymousone 8 minutes ago

> Two small edits close most of it: compute the loop bounds into locals before the loop,

I always assumed any decent runtime/compiler takes care of such optimisations, and usually leave such things to JDK in my Java code. Is that really not the case?

teo_zero 2 hours ago

Nice article!

What surprises me is that the original VLC filter does not use SIMD. Sometimes I wonder why I spent my money on a "modern" CPU with a lot of new features that stay completely ignored by most software I run every day.

fenwick67 2 hours ago

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

ygra 2 hours ago

Probably a reflection of the age of that code along with the usefulness of the feature. If no one actually needs the video blurry, then it doesn't matter how efficient the filter is.

brookman64k 2 hours ago

I would have expected the filters to run as a shader on the GPU which would make them much more efficient. I remember implementing two-pass gaussian blur in GLSL almost 20 years ago.

bschwindHN 2 hours ago

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-...

anderskaseorg 2 hours ago

There are much faster algorithms available for Gaussian blur though, running in O(n) rather than O(nσ) for an n pixel image and radius σ. See https://www.ipol.im/pub/art/2013/87/article.pdf for a survey.

schobi an hour ago

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?

anderskaseorg 8 minutes ago

FFT is O(n log n), not O(n). The better O(n) algorithms are the likes of Deriche, Vliet–Young–Verbeek, or Alvarez–Mazorra.

hn_submit an hour ago

The C# version uses unsafe raw pointers which is practically the same as writing it in C. No surprise then that the outcomes are similar.

maxlin 5 hours ago

Very interesting readup! I have some C# projects I've had in mind to try to compile to AOT. Quite different for complex programs of course, but the perf being very close to C is a great motivator.

mihular 2 hours ago

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.

mcraiha 2 hours ago

Because of Docker. You want the images to be as small as possible.

littlecranky67 7 minutes ago

I would object, I want my containers to be as fast as possible and the JIT compiles for each CPU arch you run it on (supposedly optimally). Docker image size, who cares?

Brian_K_White 3 hours ago

Most industries consider 8% a mountain. More than their entire profit margin.

Dylan16807 3 hours ago

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.