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

111–120 of 226 posts

Re: FFmpeg School of Assembly Language

#111

Post by astrange »

PaulDavisThe1st wrote: post #54
lukaslalinsky wrote: post #21

Earlier quoted context omitted.

This is for heavily vectorized code, using every hack possible to fully utilize the CPU. Compilers are smart when it comes to normal code, but codecs are not really normal code. Not a ffmpeg programmer, but have some background dealing with audio.

> codecs are not really normal code. Not really a fair comment. They are entirely normal code in most senses. They differ in one important way: they are (frequently) perfect examples of where "single instruction, multiple data" completely makes sense. "Do this to every sample" is the order of the day, and that is a bit odd when compared with text processing or numerical computation. But this is true of the majority o…

There's a difference because audio processing is often "massively parallel", or at least like 1024 samples at once, but in video codecs operations could be only 4 pixels at once and you have to stretch to find extra things to feed the SIMD operations.

Re: FFmpeg School of Assembly Language

#112

Post by astrange »

variadix wrote: post #46
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.

Also, if you write code with intrinsics the autovectorization can make it _worse_. eg a pattern is to write a SIMD main loop and then a scalar tail, but it can autovectorize that and mess it up.

Re: FFmpeg School of Assembly Language

#113

Post by astrange »

bob1029 wrote: post #43
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 thi…

Statistics aren't magic and it's not going to find superoptimizing cases like this by using them. I think this is only helpful when you get a lot of incoming poorly written/dynamic code needing a lot of inlining, that maybe just got generated in the first place. So basically serving ads on websites.

In ffmpeg's case you can just always be the correct thing.

Re: FFmpeg School of Assembly Language

#114

Post by astrange »

1propionyl wrote: post #24
jki275 wrote: post #20

Earlier quoted context omitted.

Probably some very niche things. I know I can't write ASM that's 10x better than C, but I wouldn't assume no one can.

It depends on what you're trying to do. I would in general only expect such substantial speedups when considering writing computation kernels (for audio, video, etc). Compilers today are liable in most circumstances to know many more tricks than you do. Especially if you make use of hints (e.g. "this memory is almost always accessed sequentially", "this branch is almost never taken", etc) to guide it.

Mm, those hints don't matter on modern CPUs. There's no good way for the compiler to pass it down to them either. There are some things like prefetch instructions, but unless you know the exact machine you're targeting, you won't know when to use them.

Re: FFmpeg School of Assembly Language

#115

Post by astrange »

School-Cotton wrote: post #90
jancsika wrote: post #71

What's the cost of shuttling data in and out of SIMD land?

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.

Re: FFmpeg School of Assembly Language

#119

Post by xgkickt »

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

Only if using x86-64 IME. Other architectures that don’t require as much shuffling of data are far more legible.

Re: FFmpeg School of Assembly Language

#120

Post by cnt-dracula »

kierank wrote: post #117

I am the author of these lessons. Ask me anything.

Hi, thanks for your work!

I have a question, as someone who can just about read assembly but still do not intuitively understand how to write or decompose ideas to utilise assembly, do you have any suggestions to learn / improve this?

As in, at what point would someone realise this thing can be sped up by using assembly? If one found a function that would be really performant in assembly how do you go about writing it? Would you take the output from a compiler that's been converted to assembly or would you start from scratch? Does it even matter?

Post reply on HN