Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

tomshardware.com

Post reply on HN
Print view View original

41–50 of 138 posts

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#41

Post by smj-edison »

viraptor wrote: post #21
smj-edison wrote: post #17

Earlier quoted context omitted.

I'd be worried about compile times, lol. Final binaries are quite often tens to hundreds of megabytes, pretty sure an LLM processes tokens much slower than a compiler completes passes. EDIT: another thought: non-deterministic compilation would also be an issue unless you were tracking the input seed, and it would still cause spooky action at a distance unless you had some sort of recursive seed. Compilers are suppose…

There's no reason to run the optimisation discovery at compile time. Anything that changes the structure can be run to change the source ahead of time. Anything that doesn't can be generalised into a typical optimisation step in the existing compiler pipeline. Same applies to Souper for example - you really don't want everyone to run it.

I'm not quite understanding your comment, are you saying that ANNs are only useful for tuning compiler heuristics?

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#42

Post by mhh__ »

tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

Compilers are extremely good considering the amount of crap they have to churn through but they have zero information (by default) about how the program is going to be used so it's not hard to beat them.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#43

Post by dataangel »

dragontamer wrote: post #16
ksclk wrote: post #14

Earlier quoted context omitted.

> you can already use a SAT solver Could you elaborate please? How would you approach this problem, using a SAT solver? All I know is that a SAT solver tells you whether a certain formula of ANDs and ORs is true. I don't know how it could be useful in this case.

Pretty much all instructions at the assembly level are sequences of AND/OR/XOR operations. SAT solvers can prove that some (shorter) sequences are equivalent to other (longer) sequences. But it takes a brute force search. IIRC, these super optimizing SAT solvers can see patterns and pick 'Multiply' instructions as part of their search. So it's more than traditional SAT. But it's still... At the end of the day.... A S…

You're a bit naive about the complexity. Commonly longer sequences are actually faster, not just because instructions vary in their speed, but also because the presence of earlier instructions that don't feed results into later instructions still affect their performance. Different instructions consume different CPU resources and can contend for them (e.g. the CPU can stall even though all the inputs needed for a calculation are ready just because you've done too many of that operation recently). And then keep in mind when I say "earlier instructions" I don't mean earlier in the textual list, I mean in the history of instructions actually executed; you can reach the same instruction arriving from many different paths!

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#44

Post by [deleted] »

tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

[deleted]

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#45

Post by mananaysiempre »

tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

Looking at the linked patches, you’ll note that the baseline (ff_detect_range_c) [1] is bog-standard scalar C code while the speedup is achieved in the AVX-512 version (ff_detect_rangeb_avx512) [2] of the same computation. FFmpeg devs prefer to write straight assembly using a library of vector-width-agnostic macros they maintain, but at a glance the equivalent code looks to be straightforwardly expressible in C with Intel intrinsics if that’s more your jam. (Granted, that’s essentially assembly except with a register allocator, so the practical difference is limited.) The vectorization is most of the speedup, not the assembly.

To a first approximation, modern compilers can’t vectorize loops beyond the most trivial (say a dot product), and even that you’ll have to ask for (e.g. gcc -O3, which in other cases is often slower than -O2). So for mathy code like this they can easily be a couple dozen times behind in performance compared to wide vectors (AVX/AVX2 or AVX-512), especially when individual elements are small (like the 8-bit ones here).

Very tight scalar code, on modern superscalar CPUs... You can outcode a compiler by a meaningful margin, sometimes (my current example is a 40% speedup). But you have to be extremely careful (think dependency chains and execution port loads), and the opportunity does not come often (why are you writing scalar code anyway?..).

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/346725.h...

[2] https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/346726.h...

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#46

Post by izabera »

AaronAPU wrote: post #15

When I spent a decade doing SIMD optimizations for HEVC (among other things), it was sort of a joke to compare the assembly versions to plain c. Because you’d get some ridiculous multipliers like 100x. It is pretty misleading, what it really means is it was extremely inefficient to begin with. The devil is in the details, microbenchmarks are typically calling the same function a million times in a loop and everything…

ffmpeg is not too different from a microbenchmark, the whole program is basically just: while (read(buf)) write(transform(buf))

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#47

Post by haiku2077 »

mhh__ wrote: post #42
tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

Compilers are extremely good considering the amount of crap they have to churn through but they have zero information (by default) about how the program is going to be used so it's not hard to beat them.

If anyone is curious to learn more, look up "profile-guided optimization" which observes the running program and feeds that information back into the compiler

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#48

Post by k_roy »

pizlonator wrote: post #5
Aardwolf wrote: post #4

The article somtimes says 100x, other times it says 100% speed boost. E.g. it says "boosts the app’s ‘rangedetect8_avx512’ performance by 100.73%." but the screenshot shows 100.73x. 100x would be a 9900% speed boost, while a 100% speed boost would mean it's 2x as fast. Which one is it?

The ffmpeg folks are claiming 100x not 100%. Article probably has a typo

That would be quite the percentage difference with 100x

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#49

Post by eukara »

gronglo wrote: post #31
hashishen wrote: post #29

Earlier quoted context omitted.

It doesn't matter. This is inherently better because the dev knows exactly what is being done. Llms could cripple entire systems with assembly access

You could run it in a loop, asking it to improve the code each time. I know what the ffmpeg devs have done is impressive, but I would be curious to know if something like Claude 4 Opus could make any improvements.

I think if it was easy for them to improve critical projects like ffmpeg, we'd have seen some patches that mattered already. The only activity I've seen is LLMs being used to farm sec-ops bounties which get rejected because of poor quality.

https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#50

Post by yieldcrv »

AaronAPU wrote: post #15

When I spent a decade doing SIMD optimizations for HEVC (among other things), it was sort of a joke to compare the assembly versions to plain c. Because you’d get some ridiculous multipliers like 100x. It is pretty misleading, what it really means is it was extremely inefficient to begin with. The devil is in the details, microbenchmarks are typically calling the same function a million times in a loop and everything…

> what it really means is it was extremely inefficient to begin with

I care more about the outcome than the underlying semantics, to me thats kind of a given

Post reply on HN