5 ms·

It's off by default in production because all those overflow checks add up (hah). Rust's first priority has always been low-level/systems code, where these thin

It's off by default in production because all those overflow checks add up (hah). Rust's first priority has always been low-level/systems code, where these things matter. It (semi-controversially) makes runtime bounds checks despite that priority, because they're so important to memory safety, but with that guard-rail numeric overflows become less important- they can only cause logic bugs, not safety issues, so it makes sense to me that performance would then be prioritized by default

stouset 4y ago
Also, thanks to the language, most bounds checks can be elided in practice with idiomatic code. This isn’t as often the case with arithmetic operations. I do wish there was a(n optional) clippy lint to warn against non-explicit integer arithmetic operations though.
twic 4y ago
What do they add up to? You can turn overflow checks on in release mode with -C overflow-checks=on, so it feels like it should be really easy to benchmark the current impact. I couldn't find any benchmarks doing this, though.
- brundolf 4y ago
  I'm sure it varies wildly by the type of program, and I'm sure much smarter people than me on the Rust team did their benchmarking homework when they originally made the choice. Just saying that to me, it seems like a reasonable default
  - throwaway81523 4y ago
    It seems like a seriously wrong default for a language whose story is supposed to be safety. People wanting unsafe languages already have C and C++ for that :/.
    - brundolf 4y ago
      Explained here: https://news.ycombinator.com/item?id=34514947 https://news.ycombinator.com/item?id=34514947
    - twic 4y ago
      To improve safety at large, Rust has to displace C++. People use C++ in part because of its speed (rightly or wrongly - but it is undeniably part of C++ culture). A language which is consistently slower than C++ will not displace C++. So, this was a point where the designers decided to hold their nose for now.
- dahfizz 4y ago
  I just did a very un-scientific benchmark to test this. I chose ripgrep as a conservative choice, since most of the time should be I/O anyway. I grepped for the word "Jesus" in a file that contained 100 copies of the king james bible (426MB of text). I ran it 100 times and averaged the results. Timed with /usr/bin/time. --release without overflow checking was 0.0702 seconds on average. --release with overflow checking was 0.0727 seconds, or about 3.5% slower That's more than I expected for a program that's I/O bound.
  - burntsushi 4y ago
    ripgrep author here. > That's more than I expected for a program that's I/O bound. Based on your description of your methodology and a reasonable assumption that you have more than ~426MB of available RAM, your benchmark is absolutely not I/O bound. Or at least, not bound by the speed of your disk. In your benchmark, your haystack is almost certainly entirely within memory and served from your operating system's page cache. It's unlikely you're hitting disk at all. And even if you constructed your benchmark such that every search flushed your cache first and forced re-reading the file from disk, it may or may not be I/O bound. If your disk gives you 6 GB/s read speeds, you gotta do better than a traditional finite state machine to match that speed. (That is, probably SIMD.)
    - dahfizz 4y ago
      Very true! I wouldn't expect any blocking IO here (except for the first run). I would still expect the majority of the time be spent reading from memory vs CPU bound "number crunching". I should have been clearer. In my day job we are latency sensitive and we'll refer to excessively hitting main memory as being IO bound.
      - burntsushi 4y ago
        Your query might be memory bound, but might not be. You've got to attain very high speeds to be memory bound. In your case, you chose a query that likely matches quite frequently, no? If so, it's certainly not going to be memory bound because of the overhead of dealing with all those matches. Try a literal that doesn't match or matches very rarely and you'll have a better shot at being limited by memory bandwidth. (But still maybe not.)
throwaway81523 4y ago
Of course the int overflows can cause safety issues. We're talking about Git CVE's regarding exactly that, after all. It's true that the int overflow checks incur overhead (has anyone measured it?). RISC-V missed the boat in not giving a hardware trap for it.
- brundolf 4y ago
  Indexing into an array or vec will always be checked in safe Rust, so if an overflow gives you a bad index you'll just get a panic (or an Option::None if you decided to access it that way); never a safety issue
  - throwaway81523 4y ago
    Indexes are only checked for being outside the array, not for being wrong. Getting a[3] when you wanted a[5] is a bug, potentially a serious or dangerous one. SPARK Ada goes to great lengths to statically verify that there are no int overflows in the code that it checks, and Ada itself specifies trapping overflow, though as an "optimization", the overflow check is often disabled. OCaml also checks overflow for its machine int type. GHC doesn't, and that seems like a mistake.
    - brundolf 4y ago
      "Safety" means a specific thing here, and whatever bugs might happen with this, they do not make the code "unsafe" It also helps that, in practice, when writing idiomatic Rust you'll almost always be accessing array/vec members using an iterator. Direct indexing is uncommon, which means indexing bugs specifically are very uncommon. Of course that's not the only bug that overflows can cause, but it's a big one. Not every bug can be prevented by the language (at compile time or runtime). You have to make some choices about which things are just in the programmer's hands, and I think Rust has struck a reasonable balance. Especially since the user can always choose differently in this case, and just compile their code with `overflow-checks = true`

