Re: [Rcpp-devel] Sugar seems slower than Rcpp.
Dear All,
Here are some simulations that I have run this morning. Romain's
suggestion to compute xV.size() before the loop and Douglas' idea of
using accumulate appear to work best. However, both are substantially
slower than the r-base function.
I have also included two more versions: (i) one similar to Romain's but
using pre-incrementation**in the loop and (ii) one using the iterator in
the loop. Another option may be to use the C++ boost library. I don't
know if anyone on this list has experience with using boost.
See the results of the simulations below (N=1000 data sets).
Ced
#
## Functions.
Summing1 <- cxxfunction(signature(x="numeric"), '
NumericVector xV(x);
double out = sum(xV);
return wrap(out);
',plugin="Rcpp")
Summing2 <- cxxfunction(signature(x="numeric"), '
NumericVector xV(x);
double out = 0.0;
for(int i=0; i for(NumericVector::iterator i=xV.begin(); i!=xV.end(); ++i) out
+= *i;
return wrap(out);
',plugin="Rcpp")
#
## Simulation: Time Testing.
n <- 100; N <- 1000
time.Sum <- matrix(0,N,7);
for(i in 1:N){
x <- rnorm(n)
time.Sum[i,1] <- system.time(Summing1(x))[3];
time.Sum[i,2] <- system.time(Summing2(x))[3];
time.Sum[i,3] <- system.time(Summing3(x))[3];
time.Sum[i,4] <- system.time(Summing4(x))[3];
time.Sum[i,5] <- system.time(Summing5(x))[3];
time.Sum[i,6] <- system.time(Summing6(x))[3];
time.Sum[i,7] <- system.time(sum(x))[3];
}# i
time.df <- data.frame(time.Sum)
names(time.df) <-
c("Sugar","Rcpp","Rcpp_N","Accumulate","Pre-increment","Iterator","R")
boxplot(time.df)
#
## RESULTS:
formatC(summary(time.df),dec=3)
Sugar RcppRcpp_N
" Min. :0.01600 " " Min. :0.01000 " "Min. :0.005000 "
" 1st Qu.:0.01600 " " 1st Qu.:0.01000 " "1st Qu.:0.005000 "
" Median :0.01600 " " Median :0.01100 " "Median :0.006000 "
" Mean :0.01631 " " Mean :0.01060 " "Mean :0.005668 "
" 3rd Qu.:0.01600 " " 3rd Qu.:0.01100 " "3rd Qu.:0.006000 "
" Max. :0.03700 " " Max. :0.02400 " "Max. :0.02 "
Accumulate Pre-increment Iterator
"Min. :0.005000 " "Min. :0.005000 " " Min. :0.01000 "
"1st Qu.:0.005000 " "1st Qu.:0.005000 " " 1st Qu.:0.01000 "
"Median :0.006000 " "Median :0.006000 " " Median :0.01100 "
"Mean :0.005714 " "Mean :0.005697 " " Mean :0.01065 "
"3rd Qu.:0.006000 " "3rd Qu.:0.006000 " " 3rd Qu.:0.01100 "
"Max. :0.029000 " "Max. :0.021000 " " Max. :0.03100 "
R
"Min. :0.002000 "
"1st Qu.:0.002000 "
"Median :0.002000 "
"Mean :0.002211 "
"3rd Qu.:0.002000 "
"Max. :0.004000 "
#
PS: Apologies to Dirk as I have not followed his advice, yet.
--
Cedric Ginestet
Centre for Neuroimaging Sciences (L3.04)
NIHR Biomedical Research Centre
Institute of Psychiatry, Box P089
Kings College London
De Crespigny Park
London
SE5 8AF
On 04/01/11 15:37, Dirk Eddelbuettel wrote:
On 4 January 2011 at 15:14, Cedric Ginestet wrote:
| Happy new year to everyone,
|
| I have made a very straightforward comparison of the performance of standard
R,
| Rcpp function and sugar, and found that the latter produces the poorest
| performance. Let me know what you think and how I could improve such
| performance assessment.
|
| ###
| Summing1<- cxxfunction(signature(x="numeric"), '
| NumericVector xV(x);
| double out = sum(xV);
| return wrap(out);
| ',plugin="Rcpp")
| Summing2<- cxxfunction(signature(x="numeric"), '
| NumericVector xV(x);
| double out = 0.0;
| for(int i=0; i system.time(Summing1(x));
|user system elapsed
| 0.016 0.000 0.016
|> system.time(Summing2(x));
|user system elapsed
| 0.008 0.000 0.011
|> system.time(sum(x));
|user system elapsed
| 0.000 0.000 0.003
|
|
| Sugar appears to be the slowest! What about Rcpp basic loop? Why isn't as fast
| as the standard sum() in R-base?
1) Try to think a about measurement error here; these times are all minuscule.
2) Consider reading the list archive, we have better use of benchmarks using
rbenchmark and replications; these are also some example in the examples
right in Rcpp
3) Consider reading the list archive and discussions about the NoNA tests.
4) Lastly, consider Romain's point about a baseline using an empty function.
Dirk
| Cheers,
| Cedric
|
| --
| Cedric Ginestet
| Centre for Neuroimaging Sciences (L3.04)
| NIHR Biomedical Research Centre
| Institute of Psychiatry, Box P089
| Kings College London
| De Crespigny Park
| London
| SE5 8AF
|
|
| --
| _
Re: [Rcpp-devel] Sugar seems slower than Rcpp.
On 5 January 2011 at 10:55, Cedric Ginestet wrote: | Dear All, | | Here are some simulations that I have run this morning. Romain's suggestion to | compute xV.size() before the loop and Douglas' idea of using accumulate appear | to work best. However, both are substantially slower than the r-base function. | | I have also included two more versions: (i) one similar to Romain's but using | pre-incrementation in the loop and (ii) one using the iterator in the loop. | Another option may be to use the C++ boost library. I don't know if anyone on | this list has experience with using boost. | | See the results of the simulations below (N=1000 data sets). | Ced | | # | ## Functions. | Summing1 <- cxxfunction(signature(x="numeric"), ' | NumericVector xV(x); | double out = sum(xV); | return wrap(out); | ',plugin="Rcpp") | Summing2 <- cxxfunction(signature(x="numeric"), ' | NumericVector xV(x); | double out = 0.0; | for(int i=0; ihttp://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] Loading a package using Rcpp Modules results in memory corruption
I don't know whether this is through error on my part or because of an "infelicity" in the Rcpp module code but the lme4a package, which now uses Rcpp modules extensively, ends up with some difficult-to-trace memory corruption issues. Yesterday i finally bit the bullet and ran a test with gctorture(TRUE) and valgrind enabled. It takes a very long time and results in a segfault when trying to load the package. I enclose the transcript. I should say that this is using Rcpp_0.9.0 from CRAN, not the SVN version of Rcpp. I just got these results this morning (it was running overnight) and haven't looked at the code in Module.cpp and cache.cpp yet. If it seems likely that the code is beyond me I can try to work out a simpler example that triggers the problem. ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Loading a package using Rcpp Modules results in memory corruption
This time with the enclosure :-) On Wed, Jan 5, 2011 at 11:52 AM, Douglas Bates wrote: > I don't know whether this is through error on my part or because of an > "infelicity" in the Rcpp module code but the lme4a package, which now > uses Rcpp modules extensively, ends up with some difficult-to-trace > memory corruption issues. Yesterday i finally bit the bullet and ran > a test with gctorture(TRUE) and valgrind enabled. It takes a very > long time and results in a segfault when trying to load the package. > I enclose the transcript. I should say that this is using Rcpp_0.9.0 > from CRAN, not the SVN version of Rcpp. > > I just got these results this morning (it was running overnight) and > haven't looked at the code in Module.cpp and cache.cpp yet. If it > seems likely that the code is beyond me I can try to work out a > simpler example that triggers the problem. > ==15160== Memcheck, a memory error detector ==15160== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==15160== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==15160== Command: /home/bates/build/R-devel/bin/exec/R --no-save --no-restore ==15160== ==15160== Conditional jump or move depends on uninitialised value(s) ==15160==at 0x6870E40: inflateReset2 (in /lib/libz.so.1.2.3.4) ==15160==by 0x6870F2F: inflateInit2_ (in /lib/libz.so.1.2.3.4) ==15160==by 0x686B1BC: ??? (in /lib/libz.so.1.2.3.4) ==15160==by 0x4EB019E: gzfile_open (connections.c:1186) ==15160==by 0x4EADD57: do_gzfile (connections.c:1745) ==15160==by 0x4F6152A: do_internal (names.c:1197) ==15160==by 0x4F1320A: Rf_eval (eval.c:469) ==15160==by 0x4F15C2C: Rf_applyClosure (eval.c:811) ==15160==by 0x4F130E7: Rf_eval (eval.c:513) ==15160==by 0x4F1A55F: do_set (eval.c:1698) ==15160==by 0x4F1320A: Rf_eval (eval.c:469) ==15160==by 0x4F14C6B: do_begin (eval.c:1418) ==15160== ==15160== Conditional jump or move depends on uninitialised value(s) ==15160==at 0x6870E40: inflateReset2 (in /lib/libz.so.1.2.3.4) ==15160==by 0x6870F2F: inflateInit2_ (in /lib/libz.so.1.2.3.4) ==15160==by 0x686B648: uncompress (in /lib/libz.so.1.2.3.4) ==15160==by 0x4EA4A09: R_decompress1 (connections.c:5143) ==15160==by 0x4FDD813: do_lazyLoadDBfetch (serialize.c:2378) ==15160==by 0x4F1333F: Rf_eval (eval.c:498) ==15160==by 0x4F13666: forcePromise (eval.c:331) ==15160==by 0x4F12EDB: Rf_eval (eval.c:450) ==15160==by 0x4EFAB0A: Rf_findFun (envir.c:1293) ==15160==by 0x4F13063: Rf_eval (eval.c:456) ==15160==by 0x4F4D165: R_ReplFile (main.c:100) ==15160==by 0x4F4D279: R_LoadProfile (main.c:662) ==15160== R version 2.13.0 Under development (unstable) (2011-01-04 r53913) Copyright (C) 2011 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-unknown-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > gctorture(TRUE) > library(lme4a) Loading required package: Matrix Loading required package: lattice Attaching package: 'Matrix' The following object(s) are masked from 'package:base': det Loading required package: minqa Loading required package: Rcpp ==15160== Conditional jump or move depends on uninitialised value(s) ==15160==at 0x4F0650F: Rf_promiseArgs (eval.c:1918) ==15160==by 0x4F130BA: Rf_eval (eval.c:512) ==15160==by 0xD5C7613: init_Rcpp_cache (cache.cpp:55) ==15160==by 0xD5B3493: R_init_Rcpp (Module.cpp:264) ==15160==by 0x4E668DC: AddDLL (Rdynload.c:567) ==15160==by 0x4E66B6E: do_dynload (Rdynload.c:900) ==15160==by 0x4F6152A: do_internal (names.c:1197) ==15160==by 0x4F1320A: Rf_eval (eval.c:469) ==15160==by 0x4F15C2C: Rf_applyClosure (eval.c:811) ==15160==by 0x4F130E7: Rf_eval (eval.c:513) ==15160==by 0x4F1320A: Rf_eval (eval.c:469) ==15160==by 0x4F1A55F: do_set (eval.c:1698) ==15160== ==15160== Conditional jump or move depends on uninitialised value(s) ==15160==at 0x4F0651E: Rf_promiseArgs (eval.c:1931) ==15160==by 0x4F130BA: Rf_eval (eval.c:512) ==15160==by 0xD5C7613: init_Rcpp_cache (cache.cpp:55) ==15160==by 0xD5B3493: R_init_Rcpp (Module.cpp:264) ==15160==by 0x4E668DC: AddDLL (Rdynload.c:567) ==15160==by 0x4E66B6E: do_dynload (Rdynload.c:900) ==15160==by 0x4F6152A: do_internal (names.c:1197) ==15160==by 0x4F1320A: Rf_eval (eval.c:469) ==15160==by 0x4F15C2C: Rf_applyClosure (eval.c:811) ==15160==by 0x4F130E7: Rf_eval (eval.c:513) ==15160==by 0x4F
Re: [Rcpp-devel] Loading a package using Rcpp Modules results in memory corruption
On looking more closely at the output, I thought that the problem may arise in loading the Rcpp package because that is when the function init_Rcpp_cache() is evaluated. So I ran another test which was simply gctorture(TRUE) library(Rcpp) run with -d valgrind. Unfortunately (well, at least from my point of view) that test didn't show any problems. I'm at a bit of a loss where to go on this. On Wed, Jan 5, 2011 at 11:55 AM, Douglas Bates wrote: > This time with the enclosure :-) > > On Wed, Jan 5, 2011 at 11:52 AM, Douglas Bates wrote: >> I don't know whether this is through error on my part or because of an >> "infelicity" in the Rcpp module code but the lme4a package, which now >> uses Rcpp modules extensively, ends up with some difficult-to-trace >> memory corruption issues. Yesterday i finally bit the bullet and ran >> a test with gctorture(TRUE) and valgrind enabled. It takes a very >> long time and results in a segfault when trying to load the package. >> I enclose the transcript. I should say that this is using Rcpp_0.9.0 >> from CRAN, not the SVN version of Rcpp. >> >> I just got these results this morning (it was running overnight) and >> haven't looked at the code in Module.cpp and cache.cpp yet. If it >> seems likely that the code is beyond me I can try to work out a >> simpler example that triggers the problem. >> > ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Loading a package using Rcpp Modules results in memory corruption
On Wed, Jan 5, 2011 at 2:15 PM, Douglas Bates wrote: > On looking more closely at the output, I thought that the problem may > arise in loading the Rcpp package because that is when the function > init_Rcpp_cache() is evaluated. So I ran another test which was > simply > > gctorture(TRUE) > library(Rcpp) > > run with -d valgrind. > > Unfortunately (well, at least from my point of view) that test didn't > show any problems. I'm at a bit of a loss where to go on this. Perhaps Romain or Dirk could clarify for me when init_Rcpp_cache should be called. It appears to be getting called twice, once explicitly in the .onLoad expression in Rcpp/R/zzz.R and once implicitly by being part of the R_init_Rcpp function defined in Rcpp/src/Module.cpp. Is this intentional? Should one or both of those be a maybe_init() call? I think as it stands the second call will overwrite the contents created by the first call. I'm kind of grasping at straws here but I think there might be a problem with the cache being created when the Rcpp namespace is attached and then called again when the Rcpp package is loaded in my example. > On Wed, Jan 5, 2011 at 11:55 AM, Douglas Bates wrote: >> This time with the enclosure :-) >> >> On Wed, Jan 5, 2011 at 11:52 AM, Douglas Bates wrote: >>> I don't know whether this is through error on my part or because of an >>> "infelicity" in the Rcpp module code but the lme4a package, which now >>> uses Rcpp modules extensively, ends up with some difficult-to-trace >>> memory corruption issues. Yesterday i finally bit the bullet and ran >>> a test with gctorture(TRUE) and valgrind enabled. It takes a very >>> long time and results in a segfault when trying to load the package. >>> I enclose the transcript. I should say that this is using Rcpp_0.9.0 >>> from CRAN, not the SVN version of Rcpp. >>> >>> I just got these results this morning (it was running overnight) and >>> haven't looked at the code in Module.cpp and cache.cpp yet. If it >>> seems likely that the code is beyond me I can try to work out a >>> simpler example that triggers the problem. >>> >> > ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] Patch to RcppDE vignette -- Refs
Attached is a small diff to the RcppDE vignette. I added 2 well-cited
primary lit papers that are helpful (and internet available)
introductions to DE. While I was at it, I ran the doc through the
spell-checker :).
-Christian
Index: RcppDE.Rnw
===
--- RcppDE.Rnw (revision 2835)
+++ RcppDE.Rnw (working copy)
@@ -89,12 +89,17 @@
\pkg{DEoptim}
\citep{MullenArdiaEtAl:2009:DEoptim,ArdiaBoudtCarlEtAl:2010:DEoptim,CRAN:DEoptim}
provides differential evolution optimisation for the \proglang{R} language
-and statistical environement. Differential optimisation is one of several
-evolutionary computing approaches; genetic algorithns and simulated annealing
-are two other ones. Differential optimisation is reasonably close to genetic
+and statistical environment. Differential evolution
+\citep{StornPrice:1997:Differential} is one of several
+evolutionary computing approaches to the global optimisation of arbitrary
+objective functions; genetic algorithms and simulated annealing
+are two others. Differential evolution is reasonably close to genetic
algorithms but differs in one key aspect: parameter values are encoded as
-floating point values (rather than sequences of binary digits) which makes it
-particular suitable for real-valued optimisation problems.
+floating point values (rather than sequences of binary digits), which makes it
+particular suitable for real-valued optimisation problems. The relative
+performance of differential evolution compared to other global optimisation
+algorithms, as well as optimal parametrization, is reviewed in
+\citet{StornPrice:1997:Differential} and
\citet{VesterstromThomsen:2004:Comparative}.
\pkg{DEoptim} is based on an implementation by Storn
\citep{PriceStornLampinen:2006:DE}. It was originally implemented as an
@@ -133,7 +138,7 @@
covers other aspects such as the automatic type conversion offered by
\pkg{Rcpp} as well as the automatic memory management: by replacing
allocation and freeing of heap-based dynamic memory, a consistent source of
- programmer error would be elimnated---plus we are not trying `short and
+ programmer error would be eliminated---plus we are not trying `short and
incomprehensible' in the APL-sense but aim for possible improvements on
\textsl{both} the length and the ease of comprehension without trading one
off against the other;
@@ -149,10 +154,10 @@
\end{itemize}
This paper is organised as follows. The next sections describes the structure
-of \pkg{DEoptim} which \pkg{RcppDE} shadows closesly. The following two
+of \pkg{DEoptim} which \pkg{RcppDE} shadows closely. The following two
section compare differences at the \proglang{R} and \proglang{C++} level,
-respectively. Next, changes in auxiliarry files are discussed before we
-review changes in perfomance. A summary concludes. The appendix contains a
+respectively. Next, changes in auxiliary files are discussed before we
+review changes in performance. A summary concludes. The appendix contains a
list of figures contrasting the two implementations.
\section[DEoptim structure]{\pkg{DEoptim} structure}
@@ -205,7 +210,7 @@
routine) and \verb|permute()| (which is a helper function used to shuffle
indices).
-The evalution function has been replaced by a base class and two virtual
+The evaluation function has been replaced by a base class and two virtual
classes. These can now make use of objective functions written in
\proglang{R} (as in \pkg{DEoptim}) as well as ones written in
\proglang{C++}. Using compiled objective functions can lead to substantial
@@ -279,12 +284,12 @@
types corresponding to base typed \verb|int|, \verb|double| etc. Also of
note is how one matrix object (\texttt{initialpom} for seeding a first
population of parameter values) is initialized directly from a parameter.
-\item Paremeter lookup is by a string value but done using the \pkg{Rcpp}
lookup
+\item Parameter lookup is by a string value but done using the \pkg{Rcpp}
lookup
of elements in the \verb|list| type (which corresponds to the \proglang{R}
list passed in) rather than via a (functionally similar but ad-hoc) function
\verb|getListElement| that hence is not longer needed in \pkg{RcppDE}.
\item Here as in later code examples, care was taken to ensure that variable
- names and types correpond closely between both variants.
+ names and types correspond closely between both variants.
\end{enumerate}
\paragraph{Part 2: Middle of \texttt{DEoptim()}} The second part,
@@ -300,7 +305,7 @@
\begin{enumerate}
\item Matrix objects are created in \proglang{C} by first allocating a vector
of pointers to pointers, which is followed by a loop in which each each
- column is allocated as vector of approrpriate length.
+ column is allocated as vector of appropriate length.
\item In \proglang{C++}, allocating a matrix is a single statement. Memory is
managed by reference counting and is fre
