|Anonymous | Login | Signup for a new account||2019-01-22 13:03 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007673||OCaml||platform support (windows, cross-compilation, etc)||public||2017-11-17 13:35||2018-11-09 14:09|
|Priority||low||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0007673: Vastly different performance for "exp" across Windows ports|
|Description||The micro benchmark below show radically different performance between the 2 64-bit native Windows ports.|
And this is with VS2008, it does'nt even benefit from recent improvements to the msvc runtime. I don't know which implementation of exp is used for mingw64 (does it come from msvcrt.dll?).
Removing the "mod 4" results in oppositive rankings (perhaps because the calculation involves +inf):
And for "cos" instead of "exp":
I'm not sure OCaml can do anything specific about it (except ship its own implementation of numerical functions), but just to document the issue and perhaps gather possible simple fixes. Considering how important "exp" can be in some numerical code, knowing about the performance difference might be useful...
|Steps To Reproduce|
let () = let s = ref 0. in let n = 100000000 in for j = 1 to n do s := !s +. exp (float (j mod 4)) done; Printf.printf "%f\n%!" (!s /. float n)
|Tags||No tags attached.|
|I'm not saying you must really do so, but the discussion suggests that explicitly calling the exp function from msvcrt.dll (which mingw64 depends upon anyway) would indeed improve performances quite a bit.|
|Well, sure, there exists several implementations of libm (the C FP library) that differ in performance and often in precision of the results as well. If the libm that ships with mingw is bad -- and it looks like it is on the slow side indeed -- that's something to report to the mingw people, not here, and to work out with them. It is unreasonable to expect OCaml to have its own libm or to depend on another libm than that provided by the C compiler.|
edited on: 2017-11-20 10:57
I'm not suggesting to add a dependency to another libm. Possible directions:
- Simply document the problem (in README.win32.adoc).
- Arrange so that the mingw64 port uses the implementation of exp (and others) from msvcrt.dll (the generated programs already depends on it anyway). (Or give an option to do so.)
- Make it easier for users to provide a custom implementation of the function.
> that's something to report to the mingw people, not here, and to work out with them
The link I posted in the previous note shows that the problem is "well-known".
|The topic of plugging alternative math libraries is being discussed on https://github.com/ocaml/ocaml/pull/944 [^]|
|2017-11-17 13:35||frisch||New Issue|
|2017-11-17 13:37||frisch||Note Added: 0018666|
|2017-11-17 13:41||frisch||Note Added: 0018667|
|2017-11-17 19:18||xleroy||Note Added: 0018668|
|2017-11-17 19:18||xleroy||Status||new => acknowledged|
|2017-11-20 10:56||frisch||Note Added: 0018673|
|2017-11-20 10:57||frisch||Note Edited: 0018673||View Revisions|
|2018-11-09 14:09||frisch||Note Added: 0019438|
|Copyright © 2000 - 2011 MantisBT Group|