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

21–30 of 138 posts

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

#21

Post by viraptor »

smj-edison wrote: post #17
askvictor wrote: post #3

[flagged]

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.

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

#22

Post by ErrorNoBrain »

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?

[flagged]

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

#23

Post by torginus »

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…

Sorry for the derail, but it sounds like you have a ton of experience with SIMD.

Have you used ISPC, and what are your thoughts on it?

I feel it's a bit ridiculous that in this day and age you have to write SIMD code by hand, as regular compilers suck at auto-vectorizing, especially as this has never been the case with GPU kernels.

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

#24

Post by gametorch »

LtWorf wrote: post #7
askvictor wrote: post #3

[flagged]

> I wonder how many optimisations like this could be created by LLMs Zero. There's no huge corpus of stackoverflow questions on highly specific assembly optimisations so…

There are literally textbooks on optimization. With tons of examples. I'm sure there are models out there trained on them.

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

#25

Post by dragontamer »

agent327 wrote: post #20
dragontamer wrote: post #16

Earlier quoted context omitted.

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…

A short look at any compiled code on godbolt will very quickly inform you that pretty much all instructions at the assembly level are, in fact, NOT sequences of AND/OR/XOR operations.

All instructions are implemented with logic gates. In fact. All instructions today are likely NAND gates.

Have you ever seen a WallaceTree multiplier? A good sequence that shows how XOR and AND gates can implement multiply.

Now, if multiply + XOR gets the new function you want, it's likely better than whatever the original compiler output.

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

#26

Post by viraptor »

agent327 wrote: post #20
dragontamer wrote: post #16

Earlier quoted context omitted.

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…

A short look at any compiled code on godbolt will very quickly inform you that pretty much all instructions at the assembly level are, in fact, NOT sequences of AND/OR/XOR operations.

You're missing the point. All instructions can be simplified to short integer operations, then all integer operations are just networks of gates, then all gates can be replaced with AND/OR/NOT, or even just NAND. That's why you can SAT solve program equivalence. See SMT2 programs using BV theory for example.

Also of course all instructions are MOV anyway. https://github.com/xoreaxeaxeax/movfuscator

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

#27

Post by Arubis »

askvictor wrote: post #3

[flagged]

This intrinsically feels like the opposite of a good use case for an LLM for code gen. This isn’t boilerplate code by any means, nor would established common patterns be helpful. A lot of what ffmpeg devs are doing at the assembly level is downright novel.

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

#28

Post by pizlonator »

viraptor wrote: post #8
pizlonator wrote: post #6

Earlier quoted context omitted.

The hardest part of optimizations like this is verifying that they are correct. We don’t have a reliable general purpose was of verifying if any code transformation is correct. LLMs definitely can’t do this (they will lie and say that something is correct even if it isn’t).

But we do! For llvm there's https://github.com/AliveToolkit/alive2 There are papers like https://people.cs.rutgers.edu/~sn349/papers/cgo19-casmverify... There's https://github.com/google/souper There's https://cr.yp.to/papers/symexemu-20250505.pdf And probably other things I'm not aware of. If you're limiting the scope to a few blocks at a time, symbolic execution will do fine.

> limiting the scope to a few blocks

Yeah so like that doesn’t scale.

The interesting optimizations involve reasoning across thousands of blocks

And my point is there is no reliable general purpose solution here. „Only works for a few blocks at a time” is not reliable. It’s not general purpose

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

#30

Post by ethan_smith »

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?

It's definitely 100x (or 100.73x) as shown in the screenshot, which represents a 9973% speedup - the article text incorrectly uses percentage notation in some places.
Post reply on HN