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

FFmpeg School of Assembly Language

github.com

Post reply on HN
Print view View original

141–150 of 226 posts

Re: FFmpeg School of Assembly Language

#141

Post by magicalhippo »

qingcharles wrote: post #126
kierank wrote: post #117

I am the author of these lessons. Ask me anything.

As someone who wrote x86 optimization code professionally in the 90s, do we need to do this manually still in 2025? Can we not just write tests and have some LLM try 10,000 different algorithms and profile the results? Or is an LLM unlikely to find the optimal solution even with 10,000 random seeds? Just asking. Optimizing x86 by hand isn't the easiest, because to think through it you start to have to try and fit all…

While using a LLM might not be the best approach, it would be interesting to know if there are some tools these days that can automate this.

Like, I should be able to give the compiler a hot loop and a week, and see what it can come up with.

One potential pitfall I can see is that there are a lot of non-local interactions in moderns systems. We have large out-of-order buffers, many caching layers, complex branch predictors, and an OS running other tasks at the same time, and a dozen other things.

What is optimal on paper might not be optimal in the real world.

Re: FFmpeg School of Assembly Language

#142

Post by sweeter »

foresto wrote: post #140
sweeter wrote: post #103

Earlier quoted context omitted.

Wouldn't it return the size of the pointer? I would guess it's exclusively used to handle architecture differences

Strictly speaking, or maybe just the way I personally think of it, sizeof doesn't return anything. It's not a function, so it doesn't return at all. (At least, not at run time.) Nitpicking aside, the result of sizeof(*src) would be the size of the object at which the pointer points. The type of that result is size_t. That's what makes this code from the lesson I quoted invalid: *sizeof(*src) That first asterisk tries…

Yea but that first asterisk is incorrect

Re: FFmpeg School of Assembly Language

#143

Post by magicalhippo »

CyberDildonics wrote: post #74
jsheard wrote: post #25

Earlier quoted context omitted.

C with intrinsics can get very close to straight assembly performance. The FFmpeg devs are somewhat infamously against intrinsics (IIRC they don't allow them in their codebase even if the performance is as good as equivalent assembly) but even by TFAs own estimates the difference between intrinsics and assembly is on the order of 10-15%. You might see a 10x difference if you compare meticulously optimized assembly to…

You might see a 10x difference if you compare meticulously optimized assembly to naive C in cases where vectorization is possible but the compiler fails to capitalize on that, I can get far more than 10x over naive C just by reordering memory accesses. With SIMD it can be 7x more, but that can be done with ISPC, it doesn't need to be done with asm.

> I can get far more than 10x over naive C

However you can write better than naive C by compiling and watching the compiler output.

I stopped writing assembly back around y2k as I was fairly consistently getting beaten by the compiler when I wrote compiler-friendly high-level code. Memory organization is also something you can control fairly well on the high-level code side too.

Sure some niches remained, but for my projects the gains were very modest compared to invested time.

Re: FFmpeg School of Assembly Language

#144

Post by anta40 »

Daniel_Van_Zant wrote: post #50

I'm curious from anyone who has done it. Is there any "pleasure" to be had in learning or implementing assembly (like there is for LISP or RISC-V) or is it something you learn and implement because you want to do something else (like learning COBOL if you need to work with certain kinds of systems). It has always piqued my interest but I don't have a good reason in my day-to-day job to get into it. Wondering if it is…

I do it purely for fun: learning NES/Sega/GBA coding, hopefully being able to write simple games one day.

When lockdown started in 2020, I thought working from home would give me more spare time, thus enrolled those classes on Udemy.

I'm a mobile app dev (Java/Kotlin), and assembly is practically irrelevant for daily use cases.

Re: FFmpeg School of Assembly Language

#145

Post by filleduchaos »

mvdtnz wrote: post #127
beebaween wrote: post #124

I'm kind of stunned we haven't gotten something better / more rust based than ffmpeg? Especially curious given the advent of apple metal etc. Does anyone have recommendations?

"Rust based" is not a feature. End users DO NOT CARE. What's your value prop?

Gstreamer is increasingly developed in Rust, and is a far saner, better documented and more flexible framework for developers than libav/ffmpeg.

The pipeline/plugin based architecture is pretty neat even as an end user, I find it a lot more discoverable.

Re: FFmpeg School of Assembly Language

#146

Post by foresto »

sweeter wrote: post #142
foresto wrote: post #140

Earlier quoted context omitted.

Strictly speaking, or maybe just the way I personally think of it, sizeof doesn't return anything. It's not a function, so it doesn't return at all. (At least, not at run time.) Nitpicking aside, the result of sizeof(*src) would be the size of the object at which the pointer points. The type of that result is size_t. That's what makes this code from the lesson I quoted invalid: *sizeof(*src) That first asterisk tries…

Yea but that first asterisk is incorrect

Is there an echo in here? ;)

