[Technology Report]
Multicore Projects Mean Multiple Choices
Multicore solutions may be finding their way into more projects, but opinions vary on the best architecture to use.
“Once the core count meets 32 and beyond, the adoption of AMP may grow,” Verplanke adds. “Some of our customers have proprietary, often real-time operating systems that are not SMP-capable (symmetric multiprocessing). Those customers may be interested in running specific functions on separate cores. Those functions could include forwarding engines, cryptography, pattern matching, etc.”
SYSTEM OPTIMIZATION • Once you’ve chosen the architecture for your next system, assuming a multiprocessing environment, you’ll likely need to review your code to determine how to naturally take advantage of multiple cores and/or threads.
Heterogeneous multiprocessing requires an up-front understanding of how to best partition your application code to exploit the available threads/cores. In other words, how can your application best be broken up into smaller pieces? Homogeneous multiprocessing generally has no such requirement, since the operating system will handle most of the partitioning based on some basic task definitions and up-front tweaks.
Part of parallelism today is virtualization and knowing when to use it. According to Intel, if your legacy code has low performance requirements, it may be a good candidate for virtualization. But Rick Hetherington, Sun’s CTO of Microelectronics for the Niagara program, offers a slightly different opinion.
“It doesn’t make sense to virtualize a single core,” says Hetherington. Of course, Sun’s perspective is likely more relevant in the general computing space. The embedded space allows for virtualization of even a single core when the complexity permits it.
If you’re new to a multiprocessing environment, consider trying out incremental “what-if” scenarios to find bottlenecks and candidates for parallelization. You may also find the need to port your code to a standard operating system that’s designed to take advantage of multiprocessing architectures, such as Linux.
If porting millions of lines of code isn’t an option, a hypervisor may be your best bet. Another approach is to offload common tasks from cores, such as data encryption and decryption. This will free up the core for more general-purpose tasks.
MULTICORE’S FUTURE • Anant Agarwal, professor at the Massachusetts Institute of Technology and CTO of semiconductor startup Tilera, said at this year’s Multicore Expo in Santa Clara that the tools to program and debug multicore ICs are in the “dark ages.” Apparently, quite a few unemployed cores and threads are out there looking for work. But the problems aren’t just related to tools.
“First-generation multicore processors have been a simple integration of a group of cores into an SoC (system-on-achip),” says Dan Bouvier, director of Solutions Architecture for AMCC. This has translated to rather poor performance scaling due to the overhead required to handle multiprocessing and memory bottlenecks.
“The forthcoming generation of multicore processors will need more attention toward interprocessor dynamics and how they impact the software deployment and performance,” says Bouvier. “The primary challenge in integrating upper-layer (above layer 3) accelerators in asymmetric multiprocessor subsystems is the lack of standard, agreed-to APIs.”
Such a standard exists for computer graphics in OpenGL, which defines a cross-language and cross-platform API for producing applications that produce 2D and 3D graphics. Unfortunately, with no tool standards built around open-source APIs driven by industry experts across multiple segments, we have to work with what’s available today and perhaps rethink our design strategies.
“The programming model and software stack are the key enablers (or inhibitors) for taking multicore to the next level,” says AMD’s Moore. “By working closely with our software colleagues, we will come up with solutions that offer tremendous value to our customers.”
And what’s happening on the software front? “There is a fundamental shift in multiprocessor design, with an associated change in the software paradigms and models used, as multicore, coherence, and formal interprocessor communication schemes are adopted,” says John Goodacre, program manager for multiprocessing at ARM.
So not only is this shift causing a general rift in the embedded community, it also forces the systems engineer to rethink the decision process. “There are principle changes across the hardware and software as SoC designers consider the move from ARM plus DSP to multicore plus DSP plus accelerators plus RISC and the challenges of memory coherence, consistency, and task synchronization,” says Goodacre.
Reprints
