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

151–160 of 226 posts

Re: FFmpeg School of Assembly Language

#151

Post by renhanxue »

adgjlsfhk1 wrote: post #73
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…

The counterpoint to this is that if you can write AVX2 assembly, that will be supported on ~99% of x86 CPUs around today (Haswell was 2013), so just that one branch covers ~80% of the desktop/laptop market.

If you really care about performance though you'd want to be a lot more specific than this. I've seen image processing code that not only does things like avoid specific instructions on some CPU families (like for example it avoids the vpermd instruction on Zen1/2/3 CPU's because of excessive latency), but also queries the CPU cache topology at runtime and uses buffer allocation strategies that ensure that it can work in data batches that fit in cache.

Re: FFmpeg School of Assembly Language

#152

Post by danybittel »

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…

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

Re: FFmpeg School of Assembly Language

#154

Post by [deleted] »

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…

[deleted]

Re: FFmpeg School of Assembly Language

#155

Post by TinkersW »

frontfor wrote: post #139
jupp0r wrote: post #62

I personally don't think there's much value in writing assembly (vs using intrinsics), but it's been really helpful to read it. I have often used Compiler Explorer ( https://godbolt.org/ ) to look at the assembly generated and understand optimizations that compilers perform when optimizing for performance.

Your commented is directly contradicted by the article. > To make multimedia processing fast. It’s very common to get a 10x or more speed improvement from writing assembly code, which is especially important when wanting to play videos in real time without stuttering.

They said they prefer intrinsics which the article says are only about 10% slower(citation needed), you misunderstood and made a comparison against scalar.

Personally I'd say the only good reason to use assembly over intrinsics is having control over calling convention, for example the windows CC is absolute trash and wastes many SIMD registers.

Re: FFmpeg School of Assembly Language

#156

Post by renox »

brown wrote: post #60
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…

Learning assembly was profound for me, not because I've used it (I haven't in 30 years of coding), but because it completed the picture - from transistors to logic gates to CPU architecture to high-level programming. That moment when you understand how it all fits together is worth the effort, even if you never write assembly professionally.

While I think that learning assembly is very useful, I think that one must be careful at applying assembly language concepts in a HLL C/X++/Zig..

For example, an HLL pointer is different from an assembly pointer(1). Sure the HLL pointer will be lowered to an assembly language pointer eventually but it still has a different semantic.

1: because you're relying on the compiler to use efficiently the registers, HLL pointers must be restricted otherwise programs would be awfully slow as soon as you'd use one pointer.

Re: FFmpeg School of Assembly Language

#157

Post by TinkersW »

astrange wrote: post #115
School-Cotton wrote: post #90

Earlier quoted context omitted.

SIMD doesn’t operate on a separate memory space or anything like that. You just load data from normal memory into the SIMD registers, just like you would have to load it into the scalar registers if you wanted to operate on it with normal instructions.

It is slow to move data from SIMD to scalar registers, or can be.

It depends, for SIMD float-> scalar floats it is fast as they operate on the same registers. If pulling out of lane 0 you don't even need to do anything(just a type cast). For other lanes you need a shuffle.

For SIMD integer to scalar integer, it has to move into separate register, so there is some short penalty(3 cycles iir).

Re: FFmpeg School of Assembly Language

#158

Post by saagarjha »

ilyagr wrote: post #150
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?

While the instructions are different, every platform will have some implementation of the basic operations (load, store, broadcast, etc.), perhaps with a different bit width. With those you can write an accelerated baseline implementation, typically (sometimes these are autogenerated/use some sort of portable intrinsics, but usually they don't). If you want to go past that then things get more complicated and you will have specialized algorithms for what is available.

Re: FFmpeg School of Assembly Language

#159

Post by kaslai »

booi wrote: post #148
qingcharles wrote: post #128

Earlier quoted context omitted.

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?

All the little tricks that the CPU has to speed things up, like branch prediction, out of order execution, parallel branch execution, etc, are mostly more expensive than just not having to rely on them in the first place. Branch prediction in particular is not something that should be relied on too heavily either, since it is actually quite a fragile optimization that can cause relatively large performance swings with seemingly meaningless changes to the code.

Re: FFmpeg School of Assembly Language

#160

Post by saagarjha »

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…

You would need to be very careful about verifying the output. Having an LLM generate patterns and then running them through a SAT solver might work, but usually it's only really feasible for short sequences of code.
Post reply on HN