[Rd] How to ensure -O3 on Win64

[Matthew Dowle]

On 28.12.2012 00:41, Simon Urbanek wrote:
> 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).

Indeed I had forgotten how recent that was. Ok, this is clicking now.


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

Ok thanks a lot for info. I'll try a few more things and follow up off
r-devel if need be.

Matthew