Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am a Rust fan, but 10% degradation in performance (29ms to 33ms) is not "a pretty small change" nor "within noise threshold". If the accuracy of the tests are +/- 10% then that needs to be proven and then fixed. I didn't see any evidence in the article that there is, in fact, a 10% error, and it looks like there is a genuine 10% drop in performance.


To be clear, removing the bounds checks led to the observed performance degradation. Your statement beginning with "I am a Rust fan, but..." suggests that you might have interpreted it as the other way around


I certainly did. Thank you for pointing that out. That suggests then that the problem is the tests are bogus.


a 10% drop in performance with bounds checks removed, mind you - so if anything the bounds checks are improving performance.


The more likely explanation is that the test is bunk.

Or maybe the unsafe access acts like volatile in C and disables any optimization/reordering because the compiler thinks it’s accessing a register.


Unsafe accesses do not act that way, they compile to exactly the same code as array accesses in C.

The tests aren't bunk. There are a variety of reasons why the assertions generated by array index checks can be useful for LLVM, and there is also a fair amount of noise in any end to end test like this. The main point is that it clearly isn't a primary bottleneck (which should be pretty obvious in a test that takes 30 ms and performs under 2000 bounds checks).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: