Re: Octave and CUDA

[mpender]

Hello Daniel,

I was thinking along the same lines.  I tried using OCTAVE_LOCAL_BUFFER to
reserve the memory and then preserve the pointer to the buffer in a global,
but it didn't work the way that I expected.  Reserving memory (in the
Octave memory space) seems limited to the Octave-recognized variable types.
 Recasting a handle as an integer and storing it in an Octave global should
work as a hack.  But when multiple variables are stored in the CUDA
device memory space, then some minimal memory management functions will
likely be needed.  I've started looking at SWIG for Octave (
http://www.swig.org) as a possible solution.

I had hoped to be able to implement a package or similar CUDA
implementation for Octave to get broader interest in the Octave community.
 Now I am starting to think my goal may be too ambitious for the moment.

Thank you for your advice,

- Mike


Thank you for the example; I'm not that familiar with C++ templates and
will be studying it closely.  What I really need though is the ability to
reserve a buffer and then access it repeatedly on successive calls to
either the same oct file or related oct file.  My octave script repeatedly
performs iterative calculations on related matrices, but the matrix is
partially repopulated with random values between iterations.  I call one
oct file to reserve the memory, then I call another oct file to calculate
the fitness of the solutions in the matrix (this is performed repeatedly).
 I think this approach will only work if I move the initialization and
iterative calculations all into the C++ section, which would be very, very
hard to do.

I was attempting the local_buffer approach as one attempt to allocate a
buffer that is global, writable from C++, and accessible across either
separate oct files or iterative calls to the same oct file.  It seemed the
most straightforward approach, but since Octave enforces copy-on-write with
passed parameters and does not have a pointer type I'm looking at other
approaches.

At the moment my C++/oct file implementation is about 3x - 4x *slower* than
the vectorized version that I'd written in pure Octave.  I'm surprised the
speed is not at least comparable. My next attempt will probably involve
allocating the memory and then recasting the pointer as an unsigned int,
then passing the unsigned int as a global.  The C++ oct files should be
able to turn the unsigned int back into a pointer and use it to access the
memory.

Ideally, I would like to find a way to turn CUDA utilization into just
another package that people can install.  Octave would rock with a
just-in-time compiler and integrated CUDA use.  It would probably rocket
past Matlab in terms of speed.

Thanks for your guidance,

Mike


On Mon, Jan 13, 2014 at 1:51 AM, Daniel Kraft [via Octave] <
address@hidden> wrote:

> Hi!
>
> On 2014-01-13 07:33, Michael Pender wrote:
> > Thanks for the reply.  I remember studying your work before and taking
> > to heart the part about the overhead from memory copy operations.  I'd
> > like to find a way to reserve memory on the CUDA platform and then keep
> > it available, so that the overhead from copy operations and memory
> > bandwidth is minimized, but Octave's pass-by-value approach and lack of
> > a pointer data type makes it difficult.  I still think it is possible
> > though...
>
> Yes, that's a bit bad.  In general, I've multiple times had the feeling
> that it would be great to have a way to define "new data types" for
> Octave that could encapsulate external data structures (basically like
> file handles and things like that) and would be "black boxes" for Octave
> itself.
>
> You can probably do it by storing a pointer reinterpret_cast'ed to
> integer into an Octave variable, and using that "integer" as handle.  In
> the case of GPU memory, you'd cuda_malloc the block and then cast the
> resulting pointer; or you could even construct your own C++ data
> structure holding the CUDA memory pointer plus additional data you want,
> and store a pointer to your internal data structure in the Octave integer.
>
> I've never tried that myself, though, since I've not had urgent needs
> for it so far.  It is a hack, but I presume it would work.
>
> Yours,
> Daniel
>
> --
> http://www.domob.eu/
> --
> Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
> To go: Mon-Pri
> _______________________________________________
> Help-octave mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=4661001&i=0>
> https://mailman.cae.wisc.edu/listinfo/help-octave
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
> http://octave.1599824.n4.nabble.com/Octave-and-CUDA-tp4660998p4661001.html
>  To unsubscribe from Octave and CUDA, click 
> here<http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4660998&code=bWljaGFlbC5wZW5kZXJAZ21haWwuY29tfDQ2NjA5OTh8MTM3ODg4NTI0>
> .
> NAML<http://octave.1599824.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Octave-and-CUDA-tp4660998p4661051.html
Sent from the Octave - General mailing list archive at Nabble.com.