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

[Tim Keitt]

http://www.keittlab.org/

On Sat, Jul 29, 2017 at 8:00 AM, Iñaki Úcar <i.ucar86 at gmail.com> wrote:

> 2017-07-29 13:58 GMT+02:00 JJ Allaire <jj.allaire at gmail.com>:
> > The best you can do is to get the pointer to the function (not sure if
> that
> > does what you are hoping for):
> >
> > 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


>
> Iñaki
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20170730/2bbed84d/attachment.html>