Developer’s Guide to Intel® Atom™ Processor, Part 4

By Nancy Nicolaisen

For many solution architects, the decision to pursue a Mobile Internet Device (MID)–based product or service is based on a strategic analysis of how to deploy to an ultra-mobile, connected audience as rapidly as possible. Effectively, the platform question comes down to this: smartphone or MID?

Clearly, the global smartphone population has impressive adoption numbers on its side; but these devices have two huge drawbacks as solution implementation platforms: Fragmentation of virtually every sort; and very high development, testing and deployment costs. Intel® Atom™ processor MIDs overcome both of these formidable obstacles, given a savvy approach to reuse of legacy codebases. The key to getting the fastest deployment of repurposed applications and components is understanding how debugging, stress testing and tuning tools can speed optimization and provide a significant “time to market” advantage for mobilizing content, entertainment, social networking and business process applications.

Fundamental Principles for Intel® Atom™ Processor Optimization Project Architects

Fundamentally, optimizing a candidate app or item of content downward from the desktop or laptop to a small screen, battery-powered device involves these three steps:

  • Identify functional and architectural similarities. These are likely to be most numerous in the original application's data model and business logic. Optimize these first, with minimal UI skinning and streamlined feature sets. To the extent practical, trim floating point math, polling behavior, and redesign timer based behaviors to use events rather than clocking. Key IDE Support and Productivity tools: To enable quick development, set your compiler to verbose warning levels with optimizations disabled; use interactive debuggers; employ dynamic stress testing facilities.
  • Find functional and architectural dissimilarities: These are likely to be UI features and network connection handling logic. Make a quick pass decision on what is worth keeping and what simply needs to be redesigned and reimplemented. Willingness to decisively walk away from existing assets which are not appropriate either to the size or power management requirements of a small battery powered device is key to rapidly and successfully moving an optimization project forward, and most especially to the ultimate quality of the user experience. Key Resources: Microsoft* Mobile PC User Experience Guidelines.
  • Address key mobility issues at earliest phase of optimization: By their very nature, small devices are a 100% resource constrained environment and 100% flexible status environment. Power availability, network connections, network connection types, and presence & absence of peripherals are completely fluid and dynamic. Few desktop/laptop applications are designed to gracefully handle this degree or pace of operating environment change, but the best candidates will be centered on an event driven architecture. Key IDE Support and Productivity Tools: Optimizing Compilers, Tuning Metrics.

Optimizing i86 Legacy Code for Intel® Atom™: Best Practices, Tools and Techniques

