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

FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

tomshardware.com

Post reply on HN
Print view View original

61–70 of 138 posts

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#61

Post by dragontamer »

saagarjha wrote: post #54
dragontamer wrote: post #25

Earlier quoted context omitted.

All instructions are implemented with logic gates. In fact. All instructions today are likely NAND gates. Have you ever seen a WallaceTree multiplier? A good sequence that shows how XOR and AND gates can implement multiply. Now, if multiply + XOR gets the new function you want, it's likely better than whatever the original compiler output.

Computers are not programmed on the level of logic gates. If you want to do that, design an FPGA.

Superoptimizers take this stuff into consideration.

Which is what the parent post was talking about, the rare superoptimizer.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#62

Post by MobiusHorizons »

tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

Almost all performance critical pieces of c/c++ libraries (including things as seemingly mundane as strlen) use specialized hand written assembly. Compilers are good enough for most people most of the time, but that’s only because most people aren’t writing software that is worth optimizing to this level from a financial perspective.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#63

Post by cpncrunch »

brigade wrote: post #60
cpncrunch wrote: post #38

Article is unclear what will actually be affected. It mentions "rangedetect8_avx512" and calls it an obscure function. So, what situations is it actually used for, and what is the real-time improvement in performance for the entire conversion process?

It's not conversion. Rather, this filter is used for video where you don't know whether the pixels are video or full range, or whether the alpha is premultiplied, and determining that information. Usually so you can tag it correctly in metadata. And the function in question is specifically for the color range part.

It's still unclear from your explanation how it's actually used in practice. I run thousands of ffmpeg conversions every day, so it would be useful to know how/if this is likely to help me.

Are you saying that it's run once during a conversion as part of the process? Or that it's a specific flag that you give, it then runs this function, and returns output on the console?

(Either of those would be a one-time affair, so would likely result in close to zero speed improvement in the real world).

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#64

Post by brigade »

cpncrunch wrote: post #63
brigade wrote: post #60

Earlier quoted context omitted.

It's not conversion. Rather, this filter is used for video where you don't know whether the pixels are video or full range, or whether the alpha is premultiplied, and determining that information. Usually so you can tag it correctly in metadata. And the function in question is specifically for the color range part.

It's still unclear from your explanation how it's actually used in practice. I run thousands of ffmpeg conversions every day, so it would be useful to know how/if this is likely to help me. Are you saying that it's run once during a conversion as part of the process? Or that it's a specific flag that you give, it then runs this function, and returns output on the console? (Either of those would be a one-time affair,…

This is a new filter that hasn’t even been committed yet, it only runs if explicitly specified, and would only ever be specified by someone that already knows that they don’t know the characteristics of their video.

So you wouldn’t ever run this.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#65

Post by saati »

brigade wrote: post #57
tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

It's AVX512 that makes the gains, not assembly. This kernel is simple enough that it wouldn't be measurably faster than C with AVX512 intrinsics. And it's 100x because a) min/max have single instructions in SIMD vs cmp+cmov in scalar and b) it's operating in u8 precision so each AVX512 instruction does 64x min/max. So unlike the unoptimized scalar that has a throughput under 1 byte per cycle, the AVX512 version can s…

The AVX2 version was still 64x faster than the C one, so AVX-512 is just 50% improvement over that. Hand vectorized assembly is very much the key to the gains.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#67

Post by jesse__ »

tombert wrote: post #37

Actually a bit surprised to hear that assembly is faster than optimized C. I figured that compilers are so good nowadays that any gains from hand-written assembly would be infinitesimal. Clearly I'm wrong on this; I should probably properly learn assembly at some point...

It's extremely easy to beat the compiler by dropping down to SIMD intrinsics. I recently wrote a 4 part .. guide? ..

https://scallywag.software/vim/blog/simd-perlin-noise-i

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#68

Post by jesse__ »

capyba wrote: post #58
torginus wrote: post #23

Earlier quoted context omitted.

Sorry for the derail, but it sounds like you have a ton of experience with SIMD. Have you used ISPC, and what are your thoughts on it? I feel it's a bit ridiculous that in this day and age you have to write SIMD code by hand, as regular compilers suck at auto-vectorizing, especially as this has never been the case with GPU kernels.

Personally I’ve never been able to beat gcc or icx autovectorization by using intrinsics; often I’m slower by a factor of 1.5-2x. Do you have any wisdom you can share about techniques or references you can point to?

I recently finished a 4 part series about vectorizing perlin noise.. from the very basics up to beating the state-of-the-art by 1.8x

https://scallywag.software/vim/blog/simd-perlin-noise-i

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#69

Post by CyberDildonics »

almostgotcaught wrote: post #55
torginus wrote: post #23

Earlier quoted context omitted.

Sorry for the derail, but it sounds like you have a ton of experience with SIMD. Have you used ISPC, and what are your thoughts on it? I feel it's a bit ridiculous that in this day and age you have to write SIMD code by hand, as regular compilers suck at auto-vectorizing, especially as this has never been the case with GPU kernels.

> Have you used ISPC No professional kernel writer uses Auto-vectorization. > I feel it's a bit ridiculous that in this day and age you have to write SIMD code by hand You feel it's ridiculous because you've been sold a myth/lie (abstraction). In reality the details have always mattered.

ISPC is a lot different from C++ compiler auto vectorization and it works extremely well. Have you tried it or not? If so where does it actually fall down? It warns you when doing slow stuff like gathers and scatters.

Re: FFmpeg devs boast of another 100x leap thanks to handwritten assembly code

#70

Post by brigade »

saati wrote: post #65
brigade wrote: post #57

Earlier quoted context omitted.

It's AVX512 that makes the gains, not assembly. This kernel is simple enough that it wouldn't be measurably faster than C with AVX512 intrinsics. And it's 100x because a) min/max have single instructions in SIMD vs cmp+cmov in scalar and b) it's operating in u8 precision so each AVX512 instruction does 64x min/max. So unlike the unoptimized scalar that has a throughput under 1 byte per cycle, the AVX512 version can s…

The AVX2 version was still 64x faster than the C one, so AVX-512 is just 50% improvement over that. Hand vectorized assembly is very much the key to the gains.

The only material difference AVX2 makes is that it can't saturate L1 bandwidth. Which would imply that 100x for AVX-512 is only for frames that fit within L1.

And... yep, the benchmark on 256x16 frames. [1]

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/346729.h...

Post reply on HN