4 ms·

> Not having a switch to disable bounds checking is not the same as not being able to disable bounds checking. Not sure what you're getting at. Marking the ent

> Not having a switch to disable bounds checking is not the same as not being able to disable bounds checking. Not sure what you're getting at. Marking the entire program as unsafe is not realistic. Marking specific portions leaves a long tail of code that "rarely" runs, but still adds up. > Those are benchmarks of the built-in library random number generator. The levgen-benchmarks programs implement the XOR-shift RNG in both the Rust and D versions.

deleted 11y ago
[deleted]
pcwalton 11y ago
> but still adds up. No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). Even bounds checks in hot code frequently don't matter. Have you profiled Rust code and found bounds checks to be a problem? > The levgen-benchmarks programs implement the XOR-shift RNG in both the Rust and D versions. Oh, I see that they changed it. Still, that benchmark is from 2013 and doesn't compile anymore. It predates unboxed closures and many other performance improvements. And 15% is in the "different register allocation decisions will affect the outcome" range, where comparisons are fairly meaningless. The fact that D and Rust beat C doesn't mean that they're faster than C.
- p0nce 11y ago
  > No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). Even bounds checks in hot code frequently don't matter. Have you profiled Rust code and found bounds checks to be a problem? I've measured some D code yesterday and it was like you said, bounds check didn't change performance which was very suprising (this was for JPEG loading).
CyberShadow 11y ago
I can't reply to pcwalton directly for some reason. In reply to https://news.ycombinator.com/item?id=10139287 https://news.ycombinator.com/item?id=10139287 : > No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). OK, I trust your expertise on this. The "long tail" applies to optimizations in general. I don't know why the benchmarks are slower for Rust then, could be the difference in backends. > The fact that D and Rust beat C doesn't mean that they're faster than C. I don't know what's going on there, but some languages allow writing fast code easier than in C, e.g. SIMD vector array operations.

deleted 11y ago

[deleted]

pcwalton 11y ago

> but still adds up. No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). Even bounds checks in hot code frequently don't matter. Have you profiled Rust code and found bounds checks to be a problem? > The levgen-benchmarks programs implement the XOR-shift RNG in both the Rust and D versions. Oh, I see that they changed it. Still, that benchmark is from 2013 and doesn't compile anymore. It predates unboxed closures and many other performance improvements. And 15% is in the "different register allocation decisions will affect the outcome" range, where comparisons are fairly meaningless. The fact that D and Rust beat C doesn't mean that they're faster than C.

p0nce 11y ago
> No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). Even bounds checks in hot code frequently don't matter. Have you profiled Rust code and found bounds checks to be a problem? I've measured some D code yesterday and it was like you said, bounds check didn't change performance which was very suprising (this was for JPEG loading).

CyberShadow 11y ago

I can't reply to pcwalton directly for some reason. In reply to https://news.ycombinator.com/item?id=10139287 https://news.ycombinator.com/item?id=10139287 : > No, it doesn't. Bounds checks in cold code don't matter (and there aren't many to begin with). OK, I trust your expertise on this. The "long tail" applies to optimizations in general. I don't know why the benchmarks are slower for Rust then, could be the difference in backends. > The fact that D and Rust beat C doesn't mean that they're faster than C. I don't know what's going on there, but some languages allow writing fast code easier than in C, e.g. SIMD vector array operations.