[Rcpp-devel] Forcing a shallow versus deep copy

[Dirk Eddelbuettel]

On 11 July 2013 at 10:33, baptiste auguie wrote:
| Hi,
| 
| That's great, thanks for considering this!
| 
| Following this discussion, I went to browse through my code looking for wrap()
| and as() statements that could benefit from a speed-up of memory reuse. Of
| course I didn't find any. 
| I switched to using Modules when they were introduced, the code being much
| nicer to read, and these conversions only happen behind the scene.
| My c++ functions thus only deal with native Armadillo / C++ objects, and I
| leave it up to the modules to magically do the required conversions in and out.
| It's a brilliant interface, very readable.
| 
| From what I understand, however, the resulting code can often lose a factor 2-3
| in speed, compared to the now much more verbose alternative of explicitly
| converting and sharing the memory with this type of code:

No way.

I have seen 2 to 3 __per cent__ which is very different from a factor 2 or 3.

This whole discussion is mostly a non-issue, really, as best as I can tell
because the cost ois really not that large.

Dirk
 
| arma::mat A(M.begin(), M.rows(), M.cols(), false);
| 
| From this perspective, the possibility of setting copy_aux_mem to false in as
| (), as used by modules, would be very welcome.
| 
| Best regards,
| 
| baptiste
| 
| 
| On 11 July 2013 10:22, <romain at r-enthusiasts.com> wrote:
| 
| 
|     Hello,
| 
|     This comes up every now and then, I think we can find a syntax to initiate
|     an arma::mat that would allow what you want.
| 
|     It is not likely it will come via attributes. The idea is to keep them
|     simple. The solutions I see below would eventually lead to clutter, and we
|     are heading in the less clutter direction.
| 
|     I'll think about it and propose something.
| 
|     Romain
| 
|     Le 2013-07-11 14:32, Changi Han a écrit :
| 
| 
|         Hello,
| 
|         I think I (superficially) understand the difference between:
| 
|         // [[Rcpp::export]]
|         double sum1(Rcpp::NumericMatrix M) {
|             arma::mat A(M.begin(), M.rows(), M.cols(), false);
|              return sum(sum(A));
|         }
| 
|         // [[Rcpp::export]]
|         double sum2(arma::mat A) {
|             return sum(sum(A));
|         }
| 
|         Partly out of laziness, partly because sum2 is more elegant, and
|         partly to avoid namespace pollution, I was wondering if there is a way
|         to "force" a "shallow" copy in sum2.
| 
|         If not, then may I submit a low priority feature request. An
|         attribute? Some thing like:
| 
|         // [[Rcpp::export]]
|         double sum2(arma::mat A) {
|             // [[ Rcpp::shallow ( A ) ]]
|              return sum(sum(A));
|         }
| 
|         Or (akin to C++11 generalized attributes)
| 
|         // [[Rcpp::export]] { [[ Rcpp::shallow ( A ) ]] }
|         double sum2(arma::mat A) {
|             return sum(sum(A));
|          }
| 
|         An alternative is to have an argument in sourceCpp that takes a
|         list/vector of objects that are to be shallow or deep copied.
| 
|         For example in sum1, if M is changed within the function before
|         casting to the arma::mat, then might be cleaner to add M to a
|         list/vector of objects to be deep copied rather than cloning M within
|         sum1: leads to one fewer variable name.
| 
|         Just a thought. I can certainly live with the additional step. As
|         always, thanks for all the Rcpp goodness.
| 
|         Cheers,
|         Changi Han
| 
| 
|     _______________________________________________
|     Rcpp-devel mailing list
|     Rcpp-devel at lists.r-forge.r-project.org
|     https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| 
| 
| 
| ----------------------------------------------------------------------
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com