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

111–120 of 124 posts

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

#111

Post by kbelder »

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.

I always got voted down when I posted the evaluation of the parent articles I got from my Ouija board. I just want to help people understand whether they should just reject bad articles, without having to bother reading them.

I'm moving on to evaluating articles with a modified lie detector test and tarot cards, I'm sure that'll help my credibility and give my public rejections more authority.

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

#112

Post by aapoalas »

inigyou wrote: post #102
amluto wrote: post #93

Earlier quoted context omitted.

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.

It is not.

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

#113

Post by rabiescow »

llama_drama wrote: post #63

Branchless code can indeed sometimes be slower than conventional one, but in this particular case, the article comes to the wrong conclusion. At a 1% kept, the branchless version is slower because it pays the cost of zero-initializing 8 MB of memory when allocating the Vec. This can be easily demonstrated by comparing it with a version that allocates uninitialized memory.

Did you read the article? The author was trying to even out the test cases and successfully did so. He stated that the idiomatic code was faster for the 1 % as you can see by quote below:

  The worst case became almost 4 times faster. And look how flat the branchless column   is: the running time does not depend on the data anymore, exactly as we wanted.

  Notice the price we paid though. At 1% kept the idiomatic version wins, because an almost always correctly predicted branch is nearly free, while the branchless version always pays for one million writes. Branchless code is not faster in general: it trades the best case for the worst case.

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

#115

Post by Seattle3503 »

inigyou wrote: post #103
Seattle3503 wrote: post #41

Earlier quoted context omitted.

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?

What data supports that conclusion about Pangram?

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

#116

Post by Seattle3503 »

kbelder wrote: post #111
Seattle3503 wrote: post #41

Earlier quoted context omitted.

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

I always got voted down when I posted the evaluation of the parent articles I got from my Ouija board. I just want to help people understand whether they should just reject bad articles, without having to bother reading them. I'm moving on to evaluating articles with a modified lie detector test and tarot cards, I'm sure that'll help my credibility and give my public rejections more authority.

Do you have evidence Pangram is unreliable? There are independent evaluations [1, 2] showing it works, and it's getting used more and more scientific papers. Have you used it or evaluated it yourself? What do you think these other evaluators are doing or getting wrong?

1: https://bfi.uchicago.edu/insights/artificial-writing-and-aut... 2: https://arxiv.org/pdf/2501.15654

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

#117

Post by kbelder »

Seattle3503 wrote: post #116
kbelder wrote: post #111

Earlier quoted context omitted.

I always got voted down when I posted the evaluation of the parent articles I got from my Ouija board. I just want to help people understand whether they should just reject bad articles, without having to bother reading them. I'm moving on to evaluating articles with a modified lie detector test and tarot cards, I'm sure that'll help my credibility and give my public rejections more authority.

Do you have evidence Pangram is unreliable? There are independent evaluations [1, 2] showing it works, and it's getting used more and more scientific papers. Have you used it or evaluated it yourself? What do you think these other evaluators are doing or getting wrong? 1: https://bfi.uchicago.edu/insights/artificial-writing-and-aut... 2: https://arxiv.org/pdf/2501.15654

I don't doubt that those detectors are generally correct. Pangram seems to be particularly accurate. I see independent evaluations ranging from 97% accurate to over 99%. Frankly, I somewhat doubt those numbers, but I do agree that LLM usage can be fairly accurately detected.

But procedurally, there are huge issues involved with automated tools used to harm other people. You are one of the 0.5% percent of people whose article was flagged as LLM-generated when it wasn't, one of the false positives. What do you do? Argue? The accusers will claim that you're 99.5% likely to be lying.

It's the same issue we have with automated customer service, automated insurance claims, and so forth. It is usually correct, and terrifically unjust when it fails... at which point there is no recourse. In a perverse sense, its accuracy can be a drawback, because if the false positive rate low enough, nobody is going to believe you when you're falsely accused. And people will be falsely accused.

I think it's ironic that it seems like it capitalizes on the same flaw that most LLM-posting does... "Chat GPT is usually right, I'm going with it." You shouldn't post an LLM article without independently validating its claims, so that there is a responsible person in the loop. The same is true for rejections and accusations, but more so, because they're more damaging.

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

#118

Post by phire »

adrian_b wrote: post #57
phire wrote: post #15

Earlier quoted context omitted.

I think the Pentium is more or less the first microprocessor with branch prediction. Certainly the most mainstream. PowerPC 601 arrived at more or less the same time, and the Alpha 21064 was a year earlier. There were a few minicomputers and mainframes before that with branch predictors. Arguably the 486 could have done with a branch predictor (even a single entry loop predictor would have helped), and maybe the 386…

Pentium was the first CPU with a branch predictor that many people could afford to buy. Before dynamic branch prediction, where the prediction for every branch is updated after each branch execution, depending on its history, static branch prediction had been used for decades, since around 1960, typically using the rule that forwards branches are unlikely to be taken, but backwards branches are likely to be taken. An…

> Before dynamic branch prediction... static branch prediction had been used for decades.

I'm not sure that's true. At least not the "predict backwards branches are taken" part.

Many RISC cpus did kind of have "predict forwards as not taken", but really thats just speculative execution with the complete absence of any branch prediction at all. IMO "All branches are not taken" is not a prediction.

Actual Static Branch prediction is something that seems to have shown up at the exact same time as dynamic branch prediction (ie Pentium and PowerPC 601). Seems to be more of a "well do speculative execution now, what do we do when there is no dynamic prediction?" thing.

Maybe there is a multi-chip CPU out there that has proper static prediction but not dynamic? But I checked the likely candidate (The RS/6000 aka POWER1) and it doesn't have any prediction at all (just a hole where the static prediction bits will go later). Probably because static prediction requires support for speculative execution, which it doesn't do.

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

#119

Post by Seattle3503 »

kbelder wrote: post #117
Seattle3503 wrote: post #116

Earlier quoted context omitted.

Do you have evidence Pangram is unreliable? There are independent evaluations [1, 2] showing it works, and it's getting used more and more scientific papers. Have you used it or evaluated it yourself? What do you think these other evaluators are doing or getting wrong? 1: https://bfi.uchicago.edu/insights/artificial-writing-and-aut... 2: https://arxiv.org/pdf/2501.15654

I don't doubt that those detectors are generally correct. Pangram seems to be particularly accurate. I see independent evaluations ranging from 97% accurate to over 99%. Frankly, I somewhat doubt those numbers, but I do agree that LLM usage can be fairly accurately detected. But procedurally, there are huge issues involved with automated tools used to harm other people. You are one of the 0.5% percent of people whose…

Hold on, let's not move the goalposts yet. Do you still consider Pangram on par with a "Ouija board" or "tarot cards"?

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

#120

Post by altmanaltman »

mynameisash wrote: post #105
grey-area wrote: post #44

Earlier quoted context omitted.

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...

A page shows up in the Wayback Machine when it indexes it for the first time. The website itself goes back a lot if you look at the time. Here is a wayback machine link of a blog post from 2015 which got archived in 2017 for the first time (https://web.archive.org/web/20170607071648/http://greyblake....). Again, if you want to make an intelligent argument, at least know what you're talking about.
Post reply on HN