Literacy and facility with automated debugging tools are key skills for optimization teams. A dominant consideration in the decision to target Intel® Atom™ processor MIDs for ultra-mobile applications is the fact that development and deployment platforms are very nearly symmetrical, providing unique technical, economic and strategic advantages to optimization projects. Perhaps the most notable and powerful i86 legacy code advantage is the ability to do all coding (and most testing and debugging) on the Windows* workstation. In terms of achieving time-to-market competitive advantage, developers targeting Intel® Atom™ processors can benefit from professional tools which are effective code quality influencers: debuggers, performance tuners, and stress testing engines. Here are a few things to know about the cost and schedule impact of debugging and testing practices:

  • Research shows that less than one third of all developers utilize automated debugging tools to accelerate their development cycles. Rather, most rely on embedded debugging code ( e.g. application diagnostic messages written to the screen or console window), which can itself be the source of issues. Literacy in the use of development environment debugging tools is a skill set that impacts the "bottom line" of a software project, and is worthy of mentoring and cultivation in all software engineering team members.
  • Remote debugging (typically necessary to isolate problems once code has been deployed to a device, if they can't be reproduced on the workstation) suffers from a particularly pernicious productivity killer: execution "over the wire" proceeds several orders of magnitude more slowly than on the workstation. Final testing on the target device is of course, a required step. But developers can dramatically accelerate the creation of new MID-based applications or optimization of existing code base by taking advantage of the symmetries between the Windows* desktop and MID execution environments by using fast, precise, IDE-based debugging and testing tools to validate code before deployment to mobile devices.
  • Debugging is usually thought to be an "after-the-fact" task, but preemptive coding conventions and techniques can unmask software defects early in a project's lifecycle, or make them more easily and cheaply detected further downstream. Again, these are "bottom line" considerations, because the cost to detect, isolate and correct a bug increases by an order of magnitude at each step of the project's lifecycle.
Preemptive Debugging Strategies
Compiled code typically has superior optimization potential for small devices. Because to a large degree, it is susceptible to the direct control of an application, power management is a central consideration in the design of any MID based solution. For this reason, battery powered platforms favor highly optimized, compiled solutions. Given this, it is fair to say that there will be at least some C/C++ bias in the legacy applications initially chosen as Intel® Atom™ microarchitecture optimization candidates. (Intel provides its own optimizing C++ compiler as an add-on product for Microsoft's Visual Studio Development* environment.) Establishing best practices and coding conventions that account for this when optimizing code from desktop/laptop heritage to perform well on Intel® Atom™ microarchitecture devices:
  • Use inline debugging code in a systematic, deliberate fashion, and take advantage of its presence to document areas of potential vulnerabilities for future maintainers. Even the best desktop debugger may not be able to provide complete visibility into the behavior of an Intel® Atom™ processor app, particularly if it makes use of unusual or custom USB peripherals. When debugging on the desktop, be defensive around of passages of code that could prove to be problematic because of differences in the development and deployment environments. (Think power awareness, hardware awareness and network connection awareness. ) Use preprocessor flags (#define / #undef and #ifdef / #endif to conditionally compile in debug sources during development. This technique provides two advantages. First, it prevents repeated insertion and deletion of debug code, because it is possible to turn off a particular set of debug statements simply by "undefining" them when they are not needed. Second, it gives future code maintainers some information about what the application's original architects thought might prove troublesome.
  • Be alert to the common causes of software defects in C/C++ code bases, and proactively work to find defects during development and early pass optimizations. Pick a routine but convenient time to regularly compile code with the most rigorous error reporting and type checking level set. This allows the compiler to spot oversights and coding mistakes that are some of the most common causes of software defects: Uninitialized variables, mismatched types, problems with function signatures and the like.
  • Use exception handling to account for the vulnerabilities inherent in the key, characteristic features of mobile devices. Users don't distinguish between applications that malfunction because of "bugs" and applications that fail to follow normal execution paths because of exceptional conditions, so graceful degradation strategies are a "must do". Exceptional conditions are far more likely to occur on battery powered mobile devices, because they inherently pose resource constrained execution environments in just about every respect. MID C++ coding and design styles should employ structured exception handling to account for three classes of exceptional conditions that seldom play a role in applications running on wall current:
    • Power Awareness: Applications should detect whether a device is using wall current or battery power, and adapt to changes in state relating to the power source. Potential exceptional conditions arising from power management considerations include things like operations which should be interrupted or suspended (think lengthy floating point math calculations, polling loops, complex graphical rendering, and the like), graceful shutdown when device batteries are below a given threshold, and ability to "sleep". Program defensively. Look ahead at tasks users are about to launch (for example, playing a movie). Determine in advance if there's enough battery life to complete the task, and warn the user at the start of the task if it might not complete successfully given the current state of battery charge.
    • Network Awareness: The inherent mobility of Intel® Atom™ processor class devices means that users expect to roam freely and treat network connection in the most casual possible way, expecting seamlessness. The battery powered nature of the devices also dictates that savvy users will intentionally drop connections at will, because full time antenna power can cut battery life by half. Therefore, applications optimized for the Intel® Atom™ processor must be prepared to handle exceptional conditions where network connections are dynamically dropped, remade, and handed off, as the user wanders. Because MIDs typically provide more than one type of connectivity (e.g. wireless, Ethernet, Bluetooth* ...), the connectivity behavior of MIDs is far more dynamic than would typically be the case for desktop- or laptop-based applications.
    • Hardware Awareness: Consumers love the convenience and "handiness" of mobile devices, but precisely because of their small form factor, users also expect to be able to "pair" them with peripherals or other computers that amplify or reinforce their utility. This creates a huge potential for exceptional hardware conditions, some of which are extraordinarily complex (think external monitors or multiple monitors). Variation in screen sizes, pixel density, screen orientation and color capabilities are all factors which an app might be called upon to detect and intermediate.
Some types of software defects won't be initially apparent or repeatable in a development environment, because the target is a resource-constrained platform. There are several potential explanations when this circumstance occurs:
  • Users don't have exactly the same files and applications on their systems as developers;
  • Transient conditions of resource exhaustion (memory, power, bandwidth, etc) occur on the smaller device, but not on the development system;
  • Peculiarities of timing and threading that result in race conditions or memory leaks produce a noticeable result on the small device but not on the development system.
The key to identifying the source of non-reproducible problems quickly-particularly if they are intermittent in nature in the small device-is stress testing. Various stress testing techniques and utilities are available as open source tools and examples (see Table 1 for a link to more information on stress testing tools for Windows* applications), but fundamentally they all operate by withdrawing resources from the system until an app either fails or handles the exceptional situation gracefully. Stress testing tools are often the only way to identify memory leaks and race conditions that occur as a result of interactions between applications. Because it is a virtual certainty that small devices like MIDs will frequently encounter circumstances of near exhaustion of power, memory, bandwidth and processor utilization, it is especially important that they undergo stress testing to assure the quality and reliability of optimized code. (Learn more about stress testing tools.)

Best-of-Breed Tools for Debugging and Optimizing Intel® Atom™ Microarchitecture Code

Without question, the best overall development environment for Windows-targeting MID developers comes from the people who bring us Windows* Microsoft's* Visual Studio* 9.0 is available for 90 day free trial (Download here.) and gives developers an opportunity to experiment with its integrated debugging facilities and support before committing to purchase. Microsoft's visual and intuitive debugging interface allows developers to watch memory regions; set breakpoints on execution, memory access and events; dynamically view stack and register contents; step code execution; and attach processes. (See the University of Washington Computer Science and Engineering program's MSVC debugger tutorial here.)

On the workstation, debug applications run at near native device speeds in between breakpoints, which means that early stage work on code being optimized for Intel® Atom™ devices can proceed very rapidly. When it is time to validate applications on target devices, MS Visual Studio provides essentially the same support for remote debugging, where applications are running under either Windows XP* or Windows Vista* on the MID side. Basically this is accomplished either by installing a remote debugging monitor (provided with Visual Studio 9.0) on the MID side, or by running the remote debugging monitor out of a file share on the workstation side. (Instructions for remote debugger setup.)

For those who choose to adopt Visual Studio but want more control over optimized code generation, Intel® provides two additional plug in tools specifically for enhancing code targeting Intel® processors: The Intel® C++ Compiler and VTune™ Performance Analyzer. (Download links for the Intel® tools.) Here's a key thing to note about the optimizing Intel® C++ Compiler, and for that matter, the Microsoft compilers, as well: Until very near the end of the development cycle, you won't want to use compiler optimizations. By their very nature, the compiler's optimization passes modify and rearrange generated code, with the aim of producing various types of efficiencies: size, speed, power management, and the like. This means that, should it be necessary for you to examine instructions generated by the compiler, in some cases there would be little if any correspondence between the source and the resulting assembly code. While actively debugging, disable all compiler optimizations.

It may be prolix to point out that nobody knows the Intel® execution environment like ...Intel. With a history of continual refinement and evolution spanning more than a decade, the Intel® optimizing compilers are capable of producing highly tuned, robust, stable executables. Most recently, Intel has devoted considerable effort to adding support for Intel® Atom™ processor-specific optimizations. To learn more about these capabilities, check here for Intel's account of the compiler technologies and their advantages. (The same optimizations may be used to improve the performance and footprint of Windows*-targeting code.)

The VTune™ optimization facility is a tool for quantifying which applications-and which parts of applications-may rapidly and successfully be optimized for a small device. VTune™ provides fast, definitive performance metrics for code running on a small device, highlighting inefficiencies that could cost battery life or have the potential to create instability in a limited operating environment, and is very useful for analyzing performance of threaded applications in particular.

Table 1. Development Tools and Resources for Debugging and Tuning Intel® Atom™-Targeting Applications

Tools and Resources URL
Microsoft* Visual Studio* (90-day free trial) http://msdn.microsoft.com/en-us/evalcenter/bb655861.aspx
Intel® Optimizing Compiler Suite Professional Edition for Windows* - Evaluation (30-day free trial) http://www.intel.com/cd/software/products/asmo-na/eng/388198.htm
Intel® VTune™ Performance Analyzer (30-day free trial) /en-us/articles/intel-vtune-amplifier-xe/
MSDN* Developer Network: How to: Set Up Remote Debugging http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
"Stress Testing" by James McCaffrey http://msdn.microsoft.com/en-us/magazine/cc163613.aspx
Microsoft "Mobile PC User Experience Guidelines" http://msdn.microsoft.com/en-us/library/ms695565(VS.85).aspx

Table 2. Further Reading For Intel® ™Atom Microarchitecture Developers

Tool URL
"Using VTune™ Performance Analyzer for Intel® Atom™ Processor on Windows* XP" /en-us/articles/using-vtune-atom-windows
"Using the VTune™ Performance Analyzer Sampling Collector for Mobile Internet Devices" /en-us/articles/sampling-collector-mid


Summary

In a year where good news has been in short supply, Intel® Atom™ and its collateral technologies-MIDs, Net Books, low power home file servers-are all great news for developers. Intel® Atom™ processor-powered platforms represent one of those rare, but exciting technology occurrences, where completely new markets open and new types of solutions become possible. And while the devices which Intel® Atom™ underlies may, in fact be revolutionary and disruptive, the path to the Intel® Atom™ processor-powered platform is incremental and evolutionary for Windows* software developers, particularly those with very early PC experience or embedded systems background. Intel® Atom™ is green-its manufacturing process is clean; its recycling impacts are negligible; and it uses less energy than any IC of its kind. And Intel® Atom™ is also black. While virtually every other technology niche is enduring the slings and arrows of a poor economy, analysts uniformly predict growth in the MID/UMPC/NetBook niche this year, with considerable growth in 2010 and beyond.

Link to other parts of this series:

Part 1: A New Class of Internet Devices
Part 2: Choosing Porting Candidates
Part 3: Choosing Optimization Candidates


About the Author

Nancy Nicolaisen is an author, researcher and veteran software developer specializing in mobile and embedded device technologies. Her feature articles, columns and analyses have been internationally circulated in publications including BYTE, PC Magazine, Windows Sources, Computer Shopper, Dr. Dobbs Journal of Software Engineering, Microsoft Systems Journal; She is author of three books: Making Windows Portable: Porting Win32 to Win CE (2002, John Wiley & Sons); The Practical Guide to Debugging 32 Bit Windows Applications (1996, McGraw Hill); and The Visual Guide to Visual C++ (1994, Ventana Press) available in five foreign language editions. In 2007 she served as technical advisor for the development of the Microsoft Professional Education course titled "Designing, Building and Managing Wireless Networks". Ms. Nicolaisen is currently active in exploring open source technologies and trends for mobile, embedded and wireless devices.
有关编译器优化的更完整信息,请参阅优化通知