“I believe robots should only have faces if they truly need them.” – Donald A. Norman, PhD.
Two heads are better than one. But too many cooks spoil the broth. Which aphorism applies to multicore programming?
We all know that multicore processors are here, but, like the impending robot apocalypse, we’re not sure what to do about it. It’s all very nice to ooh and ahh over the latest multicore processors – Twenty cores! Forty cores! Bring ’em on! – but when it comes time to actually code the things… we’re often left staring at our shoes.
Programming multicore is hard (who knew?), but help is on the way. From several quarters, in fact. One of the beneficent entities is the Multicore Association which, it must be said, is appropriately named. They’re all about multicore hardware and software, and they’ve come up with a cunning plan.
It’s called MTAPI, and it’s a new multicore task-management (the that’s the MT- part of the name) application programming interface (the -API part) for multicore hardware with different (i.e., heterogeneous) computing resources. Got a DSP, a CPU, and a GPU all cohabitating in your system? Not sure how to allocate tasks to them all? MTAPI is here to help.
Like any API, MTAPI is just a set of rules, not code. It’s an agreed-upon interface layer between what you want and what the system can provide. It provides a framework for parallelization without having to know exactly how parallel your hardware is. And, like any API, it accommodates updates, upgrades, and complete overhauls of the underlying hardware.
In MTAPI’s view of the world, multicore programming is broken up into Jobs, Actions, and Tasks. A Job is simply a high-level abstraction along the lines of, “I want to apply a filter to these JPG images.” The Job is then broken up into Actions, which will be dispatched to individual hardware units, like a DSP or a GPU. Finally, Tasks are callable routines that perform the actual work of the Action. In a dual-processor system, you might have one Job (filtering the images), two Actions (one for the GPU, one for the DSP), and several Tasks that perform the hardware-specific filtering.
The idea is that you can replace the underlying hardware with more, or fewer, computing resources but retain the structure of your Jobs and Actions. The Tasks are generally going to be hardware-specific.
That may all sound pretty vague, but getting even that far was an achievement. There are lots of parallel-programming frameworks around (OpenGL and CUDA, for instance), but they’re intended either for heavyweight computer systems or for specific application areas like 3D graphics or gene folding. What the Multicore Association wanted was an API for embedded systems that wasn’t domain-specific.
To back up its interface, the group also created EMB2. It’s the meat in the MTAPI sandwich: a real, working library of code that implements many of the MTAPI APIs for resource-constrained embedded systems. The EMB2 library (which stands for Embedded Multicore Building Blocks, natch) was developed mostly at Siemens for use by its own developers in different business areas. Siemens has its fingers in a lot of pies, and the company’s far-flung developers were often trying to solve the same problems, on opposite sides of the world. Thus, the company decided to bite the bullet and take the lead in developing EMB2, partly to satisfy its own requirements and partly because it’s an active member of the Multicore Association and that’s the right thing to do.
EMB2 is free, open-source code with its own website. It comes with its own task scheduler, although you’re free to use an RTOS or other operating system if you prefer. Key among its design guidelines was determinism: EMB2 does not allocate memory on the fly. Once an object is allocated or a task instantiated, its memory is fixed. No runtime garbage collection here.
The current task scheduler is fairly… straightforward. It simply dispatches Actions (in the Job-Action-Task sense) to the next idle processor core, regardless of whether it’s a DSP, a CPU, a GPU, or some other compute engine. As such, some tasks may get assigned to processors for which they’re ill-suited, but that’s better than nothing, and better than hand-coding processor affinities. Future versions of EMB2 will be a lot smarter about pairing up software with the appropriate hardware.
Although EMB2 is a giveaway, it’s also solid, production-ready code that’s been through the corporate software-quality wringer, according to Siemens. It’s also not the only way to implement MTAPI standards. Other developers can implement the same feature set in other ways. Indeed, a few Multicore Association members have already scurried off and created their own equivalents to EMB2 for their own internal use. Commercial alternatives might also be on the horizon. EMB2 is the first, but probably not the only, solution to the multicore problem.
The MTAPI standard and the EMB2 library bridge the gap between theory and existence proof. MTAPI tells us how it should be done; EMB2 shows how it can be done. Between the two, we’re a lot farther along in our march toward robot domination.
Leave a Reply
You must be logged in to post a comment.