5 ms·

Is this abstraction zero-cost? What's the overhead? Can you give me a similar set of primitives to manipulate memory in a temporally safe manner as well? What

by munin 10y ago

Is this abstraction zero-cost? What's the overhead? Can you give me a similar set of primitives to manipulate memory in a temporally safe manner as well? What is the cost of that abstraction? How does it compare to a runtime's GC?

civility 10y ago
> Is this abstraction zero-cost? What's the overhead? It will cost a single correctly predicted branch, which is effectively free on modern architectures. Any "safe" language will have to make this conditional branch too (Rust's File::read method will check the size of the slice).
- Ericson2314 10y ago
  Nope. Iterators in Rust can be used to safely avoid bounds checking in ways that would be impossible to enforce in C.
  - civility 10y ago
    We were talking about reading into a bounds checked array. Rust does not user iterators for this.
    - Ericson2314 10y ago
      I cannot trust people to correctly iterate in order through an array in C, and thus must resort to bounds checking them.
      - civility 10y ago
        This still has nothing to do with what I've said. Take care.
lacampbell 10y ago
I never made the argument that you shouldn't use a safe GC'd language. I merely made the argument (now flagged for whatever reason) that buffer overflows are an easily solvable issue in C, and if you are having issues with them you really need up your game and learn to create abstractions. As for the cost of the abstraction of bound checked arrays of arbitrary length, I can't imagine it being any slower than rust. I could be wrong. If you'd care to provide an example program in whatever language you are advocating, I can give you an implementation in C using a bounds checked array ADT, and we can compare notes.
- jdmichal 10y ago
  Obviously, if you have to check an index length you're going to be doing a branch. However, because the index checks are intrinsic to the Rust compiler, it can remove them when it proves the code is safe. So, for instance, an iteration loop over an array won't have any index checks in the generated machine code.
  - dbaupp 10y ago
    There's two problems with this statement: - index checks aren't intrinsic for all cases where it is done, e.g. https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb81323142fc5dbe6ae8813c0/src/libcore/slice.rs#L610-L618 https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb8132... - being intrinsic is absolutely not required for the checks to be removed. Bounds checks are just a normal branch with a fairly straight-forward condition, and the always-true nature of those conditions is inferred in the same way for both the built-in indexing and non-built-in indexing. This is true in languages other than Rust. An iterator is designed to just not do any indexing at all (neither using the built-in [] operator or one of the functions that implements manual bounds checks), because it instead just manually (unsafely) walks a pointer along the array.
    - jdmichal 10y ago
      > An iterator is designed to just not do any indexing at all (neither using the built-in [] operator or one of the functions that implements manual bounds checks), because it instead just manually (unsafely) walks a pointer along the array. It obviously still has to bound-check that it's not about to walk right out of the array. If you want to call this something other than a "bound-check", I think that's being overly pedantic.

by munin 10y ago

civility 10y ago

> Is this abstraction zero-cost? What's the overhead? It will cost a single correctly predicted branch, which is effectively free on modern architectures. Any "safe" language will have to make this conditional branch too (Rust's File::read method will check the size of the slice).

Ericson2314 10y ago
Nope. Iterators in Rust can be used to safely avoid bounds checking in ways that would be impossible to enforce in C.
- civility 10y ago
  We were talking about reading into a bounds checked array. Rust does not user iterators for this.
  - Ericson2314 10y ago
    I cannot trust people to correctly iterate in order through an array in C, and thus must resort to bounds checking them.
    - civility 10y ago
      This still has nothing to do with what I've said. Take care.

lacampbell 10y ago

I never made the argument that you shouldn't use a safe GC'd language. I merely made the argument (now flagged for whatever reason) that buffer overflows are an easily solvable issue in C, and if you are having issues with them you really need up your game and learn to create abstractions. As for the cost of the abstraction of bound checked arrays of arbitrary length, I can't imagine it being any slower than rust. I could be wrong. If you'd care to provide an example program in whatever language you are advocating, I can give you an implementation in C using a bounds checked array ADT, and we can compare notes.

jdmichal 10y ago
Obviously, if you have to check an index length you're going to be doing a branch. However, because the index checks are intrinsic to the Rust compiler, it can remove them when it proves the code is safe. So, for instance, an iteration loop over an array won't have any index checks in the generated machine code.
- dbaupp 10y ago
  There's two problems with this statement: - index checks aren't intrinsic for all cases where it is done, e.g. https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb81323142fc5dbe6ae8813c0/src/libcore/slice.rs#L610-L618 https://github.com/rust-lang/rust/blob/8f62c2920077eb5cb8132... - being intrinsic is absolutely not required for the checks to be removed. Bounds checks are just a normal branch with a fairly straight-forward condition, and the always-true nature of those conditions is inferred in the same way for both the built-in indexing and non-built-in indexing. This is true in languages other than Rust. An iterator is designed to just not do any indexing at all (neither using the built-in [] operator or one of the functions that implements manual bounds checks), because it instead just manually (unsafely) walks a pointer along the array.
  - jdmichal 10y ago
    > An iterator is designed to just not do any indexing at all (neither using the built-in [] operator or one of the functions that implements manual bounds checks), because it instead just manually (unsafely) walks a pointer along the array. It obviously still has to bound-check that it's not about to walk right out of the array. If you want to call this something other than a "bound-check", I think that's being overly pedantic.