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
| written) it was not cumulative, but Romain Francois changed the
| step() function several years ago, in this commit:
| Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1.
Nice catch.
| There is no indication or reasoning about changing the behavior, so it
| that making it cumulative was unintentional.
Let's presume it was intentional to the author of the change -- but as
rightly point out, it did of course change and reverse previous
We could easily add a toggle to the constructor to get an either/or