Rust and C++ on Floating-Point Intensive Code • Hacker News Board

Re: Rust and C++ on Floating-Point Intensive Code

#91

Post by lovasoa » Fri, Oct 25, 2019, 9:33 AM UTC

silentvoice wrote: post #84

tom_mellior wrote: post #67

Earlier quoted context omitted.

> yes, the program was vectorized "The program" contains two hot loops. Judging from the assembly code you linked in a sibling comment, only the second of these loops was vectorized, the first one wasn't. This slower non-vectorized loop will still dominate execution time. And for whatever it's worth, dropping the original article's for i in 0..n{ b[i]=b[i]+(r/beta)*(c[i]-a[i]*b[i]) } in place of your loop using itera…

Hi I wrote the blog post linked - and I feel a little silly that I didn't check that _both_ loops vectorized. So I fixed the Rust implementation to keep a running vector of partial sums which I finish up at the end - this one did vectorize. The result was a 2X performance bump, which I'm about to include in the blog post as an update. If it's OK I'll link to this comment as the inspiration. On the iterators versus lo…

I liked your trick to iterate on chunks to force the compiler to vectorize the code ! Now that the code is properly vectorized, you can add the `mul_add` function, and this time you'll see a significant speedup. I tried it on my machine and it made the code 20% faster.

See the generated assembler here: https://rust.godbolt.org/z/G5A2u0

Re: Rust and C++ on Floating-Point Intensive Code

#92

Post by silentvoice » Fri, Oct 25, 2019, 4:01 PM UTC

lovasoa wrote: post #91

silentvoice wrote: post #84

Earlier quoted context omitted.

Hi I wrote the blog post linked - and I feel a little silly that I didn't check that _both_ loops vectorized. So I fixed the Rust implementation to keep a running vector of partial sums which I finish up at the end - this one did vectorize. The result was a 2X performance bump, which I'm about to include in the blog post as an update. If it's OK I'll link to this comment as the inspiration. On the iterators versus lo…

I liked your trick to iterate on chunks to force the compiler to vectorize the code ! Now that the code is properly vectorized, you can add the `mul_add` function, and this time you'll see a significant speedup. I tried it on my machine and it made the code 20% faster. See the generated assembler here: https://rust.godbolt.org/z/G5A2u0

Thanks! The chunks trick was a fairly straightforward translation of what I would do in C++ if the compiler wouldn't vectorize the reduction for some reason. These days most compilers will do it if you pass enough flags, a fact I really took for granted when doing this because Rust is more conservative.

I've tried using mul_add, but at the moment performance isn't much better. But I also noticed someone else on my machine running a big parallel build, so I'll wait a little later and run the full sweep over the problem sizes with mul_add.

So really the existence of FMA didn't have a performance implication it seems except to confirm that Rust wasn't passing "fast math" to LLVM where Clang was. It just so happens that "fast math" will also allow vectorization of reductions.

Re: Rust and C++ on Floating-Point Intensive Code

#93

Post by MaxBarraclough » Fri, Oct 25, 2019, 9:02 PM UTC

IshKebab wrote: post #36

diamondlovesyou wrote: post #4

I have some experience with this, ie ensuring LLVM optimizes and codegens the "best"! I have been working to generate target independent "kernels" for the Rav1e AV1 encoder and have had to do a lot of unidiomatic things to get LLVM to generate machine code similar in quality to hand written ASM. Granted, this is on integers and not floats, but the same principles should apply. What I've found is that you need to igno…

> index checking is expensive Seems a little gung ho to disable guaranteed index checking in a video codec no? I know you still do the checks, but it sounds like it's not in a statically guaranteed way.

Surely tight loops in performance-sensitive code, are precisely where you'd consider disabling runtime checks, no?

You can still have them enabled for debugging, at least. (Something not generally possible in C/C++, sadly.)

Re: Rust and C++ on Floating-Point Intensive Code

#94

Post by IshKebab » Sat, Oct 26, 2019, 12:29 PM UTC

MaxBarraclough wrote: post #93

IshKebab wrote: post #36

Earlier quoted context omitted.

> index checking is expensive Seems a little gung ho to disable guaranteed index checking in a video codec no? I know you still do the checks, but it sounds like it's not in a statically guaranteed way.

Surely tight loops in performance-sensitive code, are precisely where you'd consider disabling runtime checks, no? You can still have them enabled for debugging, at least. (Something not generally possible in C/C++, sadly.)

Depends how much you care about safety, and how much safety is needed. If you're doing an FEA analysis or whatever, fine disable all checking. But a video codec is guaranteed to be used in dangerous environments.

Also depends how much it affects performance. It it doubles it, ok I'll accept the risk. 10% faster? No thanks I'd rather play it safe.

Re: Rust and C++ on Floating-Point Intensive Code

#95

Post by fluffything » Mon, Oct 28, 2019, 9:14 AM UTC

_bxg1 wrote: post #69

fluffything wrote: post #25

Earlier quoted context omitted.

That's kind of at odds with Rust guarantee that your code never breaks.

Technically Rust only guarantees memory-safety (and only outside of unsafe!{}). It has many features that aid in other kinds of safety - strongly encouraging you to unwrap Option and Result , requiring all match cases to be covered, allowing for lots of strategic immutability, etc. But it doesn't guarantee that kind of correctness.

That's not correct. Safe Rust is advertised as sound, and Rust defines that as "safe Rust programs do not exhibit undefined behavior". Undefined behavior is a much larger term than just memory safety, and include things like thread safety, const safety, unwind safety, etc.