Re: [Rd] How to ensure -O3 on Win64
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). Compilation with -O3 was not stable, including that some commonly-used packages segfaulted. x64 Windows is still an under-development platform for gcc, and a number of issues will not be resolved until at least gcc 4.8.0. And BTW, -O3 is not the out-of-the-box default for any R build except i386 Windows, including not for the OS X binary packages. Not sure why you are singling out Windows here It isn't just a question of optimization level but also what optimizing options the compiler is built with. We had to discard all the versions of gcc 4.6.x built with Graphite optimization as they produced far too unstable code on Windows. 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. Remember that even if -O3 works on your package with the current compiler, it may not with another one. One reason we update the recommended Windows compiler so infrequently is dealing with all the fallout from packages which break (almost always because of previously unrevealed errors in their code). But, for example, we will consider if we want to change the recommended compiler for R 3.0.0 and it is likely we will change it during 2013. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] reference Calling R from C++
Hello Guys, I have been working on integrating R and C++. I have been looking for a nice reference book which deals with it. I got R-inside but the proper documentation is not available for that package. If anyone knows some book please let me know... Thank you. -- View this message in context: http://r.789695.n4.nabble.com/reference-Calling-R-from-C-tp4654144.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in plot.ts?
Dear all, I think I have found a buglet in plot.ts plot.ts(x=1,type="n") # correct: does not show the plot plot.ts(x=1,y=1,type="n") # not correct: does show the plot I did not investigate the problem in depth but it could be related to the switch xy.labels, in fact plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot > sessionInfo() R version 2.15.2 Patched (2012-10-26 r61028) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252 [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.2 Kind regards Simone __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in plot.ts?
Hello,
You're right, it has to do with the argument xy.labels. The relevant
lines in the source are
(file src/library/stats/R/ts.R, function plot.ts)
[...]
n <- length(xy $ x) #-> default for xy.l(ines|abels)
if(missing(xy.labels)) xy.labels <- (n <= 150)
if(!is.logical(xy.labels)) {
if(!is.character(xy.labels))
stop("'xy.labels' must be logical or character")
do.lab <- TRUE
} else do.lab <- xy.labels
[...]
ptype <-
if(do.lab) "n" else if(missing(type)) "p" else type
plot.default(xy, type = ptype,
[...]
if(do.lab)
text(xy, labels =
if(is.character(xy.labels)) xy.labels
else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1)
else seq_along(xy$x),
col = col, cex = cex)
if(xy.lines)
lines(xy, col = col, lty = lty, lwd = lwd,
type = if(do.lab) "c" else "l")
[...]
Note that this is executed only if both 'x' and 'y' are passed to plot.ts.
The variable 'do.lab' will control the plot.default type and whether the
points are labeled using text() and the lines() type.
This variable is set according to xy.labels. This behavior is more or
less documented in plot.ts:
|"xy.labels|||logical, indicating if |text
()| labels should be
used for an x-y plot, /or/ character, supplying a vector of labels to be
used. The default is to label for up to 150 points, and not for more."
but I believe the documentation could be more clear. It could say that
in the case of a y ~ x plot, to supress the plot xy.labels should be set
to FALSE.
Hope this helps,
Rui Barradas
Em 29-12-2012 17:04, Simone Giannerini escreveu:
> Dear all,
>
> I think I have found a buglet in plot.ts
>
> plot.ts(x=1,type="n") # correct: does not show the plot
> plot.ts(x=1,y=1,type="n") # not correct: does show the plot
>
> I did not investigate the problem in depth but it could be related to
> the switch xy.labels, in fact
>
> plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot
> plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot
>
>> sessionInfo()
> R version 2.15.2 Patched (2012-10-26 r61028)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
> [3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
> [5] LC_TIME=Italian_Italy.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_2.15.2
>
>
> Kind regards
>
> Simone
> __
>
>
> Simone Giannerini
> Dipartimento di Scienze Statistiche "Paolo Fortunati"
> Universita' di Bologna
> Via delle belle arti 41 - 40126 Bologna, ITALY
> Tel: +39 051 2098262 Fax: +39 051 232153
> http://www2.stat.unibo.it/giannerini/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in plot.ts?
Just to add, on documentation, to my previous post. The following
illustrates my point.
# This is the last instruction in the original post.
plot.ts(x=1, y=1, type="n", xy.labels=FALSE) # does not show the plot
plot.ts(x=1, y=1, xy.labels=FALSE) # does show the plot, does not label
it, documented
plot.ts(x=1, y=1, type="n") # does show the plot (labels it), not
properly documented
plot.ts(x=1:151, y=1:151, type="n") # does not show the plot, documented
Rui Barradas
Em 29-12-2012 19:07, Rui Barradas escreveu:
Hello,
You're right, it has to do with the argument xy.labels. The relevant
lines in the source are
(file src/library/stats/R/ts.R, function plot.ts)
[...]
n <- length(xy $ x) #-> default for xy.l(ines|abels)
if(missing(xy.labels)) xy.labels <- (n <= 150)
if(!is.logical(xy.labels)) {
if(!is.character(xy.labels))
stop("'xy.labels' must be logical or character")
do.lab <- TRUE
} else do.lab <- xy.labels
[...]
ptype <-
if(do.lab) "n" else if(missing(type)) "p" else type
plot.default(xy, type = ptype,
[...]
if(do.lab)
text(xy, labels =
if(is.character(xy.labels)) xy.labels
else if(all(tsp(x) == tsp(y))) formatC(time(x), width = 1)
else seq_along(xy$x),
col = col, cex = cex)
if(xy.lines)
lines(xy, col = col, lty = lty, lwd = lwd,
type = if(do.lab) "c" else "l")
[...]
Note that this is executed only if both 'x' and 'y' are passed to plot.ts.
The variable 'do.lab' will control the plot.default type and whether the
points are labeled using text() and the lines() type.
This variable is set according to xy.labels. This behavior is more or
less documented in plot.ts:
|"xy.labels|||logical, indicating if |text
()| labels should be
used for an x-y plot, /or/ character, supplying a vector of labels to be
used. The default is to label for up to 150 points, and not for more."
but I believe the documentation could be more clear. It could say that
in the case of a y ~ x plot, to supress the plot xy.labels should be set
to FALSE.
Hope this helps,
Rui Barradas
Em 29-12-2012 17:04, Simone Giannerini escreveu:
Dear all,
I think I have found a buglet in plot.ts
plot.ts(x=1,type="n") # correct: does not show the plot
plot.ts(x=1,y=1,type="n") # not correct: does show the plot
I did not investigate the problem in depth but it could be related to
the switch xy.labels, in fact
plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot
plot.ts(x=1,y=1,type="n",xy.labels=FALSE) # does not show the plot
sessionInfo()
R version 2.15.2 Patched (2012-10-26 r61028)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252
[3] LC_MONETARY=Italian_Italy.1252 LC_NUMERIC=C
[5] LC_TIME=Italian_Italy.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.15.2
Kind regards
Simone
__
Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
