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

211–220 of 226 posts

Re: FFmpeg School of Assembly Language

#211

Post by janwas »

rbultje wrote: post #202
janwas wrote: post #193

Earlier quoted context omitted.

I'm curious why there are even function calls in time-critical code, shouldn't just about everything be inlined there? And if it's not time-critical, why are we interested in the savings from a custom calling convention?

Binary size was a concern, so excessive inlining was undesirable. And don't forget that any asm-optimized variant always has a C fallback for generic platforms lacking a hand-optimized variant which is also used to verify the asm-optimized variant using checkasm. This might not be linked into your binary/library (the linker eliminated it because it's never used), but the code exists nonetheless.

hm, fair enough. IIRC JPEG XL was a few hundred KB of SIMD code for the four or so different targets/ISAs, including the generic fallback, but I can believe video codecs are larger.

Re: FFmpeg School of Assembly Language

#212

Post by janwas »

hrydgard wrote: post #200
janwas wrote: post #193

Earlier quoted context omitted.

I'm curious why there are even function calls in time-critical code, shouldn't just about everything be inlined there? And if it's not time-critical, why are we interested in the savings from a custom calling convention?

Function calls are very fast (unless there's really a lot of parameter copying/saving-to-stack) and if you can re-use a chunk of code from multiple places, you'll reduce pressure on the instruction cache. Inlining is not always ideal.

Perhaps the use cases are different (heavily data-parallel), but FWIW I do not remember many cases where we were frontend bound, so icache hasn't been a concern.

Re: FFmpeg School of Assembly Language

#213

Post by Narishma »

holowoodman wrote: post #207
buserror wrote: post #167

I used to do quite a bit of SIMD version of critical functions, but now I rarely do -- one thing to try is isolate that code, and run it in the Most Excellent Compiler Explorer [0]. And stare at the generated code! More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide you…

Problem is, you have to take care to look at the compiler output and compare it to your expectations. Maybe fiddle with it a bit until it matches what you would have written yourself. Usually, it is quicker to just write it yourself...

> Problem is, you have to take care to look at the compiler output and compare it to your expectations. Maybe fiddle with it a bit until it matches what you would have written yourself.

And keep redoing that for every new compiler or version of a compiler, or if you change compile options. Any of those things can prevent the auto-vectorization.

Re: FFmpeg School of Assembly Language

#214

Post by ack_complete »

buserror wrote: post #167

I used to do quite a bit of SIMD version of critical functions, but now I rarely do -- one thing to try is isolate that code, and run it in the Most Excellent Compiler Explorer [0]. And stare at the generated code! More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide you…

As a counterpoint, I regularly run into trivial cases that compilers are not able to autovectorize well:

https://gcc.godbolt.org/z/rjEqzf1hh

This is an unsigned byte saturating add. It is directly supported as a single instruction in both x86-64 and ARM64 as PADDUSB and UQADD.16B. But all compilers make a mess of it from a straightforward description, either failing to vectorize it or generating vectorized code that is much larger and slower than necessary.

This is with a basic, simple vectorization primitive. It's difficult to impossible to get compilers to use some of the more complex ones, like a rounded narrowing saturated right shift (UQRSHRN).

Re: FFmpeg School of Assembly Language

#215

Post by Narishma »

buserror wrote: post #167

I used to do quite a bit of SIMD version of critical functions, but now I rarely do -- one thing to try is isolate that code, and run it in the Most Excellent Compiler Explorer [0]. And stare at the generated code! More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide you…

IME, auto-vectorization is a fragile optimization that will silently fail under all sorts of conditions. I don't like to rely on it.

Re: FFmpeg School of Assembly Language

#216

Post by eddd-ddde »

Narishma wrote: post #215
buserror wrote: post #167

I used to do quite a bit of SIMD version of critical functions, but now I rarely do -- one thing to try is isolate that code, and run it in the Most Excellent Compiler Explorer [0]. And stare at the generated code! More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide you…

IME, auto-vectorization is a fragile optimization that will silently fail under all sorts of conditions. I don't like to rely on it.

You can just store the generated binary / assembly and rely on that if you want stable code.

Re: FFmpeg School of Assembly Language

#217

Post by ack_complete »

anonymoushn wrote: post #204
neonsunset wrote: post #171

Earlier quoted context omitted.

Java's Panama Vectors are work in progress and are far from being competitive with .NET's implementation of SIMD abstractions, which is mostly on par with Zig, Swift and Mojo. You can usually port existing SIMD algorithms from C/C++/Rust to C# with few changes retaining the same performance, and it's practically impossible to do so in Java. I feel like C veterans often don't realize how unnecessarily ceremonious plat…

I'm primarily writing "general-purpose" code (especially parsers and formatters) rather than code that does the same math operation on a big array, so it's usually not reasonable to even use the same approach to the problem with different vector extensions :(

Even in the latter case, different approaches are often required. For an 8x8 byte block difference, SSE2 prefers horizontal accumulation (PSADBW) while ARM64 prefers vertical (UABAL). It's noticeably suboptimal if you try abstracting across these with generic primitives.

Re: FFmpeg School of Assembly Language

#218

Post by sweeter »

foresto wrote: post #146
sweeter wrote: post #142

Earlier quoted context omitted.

Yea but that first asterisk is incorrect

Is there an echo in here? ;)

no lol you're just missing the question I am asking. obviously sizeof wont return a pointer. Im just saying, wouldn't it be `sizeof(usize)` essentially... or `sizeof(ptr_size_on_platform)`

Re: FFmpeg School of Assembly Language

#219

Post by SavioMak »

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…

I think the first two asterisks are used like footnotes pairs

Re: FFmpeg School of Assembly Language

#220

Post by buserror »

ack_complete wrote: post #214
buserror wrote: post #167

I used to do quite a bit of SIMD version of critical functions, but now I rarely do -- one thing to try is isolate that code, and run it in the Most Excellent Compiler Explorer [0]. And stare at the generated code! More often than not, the auto-vectorisation now generates pretty excellent SIMD version of your function, and all you have to do is 'hint' the compiler -- for example explicitly list alignment, provide you…

As a counterpoint, I regularly run into trivial cases that compilers are not able to autovectorize well: https://gcc.godbolt.org/z/rjEqzf1hh This is an unsigned byte saturating add. It is directly supported as a single instruction in both x86-64 and ARM64 as PADDUSB and UQADD.16B. But all compilers make a mess of it from a straightforward description, either failing to vectorize it or generating vectorized code that…

Oh I agree it is not foolproof, in fact I never understood why saturated math isn't 'standard' somewhere, even as an operator. Given we have 'normalisation' operator there's alway a way to find a natural looking syntax of sort.

But again, if you don't like the generated code, you can take the generated code and tweak it, and use that; I did it quite a few times.

Post reply on HN