Re: FFmpeg School of Assembly Language

#147

Post by thayne »

PaulDavisThe1st wrote: post #52
thayne wrote: post #34

It doesn't mention the downsides of using assembly. The biggest of which is that your code is architecture specific, so for example you have to write different code for x86 and arm, and possibly even different code for x86_64. Unfortunately, for SIMD, there isn't really a great way to write portable code for it, at least in C. Rust is working on stabilizing a portable simd API, and zig has simd support, but I suspect…

I can't speak for ffmpeg, but I can report on why we use non-portable assembler inside Ardour (a x-platform digital audio workstation). Ardour's own code doesn't do very much DSP (it's a policy choice), but one thing that our own code does do is metering: comparing a current sample value to every previous sample value in a given audio data stream within a given time window to decide if it is higher (or lower) than th…

I'm not at all saying that it isn't worth it for ffmpeg to use assembly, but there is a tradeoff there. Ffmpeg either needs to either only support a limited number of architectures, and duplicate code for all of them, have asm implementations for the most popular architectures (probably x86(_64) and arm), and a slower, arch independent fallback implementation in c for the rest, or have asm implementations in a large number of ISAs. I'm guessing ffmpeg does the middle option, especially since this guide focuses on x86 assembly, but ffmpeg supports many other architectures.

The performance wins may very well be worth it, but it is still good to be aware of the tradeoff involved.

Re: FFmpeg School of Assembly Language

#148

Post by booi »

qingcharles wrote: post #128
cnt-dracula wrote: post #120

Earlier quoted context omitted.

Hi, thanks for your work! I have a question, as someone who can just about read assembly but still do not intuitively understand how to write or decompose ideas to utilise assembly, do you have any suggestions to learn / improve this? As in, at what point would someone realise this thing can be sped up by using assembly? If one found a function that would be really performant in assembly how do you go about writing i…

You're looking for the tiniest blocks of code that are run an exceptional number of times. For instance, I used to work on graphics renderers. You'd find the bit that was called the most (writing lines of pixels to the screen) and try to jiggle the order of the instructions to decrease the number of cycles used to move X bits from system RAM to graphics RAM. When I was doing it, branching (usually checking an exit co…

Don’t modern or even just not ancient cpus use branch prediction to work past a check knowing that the vast majority of the time the check yields the same result?

Re: FFmpeg School of Assembly Language

#149

Post by cornstalks »

computerbuster wrote: post #85

Another resource on the same topic: https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-... As I'm seeing in the comments here, the usefulness of handwritten SIMD ranges from "totally unclear" to "mission critical". I'm seeing a lot on the "totally unclear" side, but not as much on the "mission critical", so I'll talk a bit about that. FFmpeg is a pretty clear use case because of how often it is used, but I t…

One of the fun things about dav1d is that since it’s written in assembly, they can use their own calling convention. And it can differ from method to method, so they have very few stack stores and loads compared to what a compiler will generate following normal platform calling conventions.

Re: FFmpeg School of Assembly Language

#150

Post by ilyagr »

kierank wrote: post #117

I am the author of these lessons. Ask me anything.

As a user of an ARM Mac, I wonder: how much effort does it take to get such optimized code to work the same in all platforms? I guess you must have very thorough tests and fallback algorithms?

If it's so heavy in assembly, the fact that ffmpeg works on my Mac seems like a miracle. Is it ported by hand?

Post reply on HN