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

Optimizing your programs for Arm platforms

community.arm.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Optimizing your programs for Arm platforms

#21

Post by dzaima »

astrange wrote: post #13
dzaima wrote: post #12

Earlier quoted context omitted.

Both gcc and clang check for aliasing at runtime if not provable statically for autovectorization (granted, that can fail if you have reverse/strided/gather addresses, but those are less common; and yeah it does lead to some constant overhead, though likely not significant often). Of minor note is that you can add "#pragma clang loop vectorize(assume_safety)" or "#pragma GCC ivdep" on the respective compilers to a lo…

> Both gcc and clang check for aliasing at runtime if not provable statically for autovectorization This is often enough to make it unworkable, because it means you're inserting checks into hot loops. Also, if you partially vectorize something yourself you have to write similar setup code, which might involve scalar versions of the loop, but then autovectorization can come by and vectorize those, so now you have dupl…

The checks are done outside of the loop though (unless you mean ≥two nested loops, with a small-ish inner one, at which point things indeed get less nice, but also this is less common).

Yeah, autovectorization of a manual tail loop can be annoying, but there is "#pragma clang loop unroll(disable)" and "#pragma clang loop vectorize(disable)" for clang, and for gcc "#pragma GCC unroll 1" and, from gcc 14, "#pragma GCC novector".

Re: Optimizing your programs for Arm platforms

#22

Post by dzaima »

BoingBoomTschak wrote: post #19
astrange wrote: post #2

This isn't a good article. I would say that if you're trying to rely on `restrict` and autovectorization you're doomed and should write it yourself. Even if it works on one compiler version, it won't work on all of them. (It could possibly work in a language that isn't C and is designed for it; Fortran or shader programs are easier to autovectorize, and something like ISPC starts out "vectorized" and gets "autoscalar…

The big problem is that gcc/clang don't seem to have a concept of optimization notices, like SBCL does. Nobody is more appropriate than the compiler to warn you that it couldn't optimize something costly and why.

Clang does have "-Rpass-missed=vectorize" among others.

Re: Optimizing your programs for Arm platforms

#23

Post by dzaima »

astrange wrote: post #15
SubjectToChange wrote: post #9

Earlier quoted context omitted.

It has the opposite problem; it's drawing from a small pool of skilled contributors,.. The project has 2000+ direct contributors and even more indirect contributors on its mailing lists. ...because so much other incorrect advice thinks it's fine to use autovectorization that doesn't work. There are few high performance programmers who genuinely believe that autovectorization can compete with hand written assembly. Th…

> The project has 2000+ direct contributors and even more indirect contributors on its mailing lists. I'm one of them, so please just believe me instead of trying to correct me ;) It's an ongoing problem the project talks about that there aren't enough newcomers ready to write more SIMD code with good enough quality. > Should they be showering ffmpeg et al. with praise or something? The top reply is "just do this oth…

If ffmpeg can't pull together enough good SIMD developers from its thousands of contributors, then most projects won't be able to get any. Having a problem of "not enough" is already miles better the problem of "having none".

Re: Optimizing your programs for Arm platforms

#24

Post by SubjectToChange »

astrange wrote: post #15
SubjectToChange wrote: post #9

Earlier quoted context omitted.

It has the opposite problem; it's drawing from a small pool of skilled contributors,.. The project has 2000+ direct contributors and even more indirect contributors on its mailing lists. ...because so much other incorrect advice thinks it's fine to use autovectorization that doesn't work. There are few high performance programmers who genuinely believe that autovectorization can compete with hand written assembly. Th…

> The project has 2000+ direct contributors and even more indirect contributors on its mailing lists. I'm one of them, so please just believe me instead of trying to correct me ;) It's an ongoing problem the project talks about that there aren't enough newcomers ready to write more SIMD code with good enough quality. > Should they be showering ffmpeg et al. with praise or something? The top reply is "just do this oth…

I'm one of them, so please just believe me instead of trying to correct me ;)…

No you aren’t. Or rather, there’s absolutely no reason for me to believe you are.

It's an ongoing problem the project talks about that there aren't enough newcomers ready to write more SIMD code with good enough quality.

Good programmers are in short supply across the entire industry. Like anything else it’s just a matter of practice.

The top reply is "just do this other thing that the article said was unworkable", so not doing that would be a start.

A) Get a thicker skin. It’s not the end of the world when people leave comments related to the topic at hand.

B) x86inc.asm isn’t a particularly interesting approach to programming assembly.

Other people mostly only target one CPU architecture as they're less important,…

If hardware portability is a goal then handwritten assembly is even more wasteful.

It's similar to how x264 was better than every commercial competitor while working for free, simply because they took more time to think about what they were doing.

A lot of it simply comes down to sheer man hours and the quantity/quality of bug reports. No 4d chess, no great geniuses, just “good enough” persistence.

Anyway, the problem with handwriting assembly is that such programs are trivial in their complexity and/or given unusually strong guarantees.

Re: Optimizing your programs for Arm platforms

#25

Post by BoingBoomTschak »

dzaima wrote: post #22
BoingBoomTschak wrote: post #19

Earlier quoted context omitted.

The big problem is that gcc/clang don't seem to have a concept of optimization notices, like SBCL does. Nobody is more appropriate than the compiler to warn you that it couldn't optimize something costly and why.

Clang does have "-Rpass-missed=vectorize" among others.

Huh, the more you know.

Re: Optimizing your programs for Arm platforms

