Are you leveraging multicore processors effectively?
Today's latest microprocessors, and the standard for the future, contain multiple processor cores. The number of cores available are expected to grow steadily, despite the fear of Amdahl's Law regarding a limit on speedup from parallelizing a process or the euphoria associated with Gustafson's Law, which suggests that the overall amount of work that can be done can continue to increase as the number of processor cores increases.
With this in mind, the transition to multicore processors is shifting the burden of innovation to developers who are compelled to produce software that can exploit the parallel multicore architecture. Industrial OEMs are left with the quandary as to whether they need to throw out their old product designs--around which they and their customers have made significant investments, and start fresh--or whether they should compromise on features and price by continuing to support legacy hardware platforms.
Parallelization is only part of the problem. When it comes to embedded systems, a bigger issue is segmentation of the system. The laws put forth by Amdahl, Gustafson, and others address only the raw performance metrics for a homogeneous mix of tasks. Embedded systems are typically composed of elements that have very different, hardware-related tasks to perform. Consequently, in addition to performance, real-time embedded systems developers need to consider more mundane metrics like: availability of hardware, system cost, footprint, power consumption, determinism, and development effort.
Operating-system and tools providers are rising to the challenge of supporting multicore chips, but most are viewing the multicore processors as a pool of resources that can be deployed interchangeably to perform general purpose tasks. By ignoring Amdahl and Gustafson and taking a different look at how multiple cores can be used, embedded system designers don't need to compromise or start over. An alternate approach for many embedded systems is to dedicate processor cores to specific system functions. OEMs can run their legacy code, with little or no modification, on a dedicated processor core that runs independently of those cores that support new application features.
The segmentation of tasks in many embedded systems is typically associated with multiple operating environments. General-purpose operating systems (OSes) excel at supporting database structures such as one would find in recipe management or process monitoring, whereas real-time OSes excel at responding to machine-directed inputs with minimal delay. The traditional way to serve these diverse computing needs has been to incorporate multiple separate computing environments in a system--for example a discrete imaging subsystem, a stand-alone motion-control subsystem, and a human-machine interface.
Loading comments... Write a comment