Hacker News Reader

Comment by sp332 | Hacker News Reader

Is there an advantage to writing ASM without intrinsics?

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.

> 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...

Many. For me the biggest one is code readability. I am very, very happy with their choice of NASM syntax.

The idea behind intrinsics is that you use one, or several assembly instructions in your code base, letting the compiler manage registers for you. But (especially these days) there is rarely a single instruction that makes your code go faster: you have to write entire large blocks of assembly. That is much better done using assembly than intrinsics.

Not if you use a backend like the one in ICC.

I was trying to remember if autovectorization worked better with intrinsics, but I don't really know that much about it.

Yes, everything works better with intrinsics:

- codegen because the compiler spills better than you, and knows what register to save. It knows about register renaming

- inlining works better

- loop unrolling works better

- any kind of hoisting

And it's also 3x faster to write, and much faster to refactor back to C++. Provided you have the right backend, it will lead to less maintenance issue with about 5% better performance.

Reply on news.ycombinator.com