Another guest appearance this week. My colleague Faheem Sheikh is a member of the Mentor Embedded engineering team. He wanted to share his ideas about embedded software performance optimization …
‘Present’, ‘head’ and ‘court’ do not seem related at first sight. Do they? But these words have one attribute in common. They can take on multiple meanings depending upon context, expressions or interpretation, a property known as polysemy. Frequently exploited by media to create sizzling headlines or marketing folks to construct catchy product offerings, it is an important concept from linguistics. I am not sure if the higher frequency of polysemy in a language reflects on its flexibility, but here is a example-phrase live-in-action from popular culture!
On the surface there seems little room for polysemy in technical writing. Indeed engineering articles, papers and essays require precise definition of terms under usage to ensure clarity. Informal writings like email communications, social-networking-status-updates and instant messenger chats often employ jargon that can be interpreted in more ways than one. But that is understandable considering the need for brevity. So are there any technical terms/words/phrases that convey multiple meanings to a customer? In other words, is there any room for polysemy in let’s say, embedded software?
A personal favorite is ‘performance’ specially when used in conjunction with ‘optimization’. Together they make either a very useful pair (if polysemy was desired) or quite an ambiguous combination (at least in a software context).
A hypothetical example: There is a real-time pattern-matching embedded device (applications include bar-code scanner, photo-id security and surveillance systems) planning to have its next generation release. Eager to gain an edge over competitors, product marketing comes up with a customary slogan that sounds somewhat like ‘optimized performance at lowest power budget’. Top of the list new features thus include ‘upgrading processor to latest power efficient core’ and ‘performance enhancements in software.’ Of course, some performance numbers/data will be helpful to validate the claims.
In response, the project manager can define performance in terms of getting the best out of the system, while optimization might refer to methods needed for attaining nirvana. However, from an engineering perspective, improving software’s performance can throw up multiple, sometimes orthogonal options.
Typically product level embedded software is a combination of third-party libraries, in-house application development, and legacy code in addition to open source stuff. Even if all constituent components are available in source form, optimizing each one of them will require non-overlapping strategies.
For instance, optimizing libraries might involve rewriting the algorithms to take advantage of new processor features, cache and memory configurations. Improving real-time responsiveness of the system on the other hand will require eliminating overhead/latency of operating system or control software.Efficient code generation via toolchain optimization can also lead to improved performance.
The attempt to optimize multiple software components, originally built and tested for correct functionality, that too in parallel can lead to various notions of ‘performance-optimization’ to exist within the same team/project. Conversely, starting with a holistic performance-optimization view and forcing predetermined strategies on individual components might back fire as well. At which point the project manager might start thinking, software optimization?, Well, tell you what, forget about it!
An alternative scenario is where the embedded device is based on a software product which has been designed, built and tested for performance while being scalable with platforms. Such libraries usually fine tune the fundamental algorithms on a wide range of platforms while keeping OS and compiler considerations in mind. Taking that solution, it becomes a lot easier to profile the system, do some cost-benefit analysis, and if required, focus the optimization efforts on the remaining piece of logic.
Mentor Embedded’s Sourcery VSIPL++ is one such product where selecting the platform and performance-optimization simply means choosing the right version of Mentor VSIPL++. VSIPL++ will take care of all critical pieces of the back-end, leaving specific areas open for improvements. As a result the product developer can focus on a single domain for optimizations. Mentor Embedded performance library is another example where fundamental math functions are being optimized for upcoming Freescale processors.