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

161–170 of 226 posts

Re: FFmpeg School of Assembly Language

#161

Post by saagarjha »

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…

There's still a lot of reasons to learn it to apply your skills, not just because you want to do it for fun. It's quite helpful when debugging, critical in fields like binary security or compilers, and basically the whole game if you're writing (say) SIMD algorithms.

Re: FFmpeg School of Assembly Language

#162

Post by saagarjha »

Inityx wrote: post #70
oguz-ismail wrote: post #47

Earlier quoted context omitted.

>C++ or Rust Nah. I find well commented three column AT&T assembly with light use of C preprocessor macros easier and more enjoyable to read.

Now that's what I call an unpopular opinion.

Among people who write assembly regularly it's not that unpopular

Re: FFmpeg School of Assembly Language

#163

Post by saagarjha »

epolanski wrote: post #26
imglorp wrote: post #18

Asm is 10x faster than C? That was definitely true at some point but is it still true today? Have compilers really stagnated so badly they can't come close to hand coded asm?

I remember a series of lectures from an Intel engineer that went into how difficult it was writing assembly code for x86. He basically stated that the number of cases you can really write code that is faster than what a compiler would do is close to none. Essentially people think they are writing low level code, in reality that's not how CPUs interpret that code, so he explained how writing manual assembly kills perf…

That's assembly by people who learned it in 1990. Intel very much does want you writing assembly for their processors and in many ways the only way to push them hard is by doing so.

Re: FFmpeg School of Assembly Language

#164

Post by saagarjha »

thayne wrote: post #147
PaulDavisThe1st wrote: post #52

Earlier quoted context omitted.

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…

ffmpeg has multiple implementations for each architecture to take advantage of microarchitectural wins.

Re: FFmpeg School of Assembly Language

#166

Post by Ecco »

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…

I guess your question could be rephrased as "couldn't we come up with better compilers?" (LLM-based or not, brute force based or not).

I don't have an answer but I believe that a lot of effort has been put in making (very smart) compilers already, so if it's even possible I doubt it's easy.

I also believe there are some cases where it's simply not possible for a compiler to beat handwritten assembly : indeed there is only so much info you can convey in a C program, and a developer who's aware of the whole program's behavior might be able to make extra assumptions (not written in the C code) and therefore beat a compiler. I'm sure people here would be able to come up with great practical examples of this.

Re: FFmpeg School of Assembly Language

#167

Post by buserror »

I used to do quite a bit of SIMD version of critical functions, but now I rarely do -- one thing to try is isolate that code, and run it in the Most Excellent Compiler Explorer [0].

And stare at the generated code!

More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide your own vector source/destination type -- you can do a lot by 'styling' your C code while thinking about what the compiler might be able to do with it -- for example, use extra intermediary variables, really break down all the operations you want etc.

Worst case if REALLY the compiler isn't clever enough, this give you a good base to adapt the generated assembly to tweak, without having to actually write the boilerplate bits.

In most case, the resulting C function will be vectorized as good, or better than the hand coded one I'd do -- and in many other cases, it's "close enough" not to matter that much. The other good news is that that code will probably vectorize fine for WASM and NEON etc without having to have explicit versions.

[0] https://godbolt.org/

Re: FFmpeg School of Assembly Language

#168

Post by MortyWaves »

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.

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

Re: FFmpeg School of Assembly Language

#169

Post by MortyWaves »

dundarious wrote: post #129
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…

What does Zig offer in the way of builtin SIMD support, beyond overloads for trivial arithmetic operations? 90% of the utility of SIMD is outside of those types of simple operations. I like Zig, but my understanding is you have to reach for CPU specific builtins for the vast majority of cases, just like in C/C++. GCC and Clang support the vector_size attribute and overloaded arithmetic operators on those "vectorized"…

I’m also wondering what “built in” even means. Many have SIMD, Vector, Matrix, Quaternions and the like as part of the standard library, but not necessarily as their own keywords. C#/.NET, Java has SIMD by this metric.

Re: FFmpeg School of Assembly Language

#170

Post by AnyTimeTraveler »

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 learned 8086 (not x86) assembly in a university course during my bachelors degree and won a contest to create the first correct implementation that would play "Jingle Bells" on the PC-Speaker[0] attached to the custom built computer. That was very fun and I kept playing around with assembly a bit afterwards, but never got around to learning any of the extensions made in x86 assembler and beyond.

In my masters degree, there was another course, where one built their own computer PCB in Eagle, got it fabbed and then had to make a game for the 8052 CPU on there. 8052 assembly is very fun! The processor has a few bytes of ram where every bit is individually addressable and testable. I built the game Tetris on three attached persistence of vision LED-Matrices[1]. Unfortunately, the repository isn't very clean, but I used expressive variable names, so it should be readable. I did create my own calling convention for performance reasons and calculated how many cpu cycles were available for game logic between screen refreshes. Those were all very fun things to think about :)

Reading assembly now has me look up instruction names here and there, but mostly I can understand what's going on.

[0] https://github.com/AnyTimeTraveler/HardwareNaheProgrammierun... [1] https://github.com/AnyTimeTraveler/HardwarenaheSystementwick...

Post reply on HN