Embedded Systems Design Europe - March 2008 - (Page 38)

multicore prediction, nuclear simulations, and the like. The crucial question becomes: How much can your embedded application beneﬁt from parallelization? Many problems have at least some amount of work that can take place simultaneously. But most problems have substantial interactions between components that must take place in a sequence. It’s hard at best to decide at the outset, when one is selecting the processor, how much beneﬁt we’ll get from going multicore. Marketing literature from multicore vendors suggest that a two-core system can increase system performance from 30 to 50% (for desktop apps; how that scales to embedded systems is another question entirely, one that completely depends on the application). Assuming the best case (50%) and working Amdahl’s Law backwards, one sees that the vendors assume a third of the PC programs can be parallelized. That’s actually a best, best case, as a PC runs many different bits of software at the same time and could simply split execution paths by application. But, pursuing this line of reasoning, assuming the dramatic 50% speed improvement comes from running one program, the Law shows that with an inﬁnite number of processors the best one could hope for would be a 3x performance boost (excepting the special case of intrinsically parallel programs). Then there’s the bus bottleneck. Each of the twins in a dual-core SMP chip has its own zero wait-state cache, which feeds instructions and data at sizzling rates to the CPU. But once off L1, they share an L2, which though fast, stalls every access with a couple of wait states. Outside of the L2, a single bus serves two insanely high-speed processors that have ravenous appetites for memory cycles, cycles slowed by so many wait states as to make the processor clock rate for offchip activity almost irrelevant. And here’s the irony: a multi-gigahertz CPU that can address hoards of gigabytes of memory, that has tens of millions of transistors dedicated to speeding up operations, runs mind38 numbingly fast only as long as it executes out of L1, which is typically a microscopic 32 to 64 kbytes. PIC-sized. Run a bigger program or one that uses lots of data, and the wait-state logic jumps on the brakes A couple of Z80s might do almost as well. In the embedded world, we have more control of our execution environment and the program itself than in a PC. Some of the RTOS vendors have come up with clever ways to exploit multicore more efﬁciently, such as pinning tasks to particular cores. I have seen a couple of dramatic successes with this approach. If a task ﬁts entirely within L1, or even spills over to L2, expect tremendous performance boosts. But it still sort of hurts ones head – and pocketbook – to constrain such a high-end CPU to such small hunks of memory. Any program that runs on and off cache may suffer from determinism problems. What does “real time” mean when a cache miss prolongs execution time by perhaps an order of magnitude or more? Again, your mileage may vary as this is an extremely application-dependent issue, but proving a real-time system runs deterministically is hard at best. Cache, pipelines, speculative execution, and now two CPUs competing for the same slow bus all greatly complicate the issue. By deﬁnition, a hard real-time system that misses a deadline is as broken as one that has completely defective code. Multicore does address a very important problem, that of power consumption. Some vendors stress that their products are more about MIPs/watt than raw horsepower. Cut the CPU clock a bit, double the number of processors, and the total power needs drop dramatically. With high-end CPUs sucking 100 watts or more (at just over a volt; do the math and consider how close that is to the amps needed to start a car), power is a huge concern, particularly in embedded systems. Most of the SMP approaches that I’ve seen, though, still demand tens of watts, far too much for many classes of embedded systems. One wonders if a multicore approach using multiple 386s stripped of most of their fancy addressing capability and other bus management features, supported by lots of “cache,” or at least fast on-board RAM, wouldn’t offer a better MIPS/watt/price match, at least in the embedded space where gigantic applications are relatively rare. Finally, the holy grail of SMP for 30 years has been an auto-parallelizing compiler, something that can take a sequential problem and divide it among many cores. Progress has been made, and much work continues. But it’s still a largely unsolved problem that is being addressed in the embedded world at the operating-system level. QNX, Green Hills, and others have some very cool tools that partition tasks both statically and dynamically among cores. But expect new sorts of complex problems that make programming a multicore system challenging at best. HERE TO STAY Although this rant may be seen by some to be completely dismissive of multicore, that’s not the case at all; my aim is to shine a little light into the marketing FUD that permeates multicore, as it does with the introduction of any new technology. Multicore processors are here to stay and do offer some important beneﬁts. You may ﬁnd some impressive performance gains by employing SMP, depending upon your speciﬁc application. Do see David Kleidermacher’s article about it at www. embedded.com/design/205203908. Most of my complaints disappear when each core runs code from its own memory space. Tensilica has some customers getting astonishing performance gains using this approach. Picochip’s results are impressive as well (see www.insidedsp.com/Articles/ tabid/64/articleType/ArticleView/articleId/228/Default.aspx for a recent benchmark). But that’s not SMP and is a completely different discussion. Jack G. Ganssle (jack@ganssle.com) is a lecturer and consultant on embedded development issues. MARCH 2008 | embedded systems design europe | www.embedded.com/europe 036-037-038_ESDE.indd 38 5/03/08 17:31:35 http://www.embedded.com/design/205203908 http://www.embedded.com/design/205203908 http://www.insidedsp.com/Articles/tabid/64/articleType/ArticleView/ararticleId/228/Default.aspx http://www.insidedsp.com/Articles/tabid/64/articleType/ArticleView/ararticleId/228/Default.aspx http://www.insidedsp.com/Articles/tabid/64/articleType/ArticleView/ararticleId/228/Default.aspx http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - March 2008

Embedded Systems Design Europe - March 2008 Distributors to Increase Embedded Focus Kontron and Quanta to Join Forces Coverity Raises $22m as European Business Booms Help is at Hand for Europe's Industrial Control Developers Milestones in Embedded Systems Microsoft is Recruiting for Embedded Center in Aachen European Designers to Win Cash for Green Designs Duo Work on Smaller Form Factor Europe Invests in Real-Time Java for Multicore Systems Curtiss-Wright Buys Pentland Systems Designing DSP-Based Motor Control Using Fuzzy Logic Lower the Cost of Intelligent Power Control with FPGAs Virtualizing Embedded Linux Back to the Future: Manchester Encoding Is Multicore Hype or Reality New Products Advertising Contacts

Embedded Systems Design Europe - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.