Live data from Hacker News

Branchless Rust: Making a Filter 4x Faster by Removing an If

greyblake.com

31–40 of 124 posts

Re: Branchless Rust: Making a Filter 4x Faster by Removing an If

#33
post #3

Great explanation of why a branchless approach results in such a speed up. I've never really had to deal with performance optimization at this level. Generally it's probably best not to get too involved letting the CPU black box do its thing. I do wonder, would the performance characteristics of branchless vs branching be consistent across different CPUs/architectures? If you had a CPU that wasn't trying to be fancy…

I'm not sure how your intuition can be that off, if you don't have a branch predictor then any branching code is going to be even slower than it already is, favouring branchless code even more for obvious reasons.

I say this as someone who is interested in a special type of processor architecture that has no branch prediction at all and would need a branchless subset of Rust to meaningfully program it at high performance.

Re: Branchless Rust: Making a Filter 4x Faster by Removing an If

#34
post #18

This article is 100% AI written. The data was interesting, the commentary overly verbose and hard to gain useful insights from.

I'm apparently not good at spotting it. I was put off by the overly dramatic presentation. It gets tiring that the author apparently finds this more exciting than I do, and writes like it's enthralling. I just assumed it was an excess of enthusiasm or the first experience with this kind of thing. If it's AI, I'm way behind the game noticing it.

"The smoking gun" is right there in the text ;) (but also things like "Same million floats. Same threshold. Same function."). Don't know if other models have that same specific style, but it looks very 'claude-y'.

I wouldn't be surprised though if (especially) non-native speakers unconsciously start adopting the Claude writing style when they stare all day long at Claude generated text at work.

Re: Branchless Rust: Making a Filter 4x Faster by Removing an If

#37

This article is 100% AI written. The data was interesting, the commentary overly verbose and hard to gain useful insights from.

Click on their blog index page, see posts going back to early 2010s and use the same writing style. He must have been time travelling and using AI all this time!

I think he's asked it to write in his specific style, or possibly he has edited parts of it to his style, or maybe used AI to generate the initial draft.

Something like that anyway. There are some very clear AI tells (smoking guns if you like), but most of it does not read like the prose AI produces by default.

Author if you are here I am curious about your writing process, and why you didn't remove the obvious AI tells.

Re: Branchless Rust: Making a Filter 4x Faster by Removing an If

#38

Nice post! You can do even a bit better if you're willing to use intrinsics. In particular this kind of operation is well-suited for compress-type operations, available as a first-class operation in at least AVX512, SVE and RVV; you can also emulate them reasonably quickly on NEON and AVX2. Here's an example, building on the OP's work: pub fn filter_compress(input: &[f64], threshold: f64) -> Vec { use std::arch::x86_…

Nice! I saw the code and thought, I bet there’s a way to do some SIMD here… never touched intrinsics in Rust before so I really appreciate you writing it up!

See the following pdf for example on how to do this with SSSE3 (pages 104-133) or even SSE2 (pages 151-173)

https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...

Re: Branchless Rust: Making a Filter 4x Faster by Removing an If

#40

Nice post! You can do even a bit better if you're willing to use intrinsics. In particular this kind of operation is well-suited for compress-type operations, available as a first-class operation in at least AVX512, SVE and RVV; you can also emulate them reasonably quickly on NEON and AVX2. Here's an example, building on the OP's work: pub fn filter_compress(input: &[f64], threshold: f64) -> Vec { use std::arch::x86_…

I heard there's a way to arrange code such that the compiler can autobectorize easier. I wonder if there's a way to do that here?

Would probably have to pass `-C target-cpu=native` to cargo so that llvm is allowed to use AVX512.

Post reply on HN