Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007673OCamlplatform support (windows, cross-compilation, etc)public2017-11-17 13:352018-11-09 14:09
Assigned To 
PrioritylowSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007673: Vastly different performance for "exp" across Windows ports
DescriptionThe micro benchmark below show radically different performance between the 2 64-bit native Windows ports.

   msvc64: 1.4s
   mingw64: 3.7s

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):

   msvc64: 4.3s
   mingw64: 1.6s

And for "cos" instead of "exp":

   msvc64: 1.6s
   mingw64: 4.2s

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))
  Printf.printf "%f\n%!" (!s /. float n)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
frisch (developer)
2017-11-17 13:37

Relevant discussion: [^]
frisch (developer)
2017-11-17 13:41

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.
xleroy (administrator)
2017-11-17 19:18

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.
frisch (developer)
2017-11-20 10:56
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".

frisch (developer)
2018-11-09 14:09

The topic of plugging alternative math libraries is being discussed on [^]

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker