How to ensure -O3 on Win64

On Dec 27, 2012, at 6:08 PM, Matthew Dowle wrote:

On 27.12.2012 17:53, Simon Urbanek wrote:

On Dec 23, 2012, at 9:22 PM, Matthew Dowle wrote:

Hi,

Similar questions have come up before on the list and elsewhere 
but I haven't found a solution yet.

winbuilder's install.out shows data.table's .c files compiled with 
-O3 on Win32 but -O2 on Win64. The same happens on R-Forge. I gather 
that some packages don't work with -O3 so the default is -O2.

I've tried this in data.table's Makevars (entire contents) :

====
MAKEFLAGS="CFLAGS=-O3"                        # added
CFLAGS=-O3                                    # added
PKG_CFLAGS=-O3                                # added
all: $(SHLIB)                                 # no change
	mv $(SHLIB) datatable$(SHLIB_EXT)     # no change
====

but -O2 still appears in winbuilder's install.out (after -O3, and 
I believe the last -O is the one that counts) :

gcc -m64 -I"D:/RCompile/recent/R-2.15.2/include" -DNDEBUG     
-I"d:/Rcompile/CRANpkg/extralibs215/local215/include"  -O3   -O2 
-Wall -std=gnu99 -mtune=core2 -c dogroups.c -o dogroups.o

How can I ensure that data.table is compiled with -O3 on Win64?

You can't - at least not in a way that doesn't circumvent the R 
build
system. Also it's not portable so you don't want to mess with
optimization flags and hard-code it in your package as it's user's
choice how they setup R and its flags. You can certainly setup your 
R
to compile with -O3, you just can't impose that on others.

Cheers,
Simon

Thanks Simon. This makes complete sense where users compile packages 
on install (Unix and Mac, and I better check my settings then), but on 
Windows where it's more common for the user to install the 
pre-compiled .zip from CRAN is my concern. This came up because the 
new fread function in data.table wasn't showing as much of a speedup 
on Win64 as on Linux. I'm not 100% sure that non -O3 is the cause, but 
there are some function calls which get iterated a lot (e.g. isspace) 
and I'd seen that inlining was something -O3 did and not -O2.

In general, why wouldn't a user of a package want the best 
performance from -O3?

Because it doesn't work? I don't know, you said yourself that -O2 may
be there since -O3 breaks - that was not the question, though. (If 
you
are curious about that, ask on CRAN, I don't remember the answer --
note that Win64 compiler support is relatively recent).

 By non portable do you mean the executable produced by winbuilder 
(or by CRAN) might not run on all Windows machines it's installed on 
(because -O3 (over) optimizes for the machine it's built on), or do 
you mean that -O3 itself might not be available on some compilers (and 
if so which compilers don't have -O3?).

Non-portable as in -O3 may not be supported or may break (we have
seen -O3 trigger bugs in gcc before). If you hard-code it, there is 
no
way around it. The point is that you cannot make decisions for the
user in advance, because you don't know the setup the user may use. I
agree that Windows is a bit of a special-case in that there are very
few choices so the risk of breaking things is lower, but if -O2 is
really such a big deal, it is not just your problem and so you may
want to investigate it further.