Just back from my third SC conference, SC09, in Portland where I was able to confirm Doug's observation that the word 'Supercomputing' no longer figures on any of the signs, banners and conference material. It's like when Kentucky Fried Chicken went to KFC, but I'm still trying to figure out what what's so bad about the words 'super' or 'computing'. Regardless, two words that were anything but denigrated at the show were 'cloud' and 'GPU', which I'd argue were the two most prevalent themes of this year's show. I'll stay more down to earth, i.e. not in the clouds, with this blog, and focus on the GPU side of things, which is obviously of greater interest to Acceleware, its customers, and hopefully its blog readers.

Recently, a long-time friend of mine decided to replace his kitchen cabinets, and learned a key lesson about core competency that I find highly relevant to what we do at Acceleware. The story started something like this: “Hey Mike, I found this great deal on some new kitchen cabinets, so I’m going to pull out my old ones and put these ones in. I figure if I work evenings I can have it done it two weekends.” Me: “Sounds cool, let me know if you need a hand” but thinking “you can’t be serious with the two weekend thing can you?” And so began the epic journey.

When the dust finally settled, literally, it took him just under three months. “Turns out I had to rip out the drywall because I damaged it pulling out the cabinets, then the insulation turned out to be moldy due to a water leak so I pulled that out, then I found out that I had lead-based solder in my pipes – replaced those too, and there was the re-wiring of the kitchen to get another circuit in there, then we figured we might as well do the tile, so it’s turned into a complete kitchen overhaul.” Sheesh! So what is the important lesson here? My friend summed it up very nicely saying “If you enjoy the challenge of teaching yourself new things, then go ahead and do it yourself, but if you want the job done, hire a professional.”

As I mentioned in my last post, Acceleware has been doing GPU programming for 5+ years now, this makes us veritable seasoned veterans in NVIDIA’s ‘GPU computing ecosystem’. This fact might cause some to wonder why we only officially released the CUDA-based version of our FDTD libraries only a few months ago. The short answer is that it took a long time to port a code base that took 3+ years to build. The more interesting story however are the benefits and results of doing that port to CUDA. This is what I want to focus on in this post.

The foremost two benefits go hand in hand and they are performance and robustness. Before CUDA we were basically hijacking OpenGL, the graphics programming language, to do GPU computing. While this worked, there were many workarounds and kludges that were required to make sure things ran smoothly. We were actually quite proud of what we accomplished in terms of performance, but there was still some left on the table, that OpenGL just couldn’t get to. The other down side was that we didn’t make any friends at NVIDIA when we reported OpenGL computing bugs. “OpenGL isn’t made for computing” they would remind us at each reprise, a fact that couldn’t have been more obvious for our developers, or more painful for me.

Recently Acceleware celebrated its 5th Anniversary.  This was a significant milestone for our company, but it also caused me to reflect on the significant evolution that has occurred in the GPU/parallel computing space over the last five years.  An evolution for which we’ve had more than a front row seat, an evolution where we’ve been an active participant, and have evolved greatly ourselves in the process.  I’d like to highlight three main points in this evolution; I will call them the  three “A”s.  They are: Acceptance, Availability,