FFmpeg's costly functions are all written in hand optimised assembly

ask them about creating an account on mastodon, they can share the same posts and show to both comunities

Don't you mean X 🤦‍♂️(the facepalm is directed at Elon, not OP)

Is there a place where people discuss about it? Could be good to have them move, or at least set up a mastodon

In 99 cases out of 100, you won't be able to hand craft assembly better than a good compiler can - partly due to compilers being much better and partly due to the skill level required. 20 or 30 years ago compilers weren't as good and a reasonably competent person could craft more optimised assembly but these days compilers are pretty damn good and you need some extra level of ability to best the compiler.

However, there's still that 1 time out of 100 and given how resource intensive ffmpeg is, it's worth spending that extra time to hyper optimise the code because it'll pay off massively.

The reason is SIMD instructions / vectorized assembly instructions with consideration for delay slots, instruction latency, memory access times etc., for which GCC and Clang optimizers are both terrible and cannot automatically transform C code to them in any but simple cases.

This is also a reason why specialized DSP processors with SIMD capabilities have dedicated proprietary compilers for them.

The logic is that it's much faster which is important for code that runs on a large portion of the world's devices. Pretty much anything to do with video is using ffmpeg. From a set top box, to your phone, computer, YouTube & Netflix, even on Mars.

Video processing is hard, and when you're processing that much data a x10 speedup is huge. That's why it's written in assembly. And there's really no downsides to it because the original implementation is in C (cross-platform), then there are handmade assembly versions for each specific platform (performance). Win-win.

Typically inline assembly is written in an #IFDEF block with a C/C++ alternative provided. Since the assembly is machine specific the devs need to write it for all the processor families they want to optimize for.

EDIT: sorry that was the wrong page, I meant to link this one: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

http://timelessname.com/elfbin/

It's worth a read to have your mind blown about what you can do when you hand optimise assembly.

I have always understood that C generally compiles almost directly to assembly with little to no abstraction overhead, and it would not require platform-specific ASM code.

You have always understood incorrectly then. I'd recommend a trip over to Godbolt and take a look at the assembler output from C code. Play around with compiler options and see the (often MASSIVE!) changes. That alone should tell you that it doesn't compile "almost directly to assembly".

But then note something different. Count the different instructions used by the C compiler. Then look at the number of instructions available in an average CISC processor. Huge swaths of the instruction set, especially the more esoteric, but performance-oriented instructions for very specific use cases, are typically not touched by the compiler.

In the very, very, very ancient days of C the C compiler compiled almost directly to assembly. Specifically PDP-11 assembly. And any processor that was similar to the PDP-11 had similar mappings available. This hasn't been the case, however, likely longer than you've been alive.

Looks like it's also done for ARM. https://twitter.com/FFmpeg/status/1710970016777052326

It would have to be different implementations for different architectures, and so almost definitely have a C-based fallback