[Rcpp-devel] Resolving NativeSymbolInfos from Rcpp (revisited)

[Dirk Eddelbuettel]

On 31 July 2017 at 10:57, Iñaki Úcar wrote:
| Ok then, I'll sketch out a new package. May I use the name "RcppXPtr"?

Sure, could do.

The _type_ is in Rcpp proper, so maybe RcppXPtrHelpers, or RcppXPtrWrappers,
or just RcppXPtrUtils?

Dirk

[Iñaki Úcar]

The best you can do is to get the pointer to the function (not sure if that
func <- Rcpp::cppFunction("int foo() { return 1; }")

body(func)

.Primitive(".Call")(<pointer: 0x103bf0f40>)

I don't think so. Let me explain the motivation behind my question;
this way you can judge whether it's worth it.

With our simulator, simmer, we are able to generate arrivals, entities
that execute a given set of activities. One of these activities could
be, let's say, a delay. A user can provide this delay as a fixed
parameter to the C++ core, but also as a function that returns a
value, giving them a lot of flexibility to implement the simulation
model. As a trade-off, calling an R function from C++ is slow.

Now, what if the user needs flexibility *and* speed and so decides to
pass a cppFunction instead? This is perfectly valid and works like a
charm. In fact, this speeds up things a lot, especially if the
function was performing some heavy processing. *However*, it means
that we still have C++ calling R calling C++.

This is why I say, what if I can detect that situation and completely
get rid of that thin R layer? What if I can extract the pointer and
call C++ directly from my C++ core? I would expect an impressive
performance improvement.

Iñaki

[Tim Keitt]

http://www.keittlab.org/

Post by Iñaki Úcar

The best you can do is to get the pointer to the function (not sure if

that

func <- Rcpp::cppFunction("int foo() { return 1; }")

body(func)

.Primitive(".Call")(<pointer: 0x103bf0f40>)

I don't think so. Let me explain the motivation behind my question;
this way you can judge whether it's worth it.
With our simulator, simmer, we are able to generate arrivals, entities
that execute a given set of activities. One of these activities could
be, let's say, a delay. A user can provide this delay as a fixed
parameter to the C++ core, but also as a function that returns a
value, giving them a lot of flexibility to implement the simulation
model. As a trade-off, calling an R function from C++ is slow.
Now, what if the user needs flexibility *and* speed and so decides to
pass a cppFunction instead? This is perfectly valid and works like a
charm. In fact, this speeds up things a lot, especially if the
function was performing some heavy processing. *However*, it means
that we still have C++ calling R calling C++.
This is why I say, what if I can detect that situation and completely
get rid of that thin R layer? What if I can extract the pointer and
call C++ directly from my C++ core? I would expect an impressive
performance improvement.

Many C++ libs require function inlining to get top performance. You might
consider assembling the model in C++ and compiling on-the-fly. I have a
demo at https://github.com/thk686/odeintr. The user just supplies bits of
C++ code that are merged with the boilerplate and compiled.

THK

Post by Iñaki Úcar
Iñaki
_______________________________________________
Rcpp-devel mailing list
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Dirk Eddelbuettel]

On 29 July 2017 at 15:00, Iñaki Úcar wrote:
| With our simulator, simmer, we are able to generate arrivals, entities
| that execute a given set of activities. One of these activities could
| be, let's say, a delay. A user can provide this delay as a fixed
| parameter to the C++ core, but also as a function that returns a
| value, giving them a lot of flexibility to implement the simulation
| model. As a trade-off, calling an R function from C++ is slow.
|
| Now, what if the user needs flexibility *and* speed and so decides to
| pass a cppFunction instead? This is perfectly valid and works like a
| charm. In fact, this speeds up things a lot, especially if the
| function was performing some heavy processing. *However*, it means
| that we still have C++ calling R calling C++.
|
| This is why I say, what if I can detect that situation and completely
| get rid of that thin R layer? What if I can extract the pointer and
| call C++ directly from my C++ core? I would expect an impressive
| performance improvement.

Are you aware of what we can do with Rcpp::XPtr and what e.g. the RcppDE
package does to pass __user-supplied C++ functions__ down to the core of the
optimization to avoid touching R code? There is also a Rcpp Gallery piece
on this: http://gallery.rcpp.org/articles/passing-cpp-function-pointers/

Dirk

[Iñaki Úcar]

Post by Dirk Eddelbuettel
The _type_ is in Rcpp proper, so maybe RcppXPtrHelpers, or RcppXPtrWrappers,
or just RcppXPtrUtils?

Here we go, comments and PRs welcome: https://github.com/Enchufa2/RcppXPtrUtils

Apart from adding tests, I was thinking about defining a wrapper for
cppXPtr(), so that packages can use this wrapper to check and enforce
a given signature, in order to avoid compiling, running & crashing due
to a wrong signature.

Iñaki