Wolfram Blog
Ulises Cervantes-Pimentel
Abdul Dakkak

Tapping Into the Power of GPU in Mathematica

September 20, 2010
Ulises Cervantes-Pimentel, Senior Kernel Developer
Abdul Dakkak, Kernel Developer

Last week we posted an item about Wolfram Research‘s partnership with NVIDIA to integrate GPU programming into Mathematica. With NVIDIA’s GPU Technology Conference 2010 starting today, we thought we would share a little more for those who won’t be at the show to see us (booth #31, for those who are attending).

Mathematica‘s GPU programming integration is not just about performance. Yes, of course, with GPU power you get some of your answers several times faster than before—but that is only half the story.

The heart of the integration is the full automation of the GPU function developing process. With proper hardware, you can write, compile, test, and run your code in a single transparent step. There is no need to worry about details, such as memory allocation or library binding. Mathematica handles it elegantly and gracefully for you. As a developer, you will be able to focus on developing and optimizing your algorithms, and nothing else.

Here are a couple of examples to give you a taste of the upcoming feature.

We have often been asked whether it is possible to do 3D volumetric rendering with Mathematica. It’s a natural question, considering that Mathematica has supported DICOM format for a while. There have been a few solutions, but nothing was perfect nor fully integrated with Mathematica—until now. With the power of GPU, you can embed interactive volumetric images into your notebook.

3D volumetric rendering with Mathematica

Another example is ray tracing. The following image shows a ray-traced Quaternion Julia set using GPU. We can perform real-time ray tracing and maintain an interactive frame rate on consumer-level graphics hardware.

Ray-traced Quaternion Julia set using GPU

Of course, this is just the tip of the iceberg. We chose these examples simply because they look beautiful. You will be able to see more examples and applications during the NVIDIA conference, so again, stop by booth #31 if you get a chance.

Not attending the NVIDIA conference, but interested in learning more? There’s still time to register to attend the Wolfram Technology Conference 2010 taking place in October and learn how you can tap into the power of GPU in Mathematica.

Leave a Comment

11 Comments


muser

“With proper hardware, you can write, compile, test, and run your code in a single transparent step.”

Wow, this sounds impressive. Could you please post examples?

From the Wolfram Technology Conference 2010, it seems that Mathematica 8 will be relased within a month and include NVIDIA CUDA support, Wavelets, Control Systems….

Posted by muser    September 20, 2010 at 7:12 pm
Mooniac

This is massive …

Posted by Mooniac    September 20, 2010 at 7:19 pm
Raul Huertas

Insane! this is awesome!

Posted by Raul Huertas    September 20, 2010 at 8:48 pm
Robinaut

Will this be supported by Mathematica 8? When is Mathematica 8 going to be released?

Posted by Robinaut    September 20, 2010 at 11:27 pm
Luboš Motl

Impressive. Obviously, relatively to Mathematica 7.0.1, the software needs to massively speed up – and perhaps improve other things – if it is going to be useful for the creation of animated graphics etc. – something that Mathematica is, in principle, designed to do nicely but something whose usefulness is greatly reduced by the current speed, GPU-ignoring, parallelism-disabling limitations.

Posted by Luboš Motl    September 21, 2010 at 2:04 am
Jan Hernandez

I have no doubt that impressive things can come of this, but the real question is how hard will it be to code for massively parallel systems? Mathematica has long had the ability to run on multiple processes/cores, but almost nobody ever does because it has always been a hassle.

Posted by Jan Hernandez    September 21, 2010 at 2:03 pm
Maynard Handley

So Jan and Lubos hint at the issue that is of more interest to most of us. It’s nice to have some sort of support for GPUs in Mathematica, but this is some what specialized, and what most of us care about much more is much better utilization of the parallelism in existing machines — for something other than dense machine precision linear algebra and FFTs.

Which raises the real question. Obviously, at a 1000 mile level, Mathematica provides a perfect environment for programming GPUs — express what you want via Table or Map or some similar such primitive, and have the system run each sub-calculation in parallel on one of the GPUs execution engines.
Of course it’s not quite that trivial, because there is the problem of exactly what each of those sub-calculations looks like, and (right now) they usually boil down, eventually, to pattern matching inside the Mathematica Kernel, which has not (so far?) been parallelized.

So the real issue of interest to us is: to get this to work, did you simply slap on a band-aid (somewhat like the ParallelMap/ParallelTable/etc), or did you do the low level work to make sure that most “reasonable” Mathematica code will be dramatically sped up?
AND if that is the case, does this mean we will see this same technology applied to the rest of Mathematica.
Even apart from parallelizing the kernel (admittedly a hard problem) there is a lot of low lying fruit that, even in 7, was not being picked.
Obvious examples include
- using SSE/AVX when there will be a lot of parallel computation (eg in filling in Table or in numeric integration, or in various plots (esp 3D and density type plots
- likewise at a higher level using multiple CPUs for numeric integration and plots, and anything that involves searching over a large space (NMinimize, numeric integration) and to generate large quantities of randomness and then random numbers, etc etc
- at the very least, give us a version of ParallelMap etc that all see a SINGLE Mathematica kernel so we don’t have to go through this nonsense of exporting the relevant definitions to the other kernels (not to mention the wasted memory).

Obviously changing things for parallelism means that various items will break. Things broke frequently with early upgrades to Mathematic and you know what — it was worth it. If the user wants to write weird code that involves the update of a global by every successive call to a function being plotted, or whatever, give them the means to do so — but the bulk of us writing “normal” code shouldn’t have to be held back by such weird edge cases.

So there you are — that’s what would REALLY excite us. Not being told that we can write to CUDA for some set of problems of interest to but a small fraction of us, but being told that Mathematica 8 is the Parallelism Edition, and that for pretty much anything it will run at a factor of N faster, where N is your number of CPUs, with, for many purpose, a further factor of 2 faster from use of SSE (with a factor of 4 coming with AVX in SandyBridge).

Posted by Maynard Handley    September 21, 2010 at 10:37 pm
Herbert Exner

Yes, this is really another break-through striving for high-performance at low cost.
We will talk about our experiences with CUDA at the Technology Conference 2010
see: http://mathplugged.blogspot.com/2010/09/we-speak-at-wolfram-technology.html “Taming the Machine Infernal”

The core statement: because Mathematica is used as a universal interface to CUDA frameworks, users are not exposed to low-level complexities of GPU programming.

Posted by Herbert Exner    September 22, 2010 at 5:25 am
Daniel smith

Is the GPU acceleration NVIDIA CUDA only or is there support for ATI card using OpenCL or similar?

Posted by Daniel smith    September 22, 2010 at 9:23 pm
Crni

Just read the whitepaper; to be honest, I’m less than impressed. All the additions are nice, but that now “users are not exposed to low-level complexities of GPU programming”, as Herbert mentioned above – please, gimme a break… So we are spared now with managing data transfers between CPU and GPU memory, and some rudimentary Mathematica functionality (basically, BLAS and FFT, as well as some image operations) is now CUDA enabled. But for the most of time we’re still supposed to write CUDA kernels by hand, and if I have to do so, I’d probably keep doing everything else by hand – this other stuff is not that hard after all, and this way at least I have all the other tools (debugger, profiler etc.) from the CUDA C SDK at my disposal… So, again: this is all great and welcome, but definitely AccelerEyes guys with their Jacket plugin for Matlab have a strong edge here.

Posted by Crni    October 22, 2010 at 2:12 am
Chris

It seems like Maple 15 has much more to offer here.

Posted by Chris    May 30, 2011 at 8:39 pm


Leave a comment

Loading...

Or continue as a guest (your comment will be held for moderation):