[Rd] How to ensure -O3 on Win64

[Matthew Dowle]

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?  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?).

Thanks, Matthew