News for hackers. Stuff that matters.
Re:Myths about Integer Overflow in Rust by pcwalton on Friday April 29, 2016 @02:28PM (#11597717)
> In practice, for anything which isn't a micro-benchmark, it's a negligible performance hit.

Citation needed? Every paper I've seen has indicated a non-negligible performance hit in real apps.

> I see a strong correlation between people complaining about overflow checking overhead, and people who don't actually care about the safety features

I'm a counterexample.

Re:Myths about Integer Overflow in Rust by nickpsecurity on Friday April 29, 2016 @06:52PM (#11599251)
Parent might mean this:

http://danluu.com/integer-overflow/

It starts with 2x like kibwen says. Then says those ops will only be small part of workload or something. Extrapolating lead to 5%. Article goes on from there.

Not sure if it applies here but it matches the claim you quoted of micro vs macro benchmark.

Re:Myths about Integer Overflow in Rust by vardump on Friday April 29, 2016 @05:08PM (#11598780)
It would be interesting to have support for saturated types as well. u8saturated 200 + u8saturated 200 = 255. That's often desired behavior.

Saturated arithmetic is supported in hardware in SSE. Although not much point if the values need to be constantly shuffled between SSE and scalar registers...

Re:Myths about Integer Overflow in Rust by Manishearth on Friday April 29, 2016 @06:05PM (#11599070)
.saturating_add() exists. You can create a wrapper type around this and implement the Add/Sub/Mul traits.
Re:Myths about Integer Overflow in Rust by vardump on Friday April 29, 2016 @08:10PM (#11599588)
Does it have branchless codegen?
Re:Myths about Integer Overflow in Rust by Manishearth on Friday April 29, 2016 @08:25PM (#11599648)
Not right now (I'm surprised that's the case, there should be intrinsics for it), but that could change.
Re:Myths about Integer Overflow in Rust by dbaupp on Saturday April 30, 2016 @05:07AM (#11601017)
It gets optimised to be branchless if LLVM thinks that will be faster, yes.