#26

Post by astrange »

janwas wrote: post #18
astrange wrote: post #8

Earlier quoted context omitted.

> Projects like ffmpeg are able to do it because they're pulling from a massive pool of contributors. It has the opposite problem; it's drawing from a small pool of skilled contributors, because not enough people have learned it, because so much other incorrect advice thinks it's fine to use autovectorization that doesn't work. > Honestly, who is saying that? The recent article here about ffmpeg's use of assembly exc…

> it doesn't use intrinsics because they aren't actually easier to work with; they are not faster, not more portable Well golly, I'll just have to disagree based on >20 years of experience, including several in assembly. asm is only (maybe) faster for the code we manage to get written. From where I sit, video codecs are a rare special case in that the format is standardized, changes only every few years, and has only…

> BTW the "not more portable" comment is a strawman because intrinsics themselves indeed aren't portable, but a wrapper library on top (such as our Highway) is.

That's not intrinsics then, it's different abstraction. You could write a wrapper library over inline assembly if you wanted to.

(And of course the intrinsics themselves could almost all be implemented as a header using inline assembly too. Since you're probably not relying on the compiler to optimize your intrinsic math. But optimization would be a bit worse because it doesn't know the byte size of each instruction.)

Re: Optimizing your programs for Arm platforms

#27

Post by janwas »

astrange wrote: post #26
janwas wrote: post #18

Earlier quoted context omitted.

> it doesn't use intrinsics because they aren't actually easier to work with; they are not faster, not more portable Well golly, I'll just have to disagree based on >20 years of experience, including several in assembly. asm is only (maybe) faster for the code we manage to get written. From where I sit, video codecs are a rare special case in that the format is standardized, changes only every few years, and has only…

> BTW the "not more portable" comment is a strawman because intrinsics themselves indeed aren't portable, but a wrapper library on top (such as our Highway) is. That's not intrinsics then, it's different abstraction. You could write a wrapper library over inline assembly if you wanted to. (And of course the intrinsics themselves could almost all be implemented as a header using inline assembly too. Since you're proba…

hm, sounds almost like macros wouldn't make it assembly anymore :)

I'm curious whether you know of any such inline asm wrapper? Seems that this gives the compiler less information than the intrinsics, which largely expand to builtins.

Re: Optimizing your programs for Arm platforms

#28

Post by dzaima »

astrange wrote: post #26
janwas wrote: post #18

Earlier quoted context omitted.

> it doesn't use intrinsics because they aren't actually easier to work with; they are not faster, not more portable Well golly, I'll just have to disagree based on >20 years of experience, including several in assembly. asm is only (maybe) faster for the code we manage to get written. From where I sit, video codecs are a rare special case in that the format is standardized, changes only every few years, and has only…

> BTW the "not more portable" comment is a strawman because intrinsics themselves indeed aren't portable, but a wrapper library on top (such as our Highway) is. That's not intrinsics then, it's different abstraction. You could write a wrapper library over inline assembly if you wanted to. (And of course the intrinsics themselves could almost all be implemented as a header using inline assembly too. Since you're proba…

The compiler can still do optimizations on intrinsics - clang passes most through its regular optimizations, so you get things like loop unrolling, CSE (quite powerful if you have multiple invocations of the same SIMD thing, deduplicating constant loads or whatnot), and some genuine improvements/reducing what you need to pay attention to (don't need to manually merge to 'vpandn', 'vpand a,b,c; vptest a,a' → 'vptest b,c', sometimes improving shuffles, moving out negation from movmsk of negation of vpcmpeq), though it can of course make things worse too as regular compiler tax.

An example of something that inline assembly would handle badly would be broadcast, which x86 pre-AVX-512 only can do with a value already in a SIMD register, or directly from memory, but the programmer almost always will want to provide it as a regular scalar variable, i.e. GPR.

Re: Optimizing your programs for Arm platforms

#29

Post by Phyx »

BoingBoomTschak wrote: post #19
astrange wrote: post #2

This isn't a good article. I would say that if you're trying to rely on `restrict` and autovectorization you're doomed and should write it yourself. Even if it works on one compiler version, it won't work on all of them. (It could possibly work in a language that isn't C and is designed for it; Fortran or shader programs are easier to autovectorize, and something like ISPC starts out "vectorized" and gets "autoscalar…

The big problem is that gcc/clang don't seem to have a concept of optimization notices, like SBCL does. Nobody is more appropriate than the compiler to warn you that it couldn't optimize something costly and why.

GCC has among others -fopt-info-vec-missed

Re: Optimizing your programs for Arm platforms

#30

Post by ColonelPhantom »

astrange wrote: post #6
ColonelPhantom wrote: post #5

Earlier quoted context omitted.

Aren't shader programs more like ISPC (or OpenCL/CUDA), in that the programming model is based around 'pretend each SIMD lane is thread'?

Depends on the target architecture. Some GPUs have used vectors in the past, and some people try to run shaders on CPU. (like for OpenCL or for emulation)

> Some GPUs have used vectors in the past

Which ones? I'm aware of AMD/ATi Terascale using VLIW, but I'm pretty sure that architecture also used SIMD (requiring the use of both VLIW and large 'waves' to achieve maximum occupancy).

And running shaders on CPU is, in essence, a similar programming model to ISPC. When you run OpenCL on a CPU I am quite certain that the runtime pretends each lane is a program instance, same as ISPC.

Post reply on HN