GC & memory safety vs. overflow checks on arithmetic, which is slower in terms of throughput? I suspect overflow checks are slower.
(These might seem unrelated, but they are not: memory safety makes most [not all] integer overflows unweaponizable.)
Conversation
Replying to
do you know of any real world bugs where an overflow would’ve still been exploitable with memory safety? just curious to read about it
3
1
Integer overflows in cryptography can often be exploitable. Can also simply have bugs in the application logic in ways that are exploitable. Plenty of those kinds of bugs in video games among other areas. Most of them aren't exploitable with memory safety but a few still are.
1
1
Bounds checks are usually cheap when they don't interfere with loop unrolling, vectorization and other loop optimizations. It's implied that you're doing memory reads/writes so it usually won't have much impact. It can certainly push you beyond certain CPU cache/predictor limits.
1
1
Integer operations are everywhere and existing compilers are terrible at optimizing out, hoisting or combining the checks. Bounds + overflow checks everywhere add up to a fairly high cost. Rust has very careful/rare use of unchecked ops in libraries to reduce bounds overhead.
1
2
By reusing those libraries including heavily using iterators, a lot of that gets avoided without depending on unreliable optimizations. LLVM is great at inlining and a few obvious optimizations but ridiculously bad as soon as there are pointers or anything needing range analysis.
Also if you expect the compiler to optimize them well, then each of the checks is ideally identical so that they jump to the same error handler without any state and then the compiler actually has a chance to combine them. LLVM and GCC are terrible at combining them though.
1
1
Show replies