We've been using CUDA to speed up Monte Carlo pricing for years now. :) Writing in Python does make it more accessible to more programmers. I'm curious how much overhead is added.

http://www.wallstreetandtech.com/it-infrastructure/bloomberg...

It would be more interesting to see a visualization of throughput vs. problem size. That would almost certainly give a better sense of how good this approach is, and it would let us compare to other CUDA monte carlo implementations, like the one Nvidia has had on their CUDA site for years:

http://developer.download.nvidia.com/compute/cuda/2_2/sdk/we...

This particular problem is so embarrassingly parallel, I am surprised the speedup is only 14x.

If you look at the hardware specs that's what you expect. People claiming more are not usually measuring the whole problem

http://www.hpcwire.com/hpcwire/2011-12-13/ten_ways_to_fool_t...

Second that one. On these sort of problems it's not uncommon to see 100x+ speedups. My general experience is that just re-writing this in C++ instead of Numpy you'd see a >14x speedup, so I'm pretty unimpressed at this point.

If you look at the profiler screenshot at the bottom of the page, the time spent in the cuRAND kernel (cyan) is ~2x longer than in the numbapro kernel (purple). Even if the numbapro kernel is written in CUDA-C and suppose it will be a lot faster, you still won't hit 100x speedup. In addition, all kernels are double-precision, the 100x speedup is more common for single-precision kernels.

I'm be surprised if there was that large of a speedup going from a well-written numpy implementation to C/C++ (assuming a non-parallel implementation in both)...

In my experience, it's usually more like 2x-5x for a straight translation of the algorithm from numpy to C. (Though I have to confess that I often write rather naive C...)

Numpy performs quite well if you avoid a few common pitfalls. It certainly can be beat, but it's often faster than people think it is.

That matches my experience as well. I've never gotten more than a 3x speed up by doing a straight numpy->C rewrite on actual real world code (actually doing one right now, and I've gotten a 2x speed up after my first pass).

NumbaPro generates CUDA code that runs on the GPU. I don't see how using C++ to do it would necessarily make it faster as the code executing on the CPU end of things is not the bottleneck.

From my experience with CUDA/OpenCL, its easy to get a working algorithm that provides some speedup, but getting it to fully utilize the GPU takes some manual optimization.

Things like optimizing memory accesses to prevent bank conflicts, using per thread-group shared memory effectively to reduce global memory accesses are a bit tricky to get right, and I'm not sure how well auto-generated code would be able to do this.

I wonder if there's any good way to select random indexes from a bitmap using CUDA. If yes, this could be very nice for monte-carlo poker hand scoring.

That's something the demoscene loves to do. There's a few ways to do it, but what's usually done is to have a large bitmap filled with random values that's accessed by a function of threadID and current pixel (or whatever other info you have handy). Essentially, the large bitmap acts as a precalculated PRNG.

>There's a few ways to do it, but what's usually done is to have a large bitmap filled with random values that's accessed by a function of threadID and current pixel (or whatever other info you have handy).

Do you have any good links that elaborate on this kind of technique? I had an idea that sounds a lot like this once, but being fairly ignorant about the topic I had no idea what to call it or how to implement it.

Thanks.

This is probably the simplest article about the subject: http://www.reedbeta.com/blog/2013/01/12/quick-and-easy-gpu-r...

Anyone outside of Continuum who can share their experiences with Numba and/or NumbaPro?