Re:Making Rust as Fast as Go
by dan-robertson on Sunday May 03, 2020 @02:48PM
(#23061000)
I suspect that statement is not true for floats. Possibly you don’t get the same float from min(0,-0) as min(-0,0), and similarly with NaNs. Rust specifies that if one input is NaN then the other is returned but doesn’t say what happens if both are NaN.
[ Parent
| on HN ]
Re:Making Rust as Fast as Go
by fluffything on Sunday May 03, 2020 @04:21PM
(#23061569)
> Rust specifies that if one input is NaN then the other is returned but doesn’t say what happens if both are NaN.
It does. If both are NaN a NaN is returned. Note, however, that when Rust says that a NaN is returned, this means that any NaN can be returned. So if you have min(NaN0, NaN0) the result isn't necessarily NaN0, it might be another NaN with a different payload.
Re:Making Rust as Fast as Go
by dan-robertson on Sunday May 03, 2020 @06:13PM
(#23062290)
Right. That’s what I was getting at but I didn’t know the NaN-return rule.
Hmm, not sure what the llvm semantics look like, but you're right about the assembly semantics, vminsd (the instruction used in the post) is unfortunately not symettric in it's handling on NaN.
Re:Making Rust as Fast as Go
by londons_explore on Sunday May 03, 2020 @04:11PM
(#23061500)
NaN's are rarely required on the fast path of any code... The compiler ought to make a 2nd slow implementation for if any NaNs are seen.
Re:Making Rust as Fast as Go
by fluffything on Sunday May 03, 2020 @04:22PM
(#23061575)
Sure, but then it needs to add a branch to detect the inputs, and maybe keep around some state to switch between implementations at run-time.
Its far from clear that doing that is, in general, worth it.