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

41–50 of 226 posts

Re: FFmpeg School of Assembly Language

#41

Post by arkj »

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…

If you look at this from a top-down perspective, you’ll see downsides, but from a bottom-up view, those same differences can be an advantage. Different architectures have different capabilities, and writing assembly means you’re optimizing for performance rather than prioritizing code portability or maintenance.

Re: FFmpeg School of Assembly Language

#43

Post by bob1029 »

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?

This gets even more complex once you start looking at dynamic compilations. Some of the JIT compilers have the ability to hot patch functions based upon runtime statistics. In very large, enterprisey applications with unknowns regarding how they will actually be used at build time, this can make a difference.

You can go nuclear option with your static compilations and turn on all the optimizations everywhere, but this kills inner loop iteration speed. I believe there are aspects of some dynamic compiling runtimes that can make them superior to static compilations - even if we don't care how long the build takes.

Re: FFmpeg School of Assembly Language

#45

Post by Narishma »

UltraSane wrote: post #33
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…

"The FFmpeg devs are somewhat infamously against intrinsics (they don't allow them in their codebase even if the performance is as good as equivalent assembly)" Why?

I don't know if it's their reason but I myself avoid them because I find them harder to read than assembly language.

Re: FFmpeg School of Assembly Language

#46

Post by variadix »

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?

C compilers are still pretty bad at auto vectorization. For problems where SIMD is applicable, you can reasonably expect a 2x-16x speed up over the naive scalar implementation.

Re: FFmpeg School of Assembly Language

#47

Post by oguz-ismail »

jsheard wrote: post #39
oguz-ismail wrote: post #35

Earlier quoted context omitted.

Have you seen C code with SIMD intrinsics? They are an eyesore

You're not wrong but that's more of an issue with C than an issue with intrinsics, in higher level languages like C++ or Rust you have the option to wrap instrinsics in types which are much nicer to work with.

>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.

Re: FFmpeg School of Assembly Language

#48

Post by hereonout2 »

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…

Possibly they could have added that warning, but at the same time this is a guide from the ffmpeg project, presumably for ffmpeg developers.

They lay it out quite clearly I think, but things like libavcodec are probably one of the few types of project where the benefits of assembly outweigh the lack of portability.

I'm not sure rust or zig's support for SIMD would be the project's first complaint either. Likely more concerned with porting a 25 year old codebase to a new language first.

Re: FFmpeg School of Assembly Language

#49

Post by graypegg »

mkoubaa wrote: post #42

I'm shocked there still isn't a hardware accelerator for video decoding.

There is! FFmpeg supports hardware acceleration for a lot of operations. (Though format/codec dependant on the chipset you're working with, so it's not as general as you might expect. I don't know a ton about video's guts, so I assume the variance between video codec decoding is big enough to require incompatible special silicon.)

https://trac.ffmpeg.org/wiki/HWAccelIntro

Re: FFmpeg School of Assembly Language

#50

Post by Daniel_Van_Zant »

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 worth committing some time to for the fun of it.
Post reply on HN