Compilation flags

[Matt Espe]

Hi all,

I was wondering if anyone has experience with providing different compilation flags for building packages with C/C++ code. The defaults (on my machine) are -O2, -march=x86-64, and -mtune=generic. I have noticed benefits with other programs using -march=native and -O3, but the scary warning in the R documentation of "incorrect numeric computations" suggests -O3 might not be worth it.

Just curious if anyone has dug into this, and if so, did you notice a performance benefit? Or was it not really worth it?

Thanks,

Matt

[Jaime Ashander]

I add O3 but haven't fooled with mtune

I haven't noticed that warning or strange behavior (either with Stan or my own cpp code). Where does it appear?

- Jaime

--
Check out our R resources at http://d-rug.github.io/
---
You received this message because you are subscribed to the Google Groups "Davis R Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to davis-rug+...@googlegroups.com.
Visit this group at https://groups.google.com/group/davis-rug.
For more options, visit https://groups.google.com/d/optout.

[Matt Espe]

I believe Rstan overrides R's defaults by, um, default to be -O3 and -march=native.

Have you tested for issues with your own cpp code, or just have not noticed catastrophic errors? My understanding is the numerical issues can be a bit tricky to catch. 

Also, what motivated you to add O3? Have you seen a benefit? 

Matt

[Matt Espe]

Oh, and the warning is in the documentation:

https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Compilation-flags

Matt

On Friday, September 23, 2016 at 1:56:18 PM UTC-7, Jaime Ashander wrote:

[Jaime Ashander]

Stan is noticeably faster for some models. IIRC my own numerical code was notably faster too.

I meant no catastrophic errors. I haven't really tested explicitly for something more subtle, but I my tests were passing under both (thought I didn't check for this every time). If you're concerned, you could 1) write code and tests that produce reference objects, 2) install under normal Makevars and produce the references, 3) install under modified Makevars and see if the tests pass. You could also output timing to compare...

For examples of these kinds of tests* and the code I was using see https://github.com/ashander/phenoecosim I may try to do the steps 1-3 with this package later.

* maybe they're bad examples, I just installed and ran my code and the `expect_` function I'm using from devtools is already deprecated...

To unsubscribe from this group and stop receiving emails from it, send an email to davis-rug+unsubscribe@googlegroups.com.

[Matt Espe]

Hmm - I was wrong, it seems Rstan preserves the R makevars (I think there was some talk about changing this, but it seems it has not happened... It has been a while since I used Rstan).

Are you concerned that your work might not be reproduced by someone running the default configuration? In your papers/etc, do you document that you changed the optimization level for compilation? 

I think it can be a bit of a rabbit hole once you start talking about architectures, compilers, etc., but as I give this more thought I am thinking it might be a bad idea to change the compilation flags from their default from a reproducibility standpoint (unless you are going the full Docker route). As you say, the only way to know the results are the same is to run both and compare them, at which point the quest to save time at run is outweighed by running the same piece of code twice. 

I guess that took a philosophical turn, but question answered.

Matt

[Jaime Ashander]

ok, I also haven't worked with Rstan in a bit. rstan used to allow the change (which explains why rstan::set_cppo exists). but best practices have changed. good to know!

the points you raise on reproducibility are good. in my case, ultimately I did run the production code on docker (because of other dependency issues) and without -O3. 

- Jaime