-
Notifications
You must be signed in to change notification settings - Fork 22
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
turn on parallel Eigen #793
Comments
In the parallel_eigen branch, I've inserted I don't think we need to insert OTOH, there is presumably no downside to enabling |
One other comment is that Eigen's parallelization seems limited. As of Eigen 3.3.5:
So turning on parallelization will probably not help end users by and large. |
Testing indicates an issue with Also not clear that Writing R extensions section 1.2.11 indicates one should use SHLIB_OPENMP_CXXFLAGS in Makevars* files. I've now implemented this, but on one of my Macs, -fopenmp is being injected despite seeming to not be supported. Perhaps this means R was configured incorrectly (though I think I did a basic R install on that machine). But we should be cautious here for fear of breaking users' use of nimble if they don't have openMP support. Side note: users can also do this at run time if their compiler supports openMP:
Cautionary note from Writing R extensions: Note that the macro SHLIB_OPENMP_CXXFLAGS applies to the default C++ compiler and not necessarily to the C++11/14/17 compiler: users of the latter should do their own configure checks (an example is available in CRAN package ARTP2). |
Ok, so this is failing on two separate Macs. -fopenmp is being injected into the clang++ call and that is erroring out with an "unsupported option '-fopenmp'" error. This thread seems to be relevant, but I'm not understanding everything there (in particular the discussion is really about Travis). |
On SCF Mac, SHLIB_OPENMP_CXXFLAGS seems to be set to "-fopenmp" in: /Library/Frameworks/R.framework/Versions/3.4/Resources/etc/Makeconf Unfortunately if one then sets the following in a local Makevars:
as per Nimble's inst/make/Makevars, then compilation fails. Unclear why "-fopenmp" is set given openMP seemingly can't be successfully used. |
My current thought is that at run-time we want to set -fopenmp if openMP is available to user via the local Makevars in nimble_generatedCode. Why?
Plan - look at how dynamicRegistrations stuff is done and how we write Makevars in nimble_generatedCode. We might set a nimbleOption the first time compilation is done based on querying the user's system to see if -fopenmp can be used and then at subsequent times in a given R session, use the nimbleOption. Not clear on the following:
|
It would probably be good to allow for the nimbleOption to behave such that users could turn on or off -fopenmp as they prefer and we won't override that. So the options might be: auto/on/off where auto is that we detect. So there might be a user-facing option and then the option that actually says whether openMP is on for a given user session so we don't have to keep testing whether -fopenmp works. |
We should do this for next release.
The text was updated successfully, but these errors were encountered: