News for hackers. Stuff that matters.
Re:The case against a C alternative by logicchains on Tuesday August 09, 2022 @05:42AM (#32395860)
Rust does runtime bounds checks on array access, which the compiler can't elide in non-trivial cases (e.g. binary search), so if you want to write such algorithms as fast as in C, you need to use a lot of unsafe array indexing.
Re:The case against a C alternative by kaba0 on Wednesday August 10, 2022 @05:48AM (#32409645)
I would be interested in how big of a difference does it make — these branches will always go one way, so they are trivial to branch predict. Other than very slightly increasing the code size (which can have a big effect if the i cache is no longer sufficient), I fail to see it doing too badly as is.
Re:The case against a C alternative by bitcharmer on Tuesday August 09, 2022 @09:23AM (#32397478)
You might be referring to slices. Arrays in rust have to have a known length at compile time.
Re:The case against a C alternative by masklinn on Tuesday August 09, 2022 @09:26AM (#32397523)
Rustc may still need to do runtime bounds check if it can’t conclude that a dynamically computed index is in-bounds.

The length is known statically, but whether the index is in-bounds may not be.

The binary search GP talks about is exactly one such case, go on Godbolt, write up a simple binary search (with a static size so you get code), and you’ll see that the compiler checks against the literal array size on every iteration.

Re:The case against a C alternative by bitcharmer on Tuesday August 09, 2022 @01:26PM (#32400938)
I have no idea how I totally missed that from the GP's comment. Thanks for correcting me.