I wrote CUDA::Minimal back in late 2010/early 2011 and used it in some of my research before defending my Ph. D. dissertation in May of 2011. At my postdoc I didn't use parallel anything, so CUDA::Minimal languished. When I picked it back up, it didn't even compile on a modern version of Perl. It was disheartening, to say the least.

But now, once again, it works (as long as you're not using Perl v5.16)!!!

I just posted an entry about how CUDA::Minimal was behaving weirdly. I hadn't dug around to figure out what was going on, and I went so far as to modify the way the code was compiled and linked to get it to work! My previous post raised concerns about how I would continue with the newly-chosen path.

Well, I decided that I should really figure out what was giving trouble. After many hours (and staying up later than I ought), I figured it out. I highly suspect that these problems are due to interactions with C macros defined by nVidia, but I'm not sure. I'm going to post them here, and possibly also the the perl-xs mailing list, in hopes that they might help somebody solve problems.

There were two big changes. First, all XS code that uses ExtUtils::nvcc has to include this in their boot sections:

BOOT:
#undef PERL_VERSION
#define PERL_VERSION 0

Why? Because this generated C code that came later in the BOOT section was causing segfaults:

#if (PERL_REVISION == 5 && PERL_VERSION >= 9)
  if (PL_unitcheckav)
       call_list(PL_scopestack_ix, PL_unitcheckav);

Second, in order to get the address of the pointer value part of a scalar, I use sv_2pvbyte_nolen. I originally used SvPVX (having verified that he slot existed), but that started to return nil in this new compilation setup. I also tried using SvPVbyte_nolen, but that also returned nil. The perlapi docs for sv_2pvbyte_nolen state this function is "Usually accessed via the SvPVbyte_nolen macro," but I can't figure out if there's anything bad with using sv_2pvbyte_nolen.

You might ask why I don't file these on perlbug. Like I said, I'm not sure if these are bugs with Perl, or with the Perl-nvcc interactions. If it's the latter, I'm not so worried about them, and I'd rather at least begin by finding and documenting these troubles. I'll try to fix them if they really start giving trouble. If you have any ideas for what is going on or want me to try something to figure it out, feel free to respond here, or file a bug report on CUDA::Minimal.

And with that, I'm going to get my play-perl points. :-)

Edit: I got my original approach to work, see my follow-up.

A week ago I wrote about how I though play-perl was great. I put up a bunch of ideas and waited to see what others would encourage me to do. Two of my ideas got two votes each (some others got single votes), one of which involved revising CUDA::Minimal sot it works again. (CUDA is a means for executing massively parallelized code on your video card.) Well, it compiles now, but it doesn't quite work the way I had hoped and I am facing some basic architectural redesign issues. Herein I describe the old way things worked, and why that won't work anymore. Can anybody offer some ideas for how I might move forward?

In the last few days I've been introducing my CUDA bindings for Perl that I've put on github called CUDA::Minimal. CUDA is a framework for writing and running massively parallel code on the highly parallel computing architecture that is your video card (assuming your card is capable of CUDA in the first place). Today I am going to discuss error handling in CUDA.

Error handling is a boring topic, but it's important, so I'm going to motivate it a bit. Consider this statement from version 4.0 of the CUDA C Best Practices Guide (which you can find here):

Code samples throughout the guide omit error checking for conciseness. Production code should, however, systematically check the error code returned by each API call...

In CUDA::Minimal, you don't have to sacrifice conciseness for error-checking...

Yesterday I announced the release of my Perl-accessible bindings for CUDA. CUDA is marketed as a massively parallel, high-performance computing architecture. When you think about Perl and high-performance computing, I would hope that PDL, the Perl Data Language, comes to mind. :-)

PDL is a CPAN distribution that gives Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing. Today I will discuss how CUDA::Minimal and PDL talk with each other. (In case you're curious, tomorrow I discuss error handling in CUDA::Minimal.)

Since my first blog post back in December I've written and made thorough use of a simple Perl interface for CUDA. Today, I've posted it on github, and in this post I'll give a relatively simple example of how to use CUDA with Perl via Inline::C. (In case you're wondering, CUDA is a technology provided by nVidia that lets you compile and execute highly parallel code on your CUDA-capable video card.)

First, of course, you'll need to install ExtUtils::nvcc. At the moment this only works with Linux (maybe with Mac OSX, definitely not yet with Windows). It has only been confirmed with Ubuntu. See directions on the ExtUtils::nvcc wiki. (If you manage to install it on other systems, please let me know and edit the wiki or send me your notes!) If you have that installed, installing CUDA::Minimal is just a simple CPAN install.

First Script

So, at this point I will assume you've installed CUDA::Minimal. What can you do with it? Here's a simple example:

Over the summer I had the privilege of attending a week-long workshop on CUDA hosted by the Virtual School of Computational Science and Engineering. It was was free for students from the University of Illinois (and other partner institutions, I presume) and it was excellent. If you want to learn CUDA quickly and you want to learn it well, I highly recommend attending such a workshop.

Over the fall I started writing and using CUDA kernels in my research. This meant writing code in C. C is a great language, but it is not known for its w…