stouset 4y ago

Also, thanks to the language, most bounds checks can be elided in practice with idiomatic code. This isn’t as often the case with arithmetic operations. I do wish there was a(n optional) clippy lint to warn against non-explicit integer arithmetic operations though.

twic 4y ago

What do they add up to? You can turn overflow checks on in release mode with -C overflow-checks=on, so it feels like it should be really easy to benchmark the current impact. I couldn't find any benchmarks doing this, though.

brundolf 4y ago
I'm sure it varies wildly by the type of program, and I'm sure much smarter people than me on the Rust team did their benchmarking homework when they originally made the choice. Just saying that to me, it seems like a reasonable default
- throwaway81523 4y ago
  It seems like a seriously wrong default for a language whose story is supposed to be safety. People wanting unsafe languages already have C and C++ for that :/.
  - brundolf 4y ago
    Explained here: https://news.ycombinator.com/item?id=34514947 https://news.ycombinator.com/item?id=34514947
  - twic 4y ago
    To improve safety at large, Rust has to displace C++. People use C++ in part because of its speed (rightly or wrongly - but it is undeniably part of C++ culture). A language which is consistently slower than C++ will not displace C++. So, this was a point where the designers decided to hold their nose for now.
dahfizz 4y ago
I just did a very un-scientific benchmark to test this. I chose ripgrep as a conservative choice, since most of the time should be I/O anyway. I grepped for the word "Jesus" in a file that contained 100 copies of the king james bible (426MB of text). I ran it 100 times and averaged the results. Timed with /usr/bin/time. --release without overflow checking was 0.0702 seconds on average. --release with overflow checking was 0.0727 seconds, or about 3.5% slower That's more than I expected for a program that's I/O bound.
- burntsushi 4y ago
  ripgrep author here. > That's more than I expected for a program that's I/O bound. Based on your description of your methodology and a reasonable assumption that you have more than ~426MB of available RAM, your benchmark is absolutely not I/O bound. Or at least, not bound by the speed of your disk. In your benchmark, your haystack is almost certainly entirely within memory and served from your operating system's page cache. It's unlikely you're hitting disk at all. And even if you constructed your benchmark such that every search flushed your cache first and forced re-reading the file from disk, it may or may not be I/O bound. If your disk gives you 6 GB/s read speeds, you gotta do better than a traditional finite state machine to match that speed. (That is, probably SIMD.)
  - dahfizz 4y ago
    Very true! I wouldn't expect any blocking IO here (except for the first run). I would still expect the majority of the time be spent reading from memory vs CPU bound "number crunching". I should have been clearer. In my day job we are latency sensitive and we'll refer to excessively hitting main memory as being IO bound.
    - burntsushi 4y ago
      Your query might be memory bound, but might not be. You've got to attain very high speeds to be memory bound. In your case, you chose a query that likely matches quite frequently, no? If so, it's certainly not going to be memory bound because of the overhead of dealing with all those matches. Try a literal that doesn't match or matches very rarely and you'll have a better shot at being limited by memory bandwidth. (But still maybe not.)

throwaway81523 4y ago

Of course the int overflows can cause safety issues. We're talking about Git CVE's regarding exactly that, after all. It's true that the int overflow checks incur overhead (has anyone measured it?). RISC-V missed the boat in not giving a hardware trap for it.

brundolf 4y ago
Indexing into an array or vec will always be checked in safe Rust, so if an overflow gives you a bad index you'll just get a panic (or an Option::None if you decided to access it that way); never a safety issue
- throwaway81523 4y ago
  Indexes are only checked for being outside the array, not for being wrong. Getting a[3] when you wanted a[5] is a bug, potentially a serious or dangerous one. SPARK Ada goes to great lengths to statically verify that there are no int overflows in the code that it checks, and Ada itself specifies trapping overflow, though as an "optimization", the overflow check is often disabled. OCaml also checks overflow for its machine int type. GHC doesn't, and that seems like a mistake.
  - brundolf 4y ago
    "Safety" means a specific thing here, and whatever bugs might happen with this, they do not make the code "unsafe" It also helps that, in practice, when writing idiomatic Rust you'll almost always be accessing array/vec members using an iterator. Direct indexing is uncommon, which means indexing bugs specifically are very uncommon. Of course that's not the only bug that overflows can cause, but it's a big one. Not every bug can be prevented by the language (at compile time or runtime). You have to make some choices about which things are just in the programmer's hands, and I think Rust has struck a reasonable balance. Especially since the user can always choose differently in this case, and just compile their code with `overflow-checks = true`