Thank you for the detailed response.
At the risk of belabouring, a portion of the Marsenne Twister code
contains two kernel/functions for the Box Muller transformation calcs.
One is defined __device__ and the other which draws on calcs of the
first is a __global__. Would it be possible to re-code the first as a
__global__ with appropriate changes internally as well and then wrap
the two with Pycuda or am I missing something more obvious? This may
not be an efficient use of the device but could be faster than
porting. Of course there is a larger portion of C which accesses the
host and would need to be dealt with as well.
On Mon, Jun 29, 2009 at 2:00 PM, <pycuda-request(a)tiker.net> wrote:
> Send PyCUDA mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of PyCUDA digest..."
> Today's Topics:
> 1. Re: Wrapping SDK code... (Andreas Kl?ckner)
> 2. Re: OpenGL interop woes... help! (Andreas Kl?ckner)
> Message: 1
> Date: Sun, 28 Jun 2009 15:51:28 -0400
> From: Andreas Kl?ckner <lists(a)informa.tiker.net>
> Subject: Re: [PyCUDA] Wrapping SDK code...
> To: pycuda(a)tiker.net
> Message-ID: <200906281551.29553.lists(a)informa.tiker.net>
> Content-Type: text/plain; charset="windows-1252"
> On Freitag 26 Juni 2009, Vince Fulco wrote:
>> Early attempts to port over the Monte Carlo Option Pricing code
>> supplied with the SDK and need to mod it for simple time series
>> bootstrapping. Not being terribly facile in C/C++ (but learning!),
>> could someone provide a short list of the critical components which
>> need to be wrapped by pycuda?
> What PyCUDA can do for you is compile and execute functions marked __global__
> in that sample's source code--i.e. code that runs on the GPU. Everything else
> is CPU code, and making that accessible is beyond the scope of PyCUDA. If you
> do want to leave that CPU code in C, there are several other packages that
> might help you, ranging from Swig, Cython, Boost Python (potentially with
> codepy), to ctypes.
> I'm guessing that you might have the most fun if you just port the CPU control
> code to Python, though--less hassle.
>> I am aware of the various
>> kernels/functions necessary from the main body of code but more
>> interested in a how-to in terms of referencing the ancillary functions
>> properly. I.E. the RNGs "MonteCarlo_SM10" and
> See above--if you want to keep those in C, use one of the packages mentioned
> above (and worry about compiling them separately), or just quickly translate
> them to Python. (you'll find they get a fair bit shorter :P)