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

101–110 of 226 posts

Re: FFmpeg School of Assembly Language

#101

Post by sweeter »

PaulDavisThe1st wrote: post #52
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…

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…

Ardour is a great piece of software! Thanks for that. I love hearing experiences like these.

Re: FFmpeg School of Assembly Language

#102

Post by sigbottle »

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…

If you're working with C++ (and I'd imagine C), knowing how to debug the assembly comes up. And if you've written assembly it helps to be aware of basic patterns such as loops, variables, etc. to not get completely lost.

Compilers have debug symbols, you can tune optimization levels, etc. so it's hopefully not too scary of a mess once you objdump it, but I've seen people both use their assembly knowledge at work and get rewarded handsomely for it.

Re: FFmpeg School of Assembly Language

#103

Post by sweeter »

foresto wrote: post #76

> Note that the “q” suffix refers to the size of the pointer *(*i.e in C it represents *sizeof(*src) == 8 on 64-bit systems, and x86asm is smart enough to use 32-bit on 32-bit systems) but the underlying load is 128-bit. I find that sentence confusing. I assume that i.e is supposed to be i.e., but What is *(* supposed to mean? Shouldn't that be just an open parenthesis? In what context would *sizeof(*src) be consider…

Wouldn't it return the size of the pointer? I would guess it's exclusively used to handle architecture differences

Re: FFmpeg School of Assembly Language

#104

Post by ajross »

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?

No, that claim is ridiculous. When doing the same task, quite frankly, compilers are much better than any human at optimizing general logic.

But when the human and compiler are not faced with the same problem...

Say, if your compiler doesn't support autovectorization and/or your C code isn't friendly to the idiom, then sure: a 10x difference in performance between a hand-optimized SIMD implementation and a naive scalar one fed to a C compiler is probably about right.

Re: FFmpeg School of Assembly Language

#106

Post by dinkumthinkum »

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 mean, some people are interested in computers. Some people are interested in performance. Some people like to understand how the things they work with and use on a regular basis work at a very fundamental level; it's not like understanding assembly is like trying to understand computing via physics, it is directly a part of the process. I think there was a time when many people found it exciting to learn, still there are some, but now there are so many non-technical programmers working in the field, making web pages, etc., that it is a minority percentage compared earlier times.

Re: FFmpeg School of Assembly Language

#107

Post by jwr »

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…

Yes, it is definitely worth it. You get a much better understanding of CPU architectures. Also, most of your knowledge will be applicable to any platform.

Re: FFmpeg School of Assembly Language

#108

Post by jsheard »

aidenn0 wrote: post #95
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…

I don't know what is state of the art today, but historically compilers are terribly inefficient for inline assembly because they inhibit optimizations around inline assembly, so inline asm is often slower than intrinsics. For DSP code, your performance critical code is often a large number of iterations through a hot loop, so the function-call overhead incurred by calling your assembly function is negligible.

MSVC doesn't even support inline assembly anymore, so to be portable across the big three compilers you have to use either intrinsics or standalone assembly.

Re: FFmpeg School of Assembly Language

#109

Post by astrange »

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 code would be architecture specific anyway. ffmpeg is meant to be fast, so it's split into architecture independent and dependent (DSP) parts. The first relies on compiler optimizations, second is what uses SIMD, asm etc.

There is no such thing as a generic "SIMD API" it could use because it uses all specific hardware tools it can to be performant. Anyone who thinks this is posssible is simply mistaken. You can tell because none of them have written ffmpeg.

(There are some things called "array languages" or "stream processing" or "autoscalarization" that work better than SIMD - an example is ispc. But they're not a great fit here, because ffmpeg isn't massively parallel. It's just parallel enough to work.)

Re: FFmpeg School of Assembly Language

#110

Post by astrange »

schainks wrote: post #38
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?

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.

Intrinsics have the disadvantages of asm (non-portable) but also don't reliably have the advantages of them (compilers are pretty unpredictable about optimizing with them) and they're ugly (especially x86 with its weird Hungarian stuff).

There is just a little bit of intrinsics code in ffmpeg, which I wrote, that does memory copies.

https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/i...

It's like this because we didn't want to hide the memory accesses from the compiler, because that hurts optimization, as well as memory tools like ASan.

Post reply on HN