Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to AVX2 optimizations in x264

scribd.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Introduction to AVX2 optimizations in x264

#11

Post by DarkShikari »

jamesaguilar wrote: post #10
DarkShikari wrote: post #3

Earlier quoted context omitted.

I only pushed the code a few minutes ago, but binaries should probably be up at http://x264.nl/ relatively soonish (it's not my site though, so I wouldn't know exactly). If you want to test without a physical Haswell, the Intel Software Development Emulator should work okay, albeit somewhat slowly. I'd post overall numbers for real Haswells, but Intel has apparently said we can't do that yet. Regarding FMA, FMA3/4 ar…

I've heard that there are c libraries for things like SSE2. I assume the same is true of AVX2. If this is so, why do you write so much of x264 in assembly? Do you find that there are significant gains versus c-code that uses SIMD libraries? Have I been misled that C is nearly as fast as assembly 99% of the time? Note: I'm not trying to question your engineering chops, just trying to correct my own misconceptions.

"C libraries for things like SSE2"? Do you mean math libraries that have SIMD implementations of various functions that are callable from C? This here is effectively writing those libraries; they don't exist until we write the code.

Re: Introduction to AVX2 optimizations in x264

#12

Post by jamesaguilar »

DarkShikari wrote: post #11
jamesaguilar wrote: post #10

Earlier quoted context omitted.

I've heard that there are c libraries for things like SSE2. I assume the same is true of AVX2. If this is so, why do you write so much of x264 in assembly? Do you find that there are significant gains versus c-code that uses SIMD libraries? Have I been misled that C is nearly as fast as assembly 99% of the time? Note: I'm not trying to question your engineering chops, just trying to correct my own misconceptions.

"C libraries for things like SSE2"? Do you mean math libraries that have SIMD implementations of various functions that are callable from C? This here is effectively writing those libraries ; they don't exist until we write the code.

I'm talking about something like this: http://sseplus.sourceforge.net/fntable.html

I'm not an SIMD expert, but it seems like this implements similar primitives to those that are available to assembly (and not C). My question is basically whether the algorithms you're talking about could be implemented with these primitives. Although I guess no such library yet exists for AVX2.

Re: Introduction to AVX2 optimizations in x264

#13

Post by DarkShikari »

jamesaguilar wrote: post #12
DarkShikari wrote: post #11

Earlier quoted context omitted.

"C libraries for things like SSE2"? Do you mean math libraries that have SIMD implementations of various functions that are callable from C? This here is effectively writing those libraries ; they don't exist until we write the code.

I'm talking about something like this: http://sseplus.sourceforge.net/fntable.html I'm not an SIMD expert, but it seems like this implements similar primitives to those that are available to assembly (and not C). My question is basically whether the algorithms you're talking about could be implemented with these primitives. Although I guess no such library yet exists for AVX2.

Intrinsics aren't really C; they work in a C-like syntax, but you're still doing the exact same thing as assembly: you still have to write out every instruction you want to use, so you're not really saving any effort compared to just skipping the middleman.

In return, you are stuck with an extremely ugly syntax and a much less functional preprocessor, with the added bonus of a compiler that mangles your code.

Re: Introduction to AVX2 optimizations in x264

#14

Post by jedbrown »

DarkShikari wrote: post #13
jamesaguilar wrote: post #12

Earlier quoted context omitted.

I'm talking about something like this: http://sseplus.sourceforge.net/fntable.html I'm not an SIMD expert, but it seems like this implements similar primitives to those that are available to assembly (and not C). My question is basically whether the algorithms you're talking about could be implemented with these primitives. Although I guess no such library yet exists for AVX2.

Intrinsics aren't really C; they work in a C-like syntax, but you're still doing the exact same thing as assembly: you still have to write out every instruction you want to use, so you're not really saving any effort compared to just skipping the middleman. In return, you are stuck with an extremely ugly syntax and a much less functional preprocessor, with the added bonus of a compiler that mangles your code.

With intrinsics, you don't have to think about register naming. You still might count registers to avoid spills (and check the assembly to make sure), but there is less of a mental context switch than writing straight assembly.

Re: Introduction to AVX2 optimizations in x264

#15

Post by Scaevolus »

DarkShikari wrote: post #13
jamesaguilar wrote: post #12

Earlier quoted context omitted.

I'm talking about something like this: http://sseplus.sourceforge.net/fntable.html I'm not an SIMD expert, but it seems like this implements similar primitives to those that are available to assembly (and not C). My question is basically whether the algorithms you're talking about could be implemented with these primitives. Although I guess no such library yet exists for AVX2.

Intrinsics aren't really C; they work in a C-like syntax, but you're still doing the exact same thing as assembly: you still have to write out every instruction you want to use, so you're not really saving any effort compared to just skipping the middleman. In return, you are stuck with an extremely ugly syntax and a much less functional preprocessor, with the added bonus of a compiler that mangles your code.

