Skip to content
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

Vastly different performance for "exp" across Windows ports #7673

Closed
vicuna opened this issue Nov 17, 2017 · 6 comments
Closed

Vastly different performance for "exp" across Windows ports #7673

vicuna opened this issue Nov 17, 2017 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Nov 17, 2017

Original bug ID: 7673
Reporter: @alainfrisch
Status: acknowledged (set by @xavierleroy on 2017-11-17T18:18:32Z)
Resolution: open
Priority: low
Severity: minor
Category: platform support (windows, cross-compilation, etc)
Monitored by: @gasche

Bug description

The 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))
  done;
  Printf.printf "%f\n%!" (!s /. float n)
@vicuna
Copy link
Author

vicuna commented Nov 17, 2017

@vicuna
Copy link
Author

vicuna commented Nov 17, 2017

Comment author: @alainfrisch

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.

@vicuna
Copy link
Author

vicuna commented Nov 17, 2017

Comment author: @xavierleroy

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.

@vicuna
Copy link
Author

vicuna commented Nov 20, 2017

Comment author: @alainfrisch

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".

@vicuna
Copy link
Author

vicuna commented Nov 9, 2018

Comment author: @alainfrisch

The topic of plugging alternative math libraries is being discussed on #944

@github-actions
Copy link

github-actions bot commented May 7, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 7, 2020
@github-actions github-actions bot closed this as completed Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants