It was fun to read and insightful for me, not too artificial, and not too verbose.
I'm glad my internal AI detector doesn't win over my curiosity to learn.
It was fun to read and insightful for me, not too artificial, and not too verbose.
I'm glad my internal AI detector doesn't win over my curiosity to learn.
The main problem with the article is that the idea to influence backend code generation decisions via specific highlevel code constructs is mostly just mystical bullshit (some compilers do detect specific patterns - usually for bit twiddling hacks, but not on a basic level like control flow optimization).
Using a highlevel language construct like "y += (x > 0) as usize;" doesn't "switch on" branchless code just because the source code looks branchless, compilers are not that dumb anymore.
E.g. I bet that writing
...generates the exact same code after optimization, otherwise I would consider that an LLVM bug.The only reliable way is to mostly bypass the optimizer via simd intrinsics, or drop down to assembler, everything else is just cargo culting.
(fwiw I can't shake the feeling now that the article is recycled, I'm pretty sure I saw those exact same code examples in another "branchless" blog post, but maybe for a different language - because the next question was ineviatably "then why is the code using "if" slower? answer: because it also behaves differently). Or maybe I'm just having a strong dejavu ;)
PS:
> fwiw I can't shake the feeling now that the article is recycled
Ok, I remembered wrong. The article I remembered was this: https://tiki.li/blog/blqsort
HN link: https://news.ycombinator.com/item?id=48375445
It's peddling the exact same myth though.
And, on some architectures, y+=(x>0) is branchful!