[R-sig-hpc] How to configure R to work with GPUs transparently
Rowe, Brian Lee Yung (Portfolio Analytics)
b.rowe at baml.com
Mon Mar 22 16:26:56 CET 2010
I wonder if there isn't a simpler way of glueing this together that
produces more portable code with the cost being a little extra
configuration overhead. To me the goal is some form of functional
polymorphism that is:
1. backwards compatible (i.e. defaults to standard behavior)
2. granular enough to control processing at an object level
3. consistent with current R idioms
With danger of over-simplifying the problem, I think that the problem is
not so different from method dispatching and the UseMethod construct.
One approach is to support an additional reserved attribute on objects,
just like class() e.g. arch(). If the object has such an attribute and
it is "gpu", then appropriate dispatching could occur. Otherwise,
dispatch in the normal way. It's not difficult to see how this follows
the general approach of UseMethod (and in fact most of the changes could
probably be isolated to that function).
The configuration, then, is telling R what objects you want to pass to
the GPUs by explicitly attaching the arch attribute to those objects.
This approach would protect existing users from unexpected consequences
in situations where GPU overhead outweighs the performance gains. As
users adopted this approach, eventually certain libraries may default to
the gpu arch, but it could still be user configurable based on specific
Following this approach, I think it solves most of the need for better
code portability between GPU and non-GPU code and also provides a clear
path forward from a "standards" and consistency perspective for others
planning on writing libraries to leverage GPUs.
From: r-sig-hpc-bounces at r-project.org
[mailto:r-sig-hpc-bounces at r-project.org] On Behalf Of Norm Matloff
Sent: Friday, March 19, 2010 1:26 PM
To: r-sig-hpc at r-project.org
Subject: Re: [R-sig-hpc] How to configure R to work with GPUs
Though there is a lot of potential here, there are a lot of difficulties
For example, there is the issue of having R sense that one actually does
have a suitable GPU, and that CUDA (or OpenCL) is installed. One could
have the innards of lm(), say, do this sensing, but it would mean a
significant delay. As an alternative, this could be done when R starts
up, and then having R set some environment variable; I don't see
problems with this, but there could be some.
Next there are GPU configuration issues--numbers of rows and columns of
blocks, numbers of rows, columns and layers of threads per block, and so
on. This would be highly dependent on which GPU device the user has,
the R function being called, and things like problem size (numbers of
observations and variables).
I think a big question is whether there is enough demand out there for
this to be done. My own impression, possibly incorrect, is that the
vast majority of R users have little or no need for the power of GPUs.
By the way, if anyone is interested, I have an introduction to GPU
programming in my open-source textbook on parallel processing,
On Fri, Mar 19, 2010 at 11:55:01AM -0500, Spiers, Brad wrote:
> I am trying to get R to work with an NVIDIA GPU transparently. I
> know about gputools, but they require changing R scripts to include
> "gpu" before the relevant calls.
> According to the Cula Tools folks, R is actually a client of
> so there should be some way to get R to work with GPUs natively. I
> seriously doubt that I am the first person to try this. If someone
> done this, could you please share how you have done so? If you know
> that this does not work, could you please confirm? Thanks.
> Bradford T. Spiers
> SVP; Sr. Architect
> Technology Innovation Portfolio
> Bank of America
> 222 Broadway, NYC, NY 10038, USA
> [[alternative HTML version deleted]]
> R-sig-hpc mailing list
> R-sig-hpc at r-project.org
R-sig-hpc mailing list
R-sig-hpc at r-project.org
This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. The information contained in this e-mail was obtained from sources believed to be reliable; however, the accuracy or completeness of this information is not guaranteed. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to "Merrill Lynch" are references to any company in the Merrill Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Past performance is no guarantee of future results. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
More information about the R-sig-hpc