Re: Octave and CUDA

[mpender]

Sorry, please ignore the junk after the first signature line -- I was
working on another email to Kai about template syntax.


On Tue, Jan 14, 2014 at 12:28 AM, Michael Pender
<address@hidden>wrote:

> 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-tp4660998p4661052.html
Sent from the Octave - General mailing list archive at Nabble.com.