In terms of mangling, it reorders your vector operations, which can drastically hurt performance.

Do any production compilers schedule instructions to maximize superscalar performance?

Re: Introduction to AVX2 optimizations in x264

#16

Post by DarkShikari »

jedbrown wrote: post #14
DarkShikari wrote: post #13

Earlier quoted context omitted.

Intrinsics aren't really C; they work in a C-like syntax, but you're still doing the exact same thing as assembly: you still have to write out every instruction you want to use, so you're not really saving any effort compared to just skipping the middleman. In return, you are stuck with an extremely ugly syntax and a much less functional preprocessor, with the added bonus of a compiler that mangles your code.

With intrinsics, you don't have to think about register naming. You still might count registers to avoid spills (and check the assembly to make sure), but there is less of a mental context switch than writing straight assembly.

I almost never spend more than a few seconds considering register allocation/naming when writing assembly (part of this is because x264's abstraction layer lets macros swap their arguments, so you don't have to track "what happens to be in xmm0 right now" mentally). In some rare cases it can get tricky when you start pushing up against the register cap, but that's exactly the case where the compiler tends to do terribly, and you'd want to do it yourself.

The pain of not having a proper macro assembler in C intrinsics is orders of magnitude worse than having to do my own register allocation in yasm, so for now, yasm is the lesser of two evils.

Re: Introduction to AVX2 optimizations in x264

#17

Post by _ihaque »

jedbrown wrote: post #14
DarkShikari wrote: post #13

Earlier quoted context omitted.

Intrinsics aren't really C; they work in a C-like syntax, but you're still doing the exact same thing as assembly: you still have to write out every instruction you want to use, so you're not really saving any effort compared to just skipping the middleman. In return, you are stuck with an extremely ugly syntax and a much less functional preprocessor, with the added bonus of a compiler that mangles your code.

With intrinsics, you don't have to think about register naming. You still might count registers to avoid spills (and check the assembly to make sure), but there is less of a mental context switch than writing straight assembly.

(I guess DarkShikari's comment is nested too deeply for me to reply directly.)

In my (admittedly limited) experience [1], the compiler has actually done pretty decently at optimizing register allocation in intrinsic-heavy loops. I wrote out the assembly loop in [2] with manual allocation into all 16 XMMs and then noticed the compiler managed to optimize 1 of them out.

[1] https://github.com/simtk/IRMSD

[2] https://github.com/SimTk/IRMSD/blob/master/python/IRMSD/theo...

Re: Introduction to AVX2 optimizations in x264

#18

Post by jamesaguilar »

_ihaque wrote: post #17
jedbrown wrote: post #14

Earlier quoted context omitted.

With intrinsics, you don't have to think about register naming. You still might count registers to avoid spills (and check the assembly to make sure), but there is less of a mental context switch than writing straight assembly.

(I guess DarkShikari's comment is nested too deeply for me to reply directly.) In my (admittedly limited) experience [1], the compiler has actually done pretty decently at optimizing register allocation in intrinsic-heavy loops. I wrote out the assembly loop in [2] with manual allocation into all 16 XMMs and then noticed the compiler managed to optimize 1 of them out. [1] https://github.com/simtk/IRMSD [2] https://gi…

You can always reply directly by clicking on the link above a person's comment. Thanks for the interesting discussion on this one guys.

Re: Introduction to AVX2 optimizations in x264

#19

Post by _ihaque »

jamesaguilar wrote: post #18
_ihaque wrote: post #17

Earlier quoted context omitted.

(I guess DarkShikari's comment is nested too deeply for me to reply directly.) In my (admittedly limited) experience [1], the compiler has actually done pretty decently at optimizing register allocation in intrinsic-heavy loops. I wrote out the assembly loop in [2] with manual allocation into all 16 XMMs and then noticed the compiler managed to optimize 1 of them out. [1] https://github.com/simtk/IRMSD [2] https://gi…

You can always reply directly by clicking on the link above a person's comment. Thanks for the interesting discussion on this one guys.

Thanks for the pointer! That's what I get for lurking for too long.

Re: Introduction to AVX2 optimizations in x264

#20

Post by kevinnk »

Scaevolus wrote: post #15
DarkShikari wrote: post #13

Earlier quoted context omitted.

Intrinsics aren't really C; they work in a C-like syntax, but you're still doing the exact same thing as assembly: you still have to write out every instruction you want to use, so you're not really saving any effort compared to just skipping the middleman. In return, you are stuck with an extremely ugly syntax and a much less functional preprocessor, with the added bonus of a compiler that mangles your code.

In terms of mangling, it reorders your vector operations, which can drastically hurt performance. Do any production compilers schedule instructions to maximize superscalar performance?

Um, unless I misunderstand your question, virtually all of them do. In particular, GCC, Clang/LLVM and ICC all do instruction scheduling.
Post reply on HN