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

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

greyblake.com

Post reply on HN
Print view View original

101–110 of 124 posts

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

#101

Post by chrka »

Magicrafter13 wrote: post #99

Based on the title, I knew the issue as soon as I looked at the first table. Still, great primer for those who don't know about such CPU shenanigans, and I did appreciate the solution, since I knew high level how to solve it, but didn't come up with an actual piece of code before the author presented theirs. I didn't know about branch prediction or pipelined CPUs back when I was profiling the code I wrote - honestly…

I've written something like this in C - including resulting assembler code for ARM and x86.

https://easylang.online/blog/branchless

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

#102

Post by inigyou »

amluto wrote: post #93
Ygg2 wrote: post #86

Earlier quoted context omitted.

Keep in mind it's UB to be: > Executing code compiled with target features that the current thread of execution does not support I.e. calling AVX512 on Neon architecture. You need to wrap it in target attributes to even dream of it being safe.

This particular UB is not one of the subtle cases. You will almost certainly get illegal instruction signals if you mess this up.

Is rust UB different from C UB? C UB must be avoided at all costs even if you think you know the actual behavior.

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

#103

Post by inigyou »

Seattle3503 wrote: post #41
aduffy wrote: post #12

Earlier quoted context omitted.

idk why this is getting downvoted, I also got this sense, plugged it into Pangram and indeed, 80% AI-written score. I guess that's fine, but after awhile I get a spidey-sense reading something that feels like a Claude session.

Sad to see you getting voted down. But I guess both the pro-AI crowd and anti-AI crowd hate Pangram.

because it's not much better than an RNG?

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

#104

Post by mrec »

flohofwoe wrote: post #88
gwerbin wrote: post #82

Earlier quoted context omitted.

One nice thing about English is you can just make up words with plausible etymological roots in Latin/French or Old English and often people will know what you mean. In this case though it would probably be spelled "Anglicism".

German language: hold my beer ;)

Hey, this beer glass is cold, lemme get my Handschuh.

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

#105

Post by mynameisash »

grey-area wrote: post #44
altmanaltman wrote: post #29

Earlier quoted context omitted.

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 had a look at their blog page out of curiosity, not that you can prove much from the purported dates and text on a blog, which could be edited at any time. The blog posts from 2010s are in a completely different style and written by a human: https://www.greyblake.com/blog/vim-preview-plugin/ https://www.greyblake.com/blog/how-to-install-firefox-icewea... https://www.greyblake.com/blog/unexpected-ruby-behaviour/ ...…

The first link you cited[0] shows up on the Wayback Machine[1] for the first time on 2022-05-16 - more than 11 years after it was purportedly written.

[0] https://www.greyblake.com/blog/vim-preview-plugin/

[1] https://web.archive.org/web/20220516225844/https://www.greyb...

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

#106

Post by willtemperley »

Retro_Dev wrote: post #10

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

Yep, “instinct“ and “smoking gun” are LLM favourites.

I find it really annoying when the LLM says “good instinct” as if I’m an animal barely able to think.

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

#107

Post by hamburglar »

wegwerper wrote: post #59
Retro_Dev wrote: post #10

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

Agree. Interesting topic but why destroy your own credibility and reputation by shoveling llm-assisted slop to us here at hn? The post should be flagged, and in general, i wish hn would adopt a no-tolerance policy to enhanced posting like this. So what if the original text, if it existed in a human written form at all, had weird textual quirks and prose issues the author wished to hide. That texture's what makes huma…

I think I need to build “Hacker News Except All Arguments About Whether Or Not Something Is AI-Written Are Filtered Out”

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

#108

Post by andai »

anematode wrote: post #13

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_…

This is interesting. So at a certain scale, CPU optimization becomes irrelevant because you're just waiting for new data to come in?

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

#109

Post by dzaima »

dev_hugepages wrote: post #40
anematode wrote: post #13

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.

Compress patterns aren't recognized by any open-source compiler autovectorizer as far as I'm aware of. (I think intel's proprietary C/C++ compiler can?)

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

#110

Post by dzaima »

cogman10 wrote: post #79
anematode wrote: post #46

Earlier quoted context omitted.

Good question. I personally doubt that the compress instruction is easy to coax compilers into generating, as there are many edge cases to consider. For example, you'll notice here that we perform a full vector store of 8 elements unconditionally, even if only a few of the elements are active. This is safe , though, because the output buffer is as large as the input buffer, and we're chunking by 8, so we'll never tra…

I believe the bounds check, in particular, is devastating for autovectorization. There are ways around it, but it requires additional code in safe rust. Edit: actually looks like autovectorization is in play here [1]. Doesn't look like the bounds check gets in the way at all. [1] https://godbolt.org/z/af4qGba5o

There's no autovectorization there; scalar f64-s just are always stored in xmm registers. And the bounds check is still there.
Post reply on HN