C++, CUDA, Python, and Really Big Cameras

I can’t believe this blog is still here. Amazing. I figured WordPress would close it down by now.

A lot has happened since the last entry. My book was released by O’Reilly (and it’s been doing OK), I came down with a severe case of food poisoning (and ended up in the ICU), and some months later had triple-bypass open-heart surgery (and another stay at the Hotel ICU). Fun times.

Here’s a link to the book, if you’re interested (shameless self-promotion):


and of course it’s also available on Amazon.

Anyway, enough of that. Now that I’ve cheated Death yet again and I’m all better, I want to start writing some more for this blog. For the past 2 and 1/2 years I’ve been working on the MOSAIC/AWARE gigapixel camera project with Professor Mike Gehm’s group at the University of Arizona. I’m the “Research Computing Specialist, Principal”, whatever that means, and my job is to create the real-time (as real-time as possible) software that acquires image data from hundreds of small micro-cameras (we call them sensors), organizes it, passes it along to a GPU sub-system that does the rotations, tone mapping, and stitching to make a complete composited image, and then either saves the image (if it’s super-huge) or passes it back to a GUI for a user to admire. You can read more about it at these links:


For those who might be curious about the software involved in this system, here is a brief overview. The cameras themselves have their own firmware, which is a composite of C code for an embedded microcontroller and FPGA gate logic. I don’t really have anything to do with that, other than to write an occasional bug report or request a particular feature. I do a lot of testing. The sensors are being built by Distant Focus Corporation in Illinois. Here at the U of A we are providing the overall data acquisition and processing functions. This is written primarily in C++ and runs on Linux and an Nvidia Fermi class GPU. The GPU code is written in CUDA, with wrappers to allow the resulting CUDA libraries to link with the C++ object code. The entire command-acquisition-composition-response cycle is controlled by a state machine.

The Linux system with the GPU hardware is referred to as the ADM, or AWARE Data Manager. With the GPU, the computing hardware has been reduced from a cluster of eight or ten  multi-core Dell servers in a 19″ rack to a single 8-core desktop PC, and it’s faster as well. A prototype GUI has been created in MATLAB (yeah, really!), and it communicates with the ADM via a network socket using an ASCII character-based protocol. The interfaces to the sensors also employ network connections. In other words, this can be a distributed system, assuming that the network channels are fast enough (1GB or better). The folks at Duke University have been busy creating various diagnostics and display tools in Python (and some Java), as well as managing the whole project.

It’s been an interesting experience for me to get back into C++ after many years working with Python and C. I’ve never been a huge fan of the language, mainly because I never completely accepted the rationale for its existence, but I do find a lot of utility in the OO paradigm. C++ is also, in my opinion, one of the easier languages to abuse by its very nature, and over-eager developers have a tendency to use features of the language in ways that are perfectly valid, but which obfuscate what’s going on. In many cases a simpler approach would work just as well and not create code full of overloaded operators or obtuse class relationships. A lot of the C++ code I see in other projects leaves me scratching my head and saying “Why?”. In this regard Python is much more straightforward in its OO aspirations, since it’s an OO language from the outset. It just pretends to be procedural if you ask it to do so. C++ is a superset of C (a “better C” according to its creator, Bjarne Stroustrup), but certain features of the language seem somewhat clumsy to me. Like a suit of clothes that look OK, but don’t fit quite right.

In any case, I have found good uses for classes, function overloading, and strict type checking. Inheritance is also useful, if the base classes are well documented. Other features of C++ can lead to situations where I have to dig down to an abstract base class to try and figure out what a derived class is doing in a polymorphic situation. I’m not saying that abstract base classes, inheritance, or polymorphism are bad things, far from it. These are very powerful techniques, but they are not without pitfalls for the unwary.

I know that Stroustrup has stated that one can obfuscate in any language, and I generally agree. Python has its own obfuscation traps with dictionaries and lists, and I’ve had to wade through assembly language in the past that was something out of a coding nightmare. My point here is that with C++ it’s easy to create dense, virtually impenetrable code without a lot of extra effort just by following the C++ paradigm. Toss in developers who resist documenting anything in any detail, and you may end up with a lot of cryptic stuff that will probably never be reused again, if it even gets used the first time.

So long as one can have a high level of confidence in the things that are hidden (just as we have a high level of confidence in the standard library components), then it’s all good. But, when it’s just me working on a project, if I can’t easily see the context where something is defined and used, then I tend to be suspect of its purpose and suitability. I have to take the time to go and look to make sure I understand what something is supposed to do. Perhaps in a situation where there is a team that does nothing but create amazingly useful classes, fully tested and supplied with comprehensive documentation, it would be easier for other teams to accept the veracity of the code and use it without losing too much sleep over it. But when it’s a small team (maybe 1 or 2 people), then this is usually a happy fantasy rather than a reality. After a month or three, the developer(s) will have to go back and dig down through the layers of inheritance and polymorphic relationships to figure out what’s going on. That’s not efficient, and erroneous assumptions might be made to avoid doing it. That’s a sure-fire way to introduce some really nasty bugs into the code, some which will undoubtedly surface during the project demo. Not good.

So, in general, my opinion of C++ is that Strousrup should have perhaps just left C alone and created a new language from scratch, which is what has effectively happened over the past 30 years, anyway. What started as “C with Classes” has evolved into modern C++, which happens to have the ability to parse plain old C code and shares a lot of the same operators and keywords. I’ve also come to the conclusion that C++ is a language well suited for an environment with lots of warm bodies, coding style rules, and established development and testing procedures (e.g NASA, Boeing, or Lockheed). Unless some definite rules are established up-front as to what features of the language will, and will not, be used, it is something that a single developer or a small team may end up struggling with. If not during development, then surely during testing and demonstration, or even, horror of horrors, after it is released, which is the last place one wants to find defects and deal with them.

These issues with C++ aren’t unique to me alone, by any means. For a long time the FAA was reluctant to accept any safety-critical code written in C++ for use in commercial aircraft, mainly because it could be extremely difficult to review and test to the FAA’s satisfaction. It was deemed to be inherently risky, and the likelihood of hidden defects was considered to be too high to be acceptable. I believe that this attitude has shifted as more experience has been gained with C++ in aerospace applications, but the reality is that in order to take advantage of the capabilities of C++, one must be willing to follow strict guidelines for writing and testing code with a language that lends itself so well to unintentional obfuscation (in all fairness, I’ve leveled the same criticism at Python in the past–dictionary objects are just too damn easy to abuse in creative ways).

I guess the upshot here is that, yes, C++ is powerful and flexible, but so is a black mamba snake. It should be handled with extreme care.

On another topic, I’m looking for reviewers. I have several books in the pipeline, and I’m in need of people with technical expertise who would be willing to review chapter drafts and provide useful feedback. Unfortunately, there isn’t much in the way of money involved (well, none, actually, unless a publisher wants to provide something), but there is the chance to have your name in print in the acknowledgements section, possible discounts on other books from the publisher (this varies from publisher to publisher), and you can put it on your resume. I’m not really looking for proofreaders, those I get for free. I’m in need of people with expertise in C, Python, C++, electronics, microbiology, and basic organic chemistry. The review would generally be involved with one or two sections of a text, not necessarily the entire book.

Well, that’s all for now. I’ll be back. I’ve got a lot more to write about.


1 Response to “C++, CUDA, Python, and Really Big Cameras”

  1. 1 tai viinikka June 16, 2016 at 7:03 am

    Glad to see you came back! Hope the main pump is still working OK.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Follow Crankycode on WordPress.com

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: