Hacker News Reader

Comment by rbultje | Hacker News Reader

Yes. For intrinsics, the compiler chooses whether and when to spill variables to the stack. For hand-written assembly, you are explicitly burdened with this yourself, usually causing you to optimize the flow of the function so it minimizes stack spilling. In addition, your function will perform the same regardless of the compiler.

In FFmpeg, we have found in the past that functions written in pure assembly are typically a few % faste than those written in intrinsics. Depending on your use case, that may make it worth it.

The obvious disadvantage is that pure assembly is harder, so writing functions takes a bit longer.

View on HN

> the compiler chooses whether and when to spill variables to the stack.

In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++). I can manage this by looking at compiler's output: when I find there something I don't want, be it stack spilling or other reasons for me not liking the assembly, I go fix my C++ code.

> so writing functions takes a bit longer

Also reading is hard, therefore refactoring/improvements is hard, too. I have an impression the assembly is write only language.

> In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++).

This is less true when you try and support many versions of many compilers, however, in my experience.

Yeah, that makes sense. I usually deliver results of my work in binaries so I can choose the compiler, and inspect compiler output of performance critical parts. Authors of that decoder didn’t have that luxury.

Assembly is very readable with enough practice.

Source: I've ported multiple assembly language games from one assembly language to another.

I think I have enough practice. I find assembly very readable on small scale. But when I need to write larger pieces of vectorized code, higher-level C++ constructs help a lot with readability, following reasons.

Local variables and function arguments are named, as opposed to xmm/ymm register numbers.

I can use (forcefully inlined) C++ functions to compose code from smaller pieces. In some cases, even OOP.

Even in vectorized code there’re pieces running on scalar blocks of cores: loops, addresses calculations, conditions. With assembly you have to use it for the whole things.

Doesn't asm have the disadvantage that you end up spilling if you exceed 8 xmm registers even when running on x86_64 with 16 xmm registers available?

Or do you actually write separate asm for x86 and x86_64?

I would imagine they write separate asm for x86, x86_64, and the various instruction set extensions that exist.

A project may even go so far as to write different asm for the same ISA for different architectures in order to optimize for specific pipeline behavior or whatnot

https://github.com/z-classic/libgmp/tree/master/mpn/x86_64

You either write an entire separate asm function, or use macro utilities to ifdef portions of the function. See for example: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcod...

Reply on news.ycombinator.com