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

31–40 of 226 posts

Re: FFmpeg School of Assembly Language

#31

Post by sylware »

ryanianian wrote: post #28
sylware wrote: post #27

A gigantic mistake was done in much of ffmpeg assembly: They are abusing nasm macro-preprocessor up to obscene levels...

Why is it "abusing," and what would you suggest as an alternative?

Have a look an their code, it is obvious. Often you have to figure out what actually the macros does, and I remember it was not that straight forward.

And the macro language is specific to nasm.

What to do: unroll the macros and/or use a little abstraction using a simple common macro preprocessor, aka not tied to the assembler.

And I am just doing exactly that: my x86_64 assembly code does assemble with fasm/nasm/gas with a little abstraction using a C preprocessor.

Re: FFmpeg School of Assembly Language

#32

Post by pengaru »

sylware wrote: post #31
ryanianian wrote: post #28

Earlier quoted context omitted.

Why is it "abusing," and what would you suggest as an alternative?

Have a look an their code, it is obvious. Often you have to figure out what actually the macros does, and I remember it was not that straight forward. And the macro language is specific to nasm. What to do: unroll the macros and/or use a little abstraction using a simple common macro preprocessor, aka not tied to the assembler. And I am just doing exactly that: my x86_64 assembly code does assemble with fasm/nasm/gas…

there is nothing wrong with depending on nasm

Re: FFmpeg School of Assembly Language

#33

Post by UltraSane »

jsheard wrote: post #25
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 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?

Re: FFmpeg School of Assembly Language

#34

Post by thayne »

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 ffmpeg would still complain they aren't quite as fast as they would like.

One thing that confuses me is the opposition to inline asm. It seems like inline asm would be more efficient than having to make a function call to an asm function.

Re: FFmpeg School of Assembly Language

#35

Post by oguz-ismail »

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?

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

Re: FFmpeg School of Assembly Language

#36

Post by PhilipRoman »

sylware wrote: post #31
ryanianian wrote: post #28

Earlier quoted context omitted.

Why is it "abusing," and what would you suggest as an alternative?

Have a look an their code, it is obvious. Often you have to figure out what actually the macros does, and I remember it was not that straight forward. And the macro language is specific to nasm. What to do: unroll the macros and/or use a little abstraction using a simple common macro preprocessor, aka not tied to the assembler. And I am just doing exactly that: my x86_64 assembly code does assemble with fasm/nasm/gas…

To be fair, nasm allows you to detach the preprocessor from the assembler (-E). But I agree with you in general.

Re: FFmpeg School of Assembly Language

#38

Post by schainks »

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?

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.

Re: FFmpeg School of Assembly Language

#39

Post by jsheard »

oguz-ismail wrote: post #35
UltraSane wrote: post #33

Earlier quoted context omitted.

"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?

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.

Re: FFmpeg School of Assembly Language

#40

Post by iforgotpassword »

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 for random "I know asm so it must be faster".

If you know it really well, have already optimized everything on an algorithmic level and have code that can benefit from simd, 10x is real.

Post reply on HN