-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some floating point math functions produce different results on windows #1222
Comments
Making them behave identical across platforms will incur a performance penalty for some calls on some platforms. I think that this is not acceptable for performance critical calls like pow(). This leaves us with three alternatives: (a) define the deviating behavior as officially undefined and thereby push the burden of handling this to the user (b) use our own implementation of floating point ops, perhaps by incorporating some C math library directly into the rust runtime or at least allowing easy integration with a common math library (c) complete implementation of libm in rust. This would be very nice but also very much work and requires someone who knows how to write fast numeric code. For case (b), this is a list of possible candidates from a quick search |
Are there any numbers for the cost of such platform-independent code? I think having platform-independent code in the standard library is crucial. CRlibm seems out of question, giving its LGPL license. See also http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplacingGMPastheBignumlibrary |
Well, I did not measure this but it certainly would require a series of extra compares or at least a switch per call. This means the costs are at least an extra compare and an extra jump, if not more, and will negatively impact branch prediction. For some calls, this may be unacceptable in inner loop code and make rust on that particular platform suffer unduely in terms of raw performance. Unless somebody finds a suitable version of libm, I would actually tend towards (a) for now, and aim for (c) later. |
Just found this: Hmm maybe it would be enough to have a configure option for switching the libm in use for now? |
re-nominating well-covered, not production-ready |
accepted for well-defined milestone |
accepted for production-ready milestone |
1 similar comment
accepted for production-ready milestone |
This is caused by mingw's implementations of these functions being incomplete on Windows. |
So this is #8663, right? |
Not 1.0, high |
Fixed by the move to mingw-w64. |
Mostly dealing with NaN and infinity. See stdtest/math.rs. Some of the tests are commented out because they produce different results on windows.
Since they are just wrappers around the C functions it's not clear whether we should tolerate the differences or try to be consistent. I'm inclined to make them all behave the same on any platform.
The text was updated successfully, but these errors were encountered: