[Rd] How to ensure -O3 on Win64
mdowle at mdowle.plus.com
Fri Dec 28 22:51:02 CET 2012
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:
>>>> 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
>>> 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
>>> to compile with -O3, you just can't impose that on others.
>> 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
> 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
> 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.
More information about the R-devel