3 ms·
> Not necessarily in the "safer"/default mode, but it needs to have an unsafe, turn-off-all-checks-run as fast as you can mode. By design, Rust allows you to o
by dbaupp 12y ago
> Not necessarily in the "safer"/default mode, but it needs to have an unsafe, turn-off-all-checks-run as fast as you can mode.
By design, Rust allows you to opt-in to this mode locally via `unsafe { ... }`; this allows you to be 100% safe through the vast majority of the code base, but then eek out the very last drop of performance in core routines where there's no safe alternative. Then only those regions need to be checked for memory safety vulnerabilities rather than the whole codebase.
Although, many things can be written in safe code and still be performant: iterators provide safe and highly efficient sequential access to vectors and arrays (right now they optimise to the same code as the equivalent C/C++, other a bug in LLVM where it's not recognising that some pointers are guaranteed to be nonnull).
- masklinn 12y ago> By design, Rust allows you to opt-in to this mode locally via `unsafe { ... }`; It should be noted that contrary to e.g. Swift's -Ofast, Rust's unsafe {} does not change language semantics. It allows operations marked as unsafe (non-bounds-checked array accesses, raw pointer and pointer munging, etc…) but operations usable outside unsafe {} have the exact same semantics inside.