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

191–200 of 226 posts

Re: FFmpeg School of Assembly Language

#191

Post by Ono-Sendai »

thegrim33 wrote: post #133
imchaz wrote: post #131

I'll be honest, I didn't read through much. Ffmpeg gives me severe ptsd. My first task out of college was to write a procedurally generated video using ffmpeg, conform to dash, and get it under 150kb/s while being readable. Docs were unusable. Dash was only a few months old. And stackoverflow was devoid of help. I kid you not, the only way to get any insight was some sketchy IRC channel. (2016 btw, well past IRCs pri…

Not trying to be too negative but the memories your comment brought up in me, I need to rant about ffmpeg for a minute. ffmpeg is the worst documented major library I've ever used in my life. I integrated with it to render videos inside my 3D engine and boy do I shiver at any thought of having to work with it again. The "documentation" is a collect of 15-20 year old source samples. The vast majority of them either wo…

that's hilarious, thank you. The life of a c++ programmer using dodgy libraries.

Re: FFmpeg School of Assembly Language

#192

Post by screcth »

astrange wrote: post #111
PaulDavisThe1st wrote: post #54

Earlier quoted context omitted.

> codecs are not really normal code. Not really a fair comment. They are entirely normal code in most senses. They differ in one important way: they are (frequently) perfect examples of where "single instruction, multiple data" completely makes sense. "Do this to every sample" is the order of the day, and that is a bit odd when compared with text processing or numerical computation. But this is true of the majority o…

There's a difference because audio processing is often "massively parallel", or at least like 1024 samples at once, but in video codecs operations could be only 4 pixels at once and you have to stretch to find extra things to feed the SIMD operations.

Can you use the remaining SIMD lanes for processing independent data streams?

Think encoding or decoding non-overlapping parts of a video.

Re: FFmpeg School of Assembly Language

#193

Post by janwas »

cornstalks wrote: post #149
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.

I'm curious why there are even function calls in time-critical code, shouldn't just about everything be inlined there? And if it's not time-critical, why are we interested in the savings from a custom calling convention?

Re: FFmpeg School of Assembly Language

#194

Post by janwas »

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…

I'm also in the mission-critical camp, with perhaps an interesting counterpoint. If we're focusing on small details (or drowning in incidental complexity), it can be harder to see algorithmic optimizations. Or the friction of changing huge amounts of per-platform code can prevent us from escaping a local minimum.

Example: our new matmul outperforms a well-known library for LLM inference, sometimes even if it uses AMX vs our AVX512BF16. Why? They seem to have some threading bottleneck, or maybe it's something else; hard to tell with a JIT involved.

This would not have happened if I had to write per-platform kernels. There are only so many hours in the day. Writing a single implementation using Highway enabled exploring more of the design space, including a new kernel type and an autotuner able to pick not only block sizes, but also parallelization strategies and their parameters.

Perhaps in a second step, one can then hand-tune some parts, but I sure hope a broader exploration precedes micro-optimizing register allocation and calling conventions.

Re: FFmpeg School of Assembly Language

#195

Post by warble »

School-Cotton wrote: post #87
warble wrote: post #23

Earlier quoted context omitted.

I highly doubt it's true. I can usually approach the same speed in C if I'm working with a familiar compiler. Sometimes I can do significantly better in assembly but it's rare. I work on bare metal embedded systems though, so maybe there's some nuance when working with bigger OS libs?

The difference is probably that you don’t work in an environment that supports SIMD or your code can’t benefit from it.

You're correct, I don't use SIMD instructions much, but I can, and with a C compiler. So still, not sure the advantage of ASM.

Re: FFmpeg School of Assembly Language

#196

Post by janwas »

HALtheWise wrote: post #135
kierank wrote: post #117

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

What's your perspective on variable-width SIMD instruction sets (like ARM SVE or the RISC-V V extension)? How does developer ergonomics and code performance compare to traditional SIMD? Are we approaching a world with fewer different SIMD instruction sets to program for?

Var-width SIMD can mostly be written using the exact same Highway code, we just have to be careful to avoid things like arrays of vectors and sizeof(vector).

It can be more complicated to write things which are vector-length dependent, such as sorting networks or transposes, but we have always found a way so far.

On the contrary, there are increasing numbers of ISAs, including the two LoongArch LSX/LASX, AVX-512 which is really really good on Zen5, and three versions of Arm SVE. RISC-V V also has lots of variants and extensions. In such a world, I would not want to have to implement per-platform implementations.

Re: FFmpeg School of Assembly Language

#197

Post by janwas »

danybittel wrote: post #152
qingcharles wrote: post #126

Earlier quoted context omitted.

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…

What you're looking for is https://en.wikipedia.org/wiki/Superoptimization .

Collaborators have actually superoptimized some of the more complicated Highway ops on RISC-V, with interesting gains, but I think the approach would struggle with largish tasks/algorithms?

Re: FFmpeg School of Assembly Language

#198

Post by janwas »

astrange wrote: post #110
schainks wrote: post #38

Earlier quoted context omitted.

Did you read lesson one? TL;DR They want to squeeze every drop of performance out of the CPU when processing media, and maintaining a mixture of intrinsics code and assembly is not worth the trade off when doing 100% assembly offers better performance guarantees, readability, and ease of maintenance / onboarding of developers.

Intrinsics have the disadvantages of asm (non-portable) but also don't reliably have the advantages of them (compilers are pretty unpredictable about optimizing with them) and they're ugly (especially x86 with its weird Hungarian stuff). There is just a little bit of intrinsics code in ffmpeg, which I wrote, that does memory copies. https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/i... It's like this becaus…

Intrinsics have the huge advantage of enabling wrapper functions, which remove the ugly names and allow you to write user code only once, such that it is even portable (or at least multiplatform-dependent).

Good point about asan and other instrumentation :) hm, I'd think that is very important for codecs in particular?

Re: FFmpeg School of Assembly Language

#199

Post by wolf550e »

MortyWaves wrote: post #168
cornstalks wrote: post #149

Earlier quoted context omitted.

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.

Doesn’t this just make it harder to maintain ports to other architectures though?

There indeed have been bugs caused by amd64 assembly code assuming unix calling convention being used for Windows builds and causing data corruption. You have to be careful.

Re: FFmpeg School of Assembly Language

#200

Post by hrydgard »

janwas wrote: post #193
cornstalks wrote: post #149

Earlier quoted context omitted.

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.

I'm curious why there are even function calls in time-critical code, shouldn't just about everything be inlined there? And if it's not time-critical, why are we interested in the savings from a custom calling convention?

Function calls are very fast (unless there's really a lot of parameter copying/saving-to-stack) and if you can re-use a chunk of code from multiple places, you'll reduce pressure on the instruction cache. Inlining is not always ideal.
Post reply on HN