[Rcpp-devel] [small ann] Sparse++
Hello mailing list. Just small announcement. I made package "sparsepp" which brings bindings to header only 'sparsepp' library - https://github.com/greg7mdp/sparsepp. It is on CRAN already. Sparse++ is improvement over google sparse hash library (see this write-up https://github.com/greg7mdp/sparsepp/blob/master/bench.md). Initially I evaluated it with my text2vec package, where main data structure is unordered_map< pair, T >, where T is int or float. In my case memory improvement was 2x and speed up was 1.5x (lookup and insert operations). So I decided to build small package which can be used by other people (not text2vec only). Usage is as usual 1. add to DESCRIPTION of your package: LinkingTo: sparsepp 2. add #include to you source/header 3. use spp::sparse_hash_map as drop-in replacement for std::unordered_map . -- Regards Dmitriy Selivanov ___ 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] [small ann] Sparse++
On 30 December 2016 at 15:49, Dmitriy Selivanov wrote:
| Hello mailing list. Just small announcement. I made package "sparsepp" which
| brings bindings to header only 'sparsepp' library - https://github.com/
| greg7mdp/sparsepp. It is on CRAN already. Sparse++ is improvement over google
| sparse hash library (see this write-up https://github.com/greg7mdp/sparsepp/
| blob/master/bench.md).
|
| Initially I evaluated it with my text2vec package, where main data structure
| is unordered_map< pair, T >, where T is int or float.
| In my case memory improvement was 2x and speed up was 1.5x (lookup and insert
| operations).
|
| So I decided to build small package which can be used by other people (not
| text2vec only).
|
| Usage is as usual
|
| 1. add to DESCRIPTION of your package: LinkingTo: sparsepp
| 2. add #include to you source/header
| 3. use spp::sparse_hash_map as drop-in replacement for std::unordered_map.
Thanks, possibly very useful.
Now, should it have at least a 'Suggests: Rcpp' if the example requires it,
\dontrun{} or not? Also examine whose project you're posting on.
Sure it "could" be used from R without Rcpp. But how likely is that?
Suggests is for exactly that reason, at least in my book.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
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] Rcpp Timer
On 29 December 2016 at 11:25, Jonathan Christensen wrote: | Hi Kaspar and Dirk, | | It is indeed cumulative. Previously (presumably when that gallery page was | written) it was not cumulative, but Romain Francois changed the behavior of the | step() function several years ago, in this commit: https://github.com/RcppCore/ | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. Nice catch. | There is no indication or reasoning about changing the behavior, so it may be | that making it cumulative was unintentional. Let's presume it was intentional to the author of the change -- but as you rightly point out, it did of course change and reverse previous behaviour. We could easily add a toggle to the constructor to get an either/or behaviour. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ 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] Rcpp Timer
On 30 December 2016 at 06:37, Dirk Eddelbuettel wrote:
|
| On 29 December 2016 at 11:25, Jonathan Christensen wrote:
| | Hi Kaspar and Dirk,
| |
| | It is indeed cumulative. Previously (presumably when that gallery page was
| | written) it was not cumulative, but Romain Francois changed the behavior of
the
| | step() function several years ago, in this commit:
https://github.com/RcppCore/
| | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1.
|
| Nice catch.
|
| | There is no indication or reasoning about changing the behavior, so it may
be
| | that making it cumulative was unintentional.
|
| Let's presume it was intentional to the author of the change -- but as you
| rightly point out, it did of course change and reverse previous behaviour.
|
| We could easily add a toggle to the constructor to get an either/or behaviour.
Even easier:
- Add a step() call immediately after creating timer()
- This also records the start
- Results are still cumulative
- Running diff() over it shows changes:
Demo using minimally modified Rcpp Gallery piece (just added step("start"); )
R> sourceCpp("/tmp/timer.cpp")
R> tt <- useTimer()
R> tt # cumulative
start get/put g/p+rnorm() empty loop
0.000114 1629.043000 3996.890739 3996.893329
R> diff(tt) # incremental
get/put g/p+rnorm() empty loop
1629.04289 2367.84774 0.00259
R>
I will alter the gallery story accordingly. We can always add a 'zero' step
to the constructor to get these two behaviours cheaply.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
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] Rcpp Timer
It made more sense to track times since an origin, esp when you might use several timers in case you use multiple threads. > Le 30 déc. 2016 à 13:37, Dirk Eddelbuettel a écrit : > > > On 29 December 2016 at 11:25, Jonathan Christensen wrote: > | Hi Kaspar and Dirk, > | > | It is indeed cumulative. Previously (presumably when that gallery page was > | written) it was not cumulative, but Romain Francois changed the behavior of > the > | step() function several years ago, in this commit: > https://github.com/RcppCore/ > | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. > > Nice catch. > > | There is no indication or reasoning about changing the behavior, so it may > be > | that making it cumulative was unintentional. > > Let's presume it was intentional to the author of the change -- but as you > rightly point out, it did of course change and reverse previous behaviour. > > We could easily add a toggle to the constructor to get an either/or behaviour. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > ___ > 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 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] Rcpp Timer
On 30 December 2016 at 20:38, Romain Francois wrote: | It made more sense to track times since an origin, esp when you might use several timers in case you use multiple threads. Using an offset to an origin (and hence differences) is also a sensible way to deal with higher resolutions. We cannot natively represent nanoseconds (which the Timer class uses) in R with base types: doubles use 53 bits precision which gets us a bit more than microseconds, and ints are 32 bit -- so conversion would be lossy. (The nanoseconds package I just releases uses bit64::integer64 which gets us nanosecond, but that is a higher-level depend and not something we want to depend on at the Rcpp level). Whether cumulative times, or individual measurements is better is still open fore debate. In any event, I fixed the Rcpp Gallery story at http://gallery.rcpp.org/articles/using-the-rcpp-timer/ Dirk | > Le 30 déc. 2016 à 13:37, Dirk Eddelbuettel a écrit : | > | > | > On 29 December 2016 at 11:25, Jonathan Christensen wrote: | > | Hi Kaspar and Dirk, | > | | > | It is indeed cumulative. Previously (presumably when that gallery page was | > | written) it was not cumulative, but Romain Francois changed the behavior of the | > | step() function several years ago, in this commit: https://github.com/RcppCore/ | > | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. | > | > Nice catch. | > | > | There is no indication or reasoning about changing the behavior, so it may be | > | that making it cumulative was unintentional. | > | > Let's presume it was intentional to the author of the change -- but as you | > rightly point out, it did of course change and reverse previous behaviour. | > | > We could easily add a toggle to the constructor to get an either/or behaviour. | > | > Dirk | > | > -- | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > ___ | > 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 | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ 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
