FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
1–10 of 138 posts
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#2Still waiting for Pipewire + xdg desktop portal screen / window capture support in ffmpeg CLI. It's been dragging feet forever with it.
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#3[flagged]
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#4The 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?
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#5The 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
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#6[flagged]
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).
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#7[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…
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#8[flagged]
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.
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#9The 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?
100x to the single function 100% (2x) to the whole filter
Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code
#10[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…
You can run an agent in a loop, but for something this small you can already use a SAT solver or superoptimizer if you want to get out of the business of thinking about things yourself.
I've never seen anyone actually do it, mostly because modeling the problem is more work than just doing it.