[Rcpp-devel] NVCC compatibility

[Charles Determan]

Greetings,

I have been exploring GPU implementations for R. Primarily I have been
using OpenCL given it is so portable and everyone can use it without being
tied to NVIDIA. That said, NVIDIA hardware is difficult to beat and
creating packages that leverage are arguably valuable (e.g. gputools,
gmatrix). In my efforts to explore how to best develop these types of
packages I must use NVCC but I also would like to continue leveraging
Rcpp. Normally, any compilation with NVCC would results in the following
warnings and error when including Rcpp.h.

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/r_cast.h(121): warning:
statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/r_cast.h(74): warning:
statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/vector/vector_from_string.h(42):
warning: statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/r_cast.h(54): warning:
statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/r_cast.h(74): warning:
statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/r_cast.h(121): warning:
statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/Environment.h(97): warning:
statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/vector/vector_from_string.h(42):
warning: statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/vector/Vector.h(324):
warning: statement is unreachable

/usr/local/lib/R/site-library/Rcpp/include/Rcpp/vector/proxy.h(99): error:
the object has type qualifiers that are not compatible with the member
function "Rcpp::internal::string_name_proxy<RTYPE>::get"
object type is: const Rcpp::internal::string_name_proxy<RTYPE>


I stumbled upon another github user's package that tries to address this by
a small modification in Rcpp. You can see it here (
https://github.com/jtilly/RcppThrust) were the user notes that removing the
'const' in line 98 of Rcpp/vector/proxy.h allows the compilation to succeed
(although the warnings continue).

Does anyone have any thoughts regarding this modification? Would changing
that line cause any issues? I'm not sure about the warnings at the moment
but at least nvcc and Rcpp could be used in concert.

Regards,
Charles

[Dirk Eddelbuettel]

On 9 January 2018 at 09:25, Charles Determan wrote:
| Does anyone have any thoughts regarding this modification? Would changing
| that line cause any issues? I'm not sure about the warnings at the moment
| but at least nvcc and Rcpp could be used in concert.

That is a question that is empirically answerable. As you are the one driving
this I would invite you to test it on the 1200+ reverse depends packages ;-)

Thrust rings a bell but I may be more familiar with what Norm had done. I
should look at Jan's RcppThrust then. Hm, which seems to use Norm's work.

We should probably integrate this. January is a release month though so now
is now the greatest time to push this into master. A local copy may be best,
but open to revisit.

Dirk

[Dirk Eddelbuettel]

On 9 January 2018 at 09:25, Charles Determan wrote:
| tied to NVIDIA. That said, NVIDIA hardware is difficult to beat and
| creating packages that leverage are arguably valuable (e.g. gputools,
| gmatrix). In my efforts to explore how to best develop these types of

They are also both off CRAN now!

Maintaining NVidia-using code to the satisfaction of CRAN is seemingly not
for the faint of heart.

Dirk

[Charles Determan]

Thanks Dirk, I was not aware that both were off CRAN now. And yes, I agree
that maintaining NVIDIA based packages is not easy but I certainly want to
attempt it. It seems like my gpuR package has been well received and I
would like to provide a CUDA based package as well. Anything I can do to
help make gpu computing more accessible to R users is my goal.

Charles

Post by Dirk Eddelbuettel
| tied to NVIDIA. That said, NVIDIA hardware is difficult to beat and
| creating packages that leverage are arguably valuable (e.g. gputools,
| gmatrix). In my efforts to explore how to best develop these types of
They are also both off CRAN now!
Maintaining NVidia-using code to the satisfaction of CRAN is seemingly not
for the faint of heart.
Dirk
--

[Dirk Eddelbuettel]

On 9 January 2018 at 09:51, Charles Determan wrote:
| Thanks Dirk, I was not aware that both were off CRAN now. And yes, I agree
| that maintaining NVIDIA based packages is not easy but I certainly want to
| attempt it. It seems like my gpuR package has been well received and I
| would like to provide a CUDA based package as well. Anything I can do to
| help make gpu computing more accessible to R users is my goal.

Yep. I opened an issue ticket: https://github.com/RcppCore/Rcpp/issues/797

Dirk

[Iñaki Úcar]

Post by Charles Determan
Greetings,
I have been exploring GPU implementations for R. Primarily I have been
using OpenCL given it is so portable and everyone can use it without being
tied to NVIDIA. That said, NVIDIA hardware is difficult to beat and
creating packages that leverage are arguably valuable (e.g. gputools,
gmatrix). In my efforts to explore how to best develop these types of
packages I must use NVCC but I also would like to continue leveraging Rcpp.
Normally, any compilation with NVCC would results in the following warnings
and error when including Rcpp.h.
statement is unreachable
statement is unreachable
warning: statement is unreachable
statement is unreachable
statement is unreachable
statement is unreachable
statement is unreachable
warning: statement is unreachable
warning: statement is unreachable
the object has type qualifiers that are not compatible with the member
function "Rcpp::internal::string_name_proxy<RTYPE>::get"
object type is: const Rcpp::internal::string_name_proxy<RTYPE>
I stumbled upon another github user's package that tries to address this by
a small modification in Rcpp. You can see it here
(https://github.com/jtilly/RcppThrust) were the user notes that removing the
'const' in line 98 of Rcpp/vector/proxy.h allows the compilation to succeed
(although the warnings continue).

Instead of discarding that 'const', I would try first to check whether
adding it to the getter solves the problem without breaking anything.
I.e.:

char* get() const {

instead of [1]. At least it sounds more reasonable to me.

[1] https://github.com/RcppCore/Rcpp/blob/0.12.9/inst/include/Rcpp/vector/proxy.h#L128

Iñaki

[Mark Seligman]

Post by Dirk Eddelbuettel
Thrust rings a bell but I may be more familiar with what Norm had done.
I
should look at Jan's RcppThrust then. Hm, which seems to use Norm's
work.
We should probably integrate this. January is a release month though
so now
is now the greatest time to push this into master. A local copy may be
best,
but open to revisit.
Dirk

I do fair amount of work using nvcc on Rcpp, and second Charles'
request. Please let me know if I can be of assistance more generally.

FWIW, the nvcc's biggest drawback seems to be the lag in tracking gcc.

- mls