[Rcpp-devel] Rcpp::plugins - Unwinding protection

Hi everyone,

I am using Rcpp to develop my own package and one of my functions calls
back into R for a given amount of iterations. To speed up the process, I
wanted to use Rcpp::unwindProtect. However, I couldn't find
on Rcpp's documentation what is the correct way to use this plugin.
Therefore, I would like to ask you for some guidance, if possible.

Reproducible toy example:

````````````````
require(Rcpp)
Rcpp::cppFunction("
  NumericVector test_f(NumericMatrix x, Function f) {
    NumericVector out(x.ncol());

    for (int iter = 0; iter < x.ncol(); iter++) {
      out[iter] = as<double>(f(x(_ , iter)));
    }

    return out;
  }
")

x <- matrix(1.2:9.2, 3, 3)

colSums(x)
f <- function(x) sum(x)
test_f(x, f)

require(rbenchmark)
rbenchmark::benchmark("R1"=colSums(x),
                                        "R2"=test_f(x, f),
                                        replications=10000)
````````````````

Best,
Vithor

On 2 December 2021 at 17:48, Iñaki Ucar wrote:
| My simulation package makes heavy use of calls to R user functions from a
| C++ simulation loop, and therefore greatly benefits from this feature
too,
| which I think we should promote to default.

I agree and believe I looked into it once before -- but found 'shrapnel'
from
other packages being affected. We are eight months into the (simpler !!)
transition to default to STRICT_R_HEADERS which will go in with Rcpp 1.0.8
in
January (and yay, yesterday brought several updates, so my thanks to
everybody who folded patches or PRs I sent in and uploaded; current score
is
now 70 out 92 done, see https://github.com/RcppCore/Rcpp/issues/1158 )

So maybe in 2022...

| Meanwhile, take a look at this
| Makevars file to see how to activate it:
| https://github.com/r-simmer/simmer/blob/master/src/Makevars

Yep.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Hi Iñaki and Dirk,

Thank you for your response. Adding my functions to an R package and changing the Makevars file as suggested reduced the runtime by half. Excited for Rcpp 1.0.8! :)

Best,

Em qui., 2 de dez. de 2021 às 18:22, Dirk Eddelbuettel <edd at debian.org> escreveu:

On 2 December 2021 at 17:48, Iñaki Ucar wrote:
| My simulation package makes heavy use of calls to R user functions from a
| C++ simulation loop, and therefore greatly benefits from this feature too,
| which I think we should promote to default.

I agree and believe I looked into it once before -- but found 'shrapnel' from
other packages being affected. We are eight months into the (simpler !!)
transition to default to STRICT_R_HEADERS which will go in with Rcpp 1.0.8 in
January (and yay, yesterday brought several updates, so my thanks to
everybody who folded patches or PRs I sent in and uploaded; current score is
now 70 out 92 done, see https://github.com/RcppCore/Rcpp/issues/1158 )

So maybe in 2022...

| Meanwhile, take a look at this
| Makevars file to see how to activate it:
| https://github.com/r-simmer/simmer/blob/master/src/Makevars

Yep.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

--
Prof. Ph.D. Víthor Rosa Franco
Universidade São Francisco (USF), Campinas, SP, Brazil
Phone: +55 61 994602228
Curriculum

No amount of experimentation can ever prove me right; a single experiment can prove me wrong.

On 3 December 2021 at 17:03, Iñaki Ucar wrote:
| On Fri, 3 Dec 2021 at 15:44, Víthor Rosa <vrosafranco at gmail.com> wrote:
| >
| > Thank you for your response. Adding my functions to an R package and changing the Makevars file as suggested reduced the runtime by half. Excited for Rcpp 1.0.8! :)
|
| Excellent! Glad it helped.

I have been sitting on a branch at GitHub that defines new / easier /
alternate header files as entry points. So instead of starting with Rcpp.h
(possibly combined with #define statements) one could now pick exactly one
off these three

   #include <Rcpp/Light>

   #include <Rcpp/Lighter>

   #include <Rcpp/Lightest>

which turn off, respectively, Modules, RTTI and Sugar. See the commit at [1]
for more and full code, it's essentially a define each and simple nesting.

Each of these shaves a little bit of the compile times.  (I need to rebase it
to current master, it's a few months old.)

But I had not yet convinced myself it would be useful / of interest.  But as
this thread shows, there may be interest.  Any comments? Yay? Nay?

(And as discussed turning UNWIND_PROTECT on globally is also a good idea but
may need a proper transition, and is hence for now outside the scope of this
branch.)

Dirk


[1] https://github.com/RcppCore/Rcpp/commit/5cf57ff663d06acf42124feae51d469f3f77be52#diff-05c80375618a46d399d73e4f32a3006aa698b9bb293a37c6d2e431a1c541b7bb

--
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On 3 December 2021 at 19:47, Iñaki Ucar wrote:
| Mmmh, no strong opinions here. I think it doesn't matter much whether
| it's an include or a define. What matters most is whether this is
| discoverable and the user understands what it does.

That was my motivation -- by pointing to such a top-level directory (and also
cleaning up some of the sprawling header mess :) ) it may easier.

| In this particular case, Víthor is interested in runtime performance.
| Disabling modules and RTTI (and Sugar if he's not using that) will
| save some compilation time, but won't help with runtime performance.

Understood. But it is a compile-time switch like these.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org