[Rcpp-devel] [small ann] Sparse++
Dmitriy Selivanov
selivanov.dmitriy at gmail.com
Sat Dec 31 16:41:38 CET 2016
Thanks for feedback, Dirk. This make sense - unlikely sparsepp will be used
without Rcpp (my idea was to have as small dependencies as possible). I
will add Rcpp to suggests.
2016-12-31 15:00 GMT+04:00 <rcpp-devel-request at lists.r-forge.r-project.org>:
> Send Rcpp-devel mailing list submissions to
> rcpp-devel at lists.r-forge.r-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.r-forge.r-project.org/cgi-bin/mailman/
> listinfo/rcpp-devel
>
> or, via email, send a message with subject or body 'help' to
> rcpp-devel-request at lists.r-forge.r-project.org
>
> You can reach the person managing the list at
> rcpp-devel-owner at lists.r-forge.r-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rcpp-devel digest..."
>
>
> Today's Topics:
>
> 1. [small ann] Sparse++ (Dmitriy Selivanov)
> 2. Re: [small ann] Sparse++ (Dirk Eddelbuettel)
> 3. Re: Rcpp Timer (Dirk Eddelbuettel)
> 4. Re: Rcpp Timer (Dirk Eddelbuettel)
> 5. Re: Rcpp Timer (Romain Francois)
> 6. Re: Rcpp Timer (Dirk Eddelbuettel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 30 Dec 2016 15:49:42 +0400
> From: Dmitriy Selivanov <selivanov.dmitriy at gmail.com>
> To: rcpp-devel at lists.r-forge.r-project.org
> Subject: [Rcpp-devel] [small ann] Sparse++
> Message-ID:
> <CAJdZCv3j7-DW4HkaSkNs-uHcMwc7s2+YUOhJT6Yrz=k05ggN8A@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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<uint32_t, uint32_t>, 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 <sparsepp.h> to you source/header
> 3. use spp::sparse_hash_map as drop-in replacement for
> std::unordered_map
> .
>
> --
> Regards
> Dmitriy Selivanov
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-
> devel/attachments/20161230/d3038ad2/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 30 Dec 2016 06:26:35 -0600
> From: Dirk Eddelbuettel <edd at debian.org>
> To: Dmitriy Selivanov <selivanov.dmitriy at gmail.com>
> Cc: rcpp-devel at lists.r-forge.r-project.org
> Subject: Re: [Rcpp-devel] [small ann] Sparse++
> Message-ID: <22630.21115.213619.66209 at max.nulle.part>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> 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<uint32_t, uint32_t>, 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 <sparsepp.h>?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 | edd at debian.org
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 30 Dec 2016 06:37:55 -0600
> From: Dirk Eddelbuettel <edd at debian.org>
> To: Jonathan Christensen <dzhonatan at gmail.com>
> Cc: rcpp-devel at lists.r-forge.r-project.org, Kaspar M?rtens
> <kaspar.martens at gmail.com>
> Subject: Re: [Rcpp-devel] Rcpp Timer
> Message-ID: <22630.21795.782989.138019 at max.nulle.part>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> 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 | edd at debian.org
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 30 Dec 2016 07:01:48 -0600
> From: Dirk Eddelbuettel <edd at debian.org>
> To: Dirk Eddelbuettel <edd at debian.org>
> Cc: Kaspar M?rtens <kaspar.martens at gmail.com>,
> rcpp-devel at lists.r-forge.r-project.org
> Subject: Re: [Rcpp-devel] Rcpp Timer
> Message-ID: <22630.23228.969582.535494 at max.nulle.part>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> 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 | edd at debian.org
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 30 Dec 2016 20:38:55 +0100
> From: Romain Francois <romain at r-enthusiasts.com>
> To: Dirk Eddelbuettel <edd at debian.org>
> Cc: Kaspar M?rtens <kaspar.martens at gmail.com>,
> rcpp-devel at lists.r-forge.r-project.org
> Subject: Re: [Rcpp-devel] Rcpp Timer
> Message-ID: <0B8A3AF5-91C5-40D5-AEA3-92A2846DB5F2 at r-enthusiasts.com>
> Content-Type: text/plain; charset=utf-8
>
> 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 <edd at debian.org> 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 | edd at debian.org
> > _______________________________________________
> > 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
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 30 Dec 2016 13:58:10 -0600
> From: Dirk Eddelbuettel <edd at debian.org>
> To: Romain Francois <romain at r-enthusiasts.com>
> Cc: Kaspar M?rtens <kaspar.martens at gmail.com>,
> rcpp-devel at lists.r-forge.r-project.org
> Subject: Re: [Rcpp-devel] Rcpp Timer
> Message-ID: <22630.48210.639061.279791 at max.nulle.part>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> 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 <edd at debian.org> 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 | edd at debian.org
> | > _______________________________________________
> | > 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
> |
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
>
> ------------------------------
>
> _______________________________________________
> 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
>
> End of Rcpp-devel Digest, Vol 86, Issue 14
> ******************************************
>
--
Regards
Dmitriy Selivanov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20161231/4909290c/attachment-0001.html>
More information about the Rcpp-devel
mailing list