Optimizing Performance and Power in Windows Embedded Compact 7

Optimizing Performance and Power in Windows Embedded Compact 7

Douglas Boling

Boling Consulting Inc.

About Douglas Boling

• Independent consultant specializing in Windows Mobile and Windows Embedded Compact (Windows CE)

– On-Site Instruction

– Consulting and Development

• Author

– Programming Embedded Windows CE

• Fourth Edition

Agenda

• Concepts

• Performance strategies

• Power strategies

Fundamentals

• Embedded hardware is slow

– It’s designed that way intentionally

• Slower hardware means

– Smaller

– Better battery life

– Cooler (temperature wise)

– Less expensive

• Software performance impacts hardware design

– Users expect a level of performance

– With slow software, hardware has to be made faster

Speed Limiters

• Devices are “bus limited”

– Performance of device limited by memory bandwidth

• Embedded CPUs fast in the core

– Computation ability fairly good

• Often, no floating point

– Except x86

– Some ARM CPUs

Bad Caching Algorithms

• Most BSPs were designed assuming single level caches

– Or relatively small L2 caches

• BSPs may flush entire L2 cache unnecessarily

– Huge impact to performance

– If smaller flush than one line, look at flushing by address

• Solution

– Go over cache routines with fine tooth comb

– Specialized cache algorithms may be necessary

– Take the time, it’s worth it!

Excessive Copying of Data

• Try to pass pointers, not data

• Use Memory Mapped Object to share buffers between apps

• Have driver work on application’s buffers

– This can be a stability/Security problem

Frequent Calls Across “Boundaries”

• Calling between applications and drivers

• Calling between managed and native code

• Solution

– Think “chunky”, not “chatty”

• Make fewer calls with larger amounts of data

Frequent Registry Access

• Read registry data once and save in memory

• Keep registry keys open if reading multiple values

• Registry not good for interprocess communication

• The RAM-based registry is much faster than the hive registry

Mounting Databases

• Database mounts are very slow

– Lots of work by the OS

• Make sure a process mounts a DB only once

– Share code within application

Data Alignment

• RISC processors hate non-aligned memory accesses

– Old ARM processor used to just throw an exception

• Not a bad idea!

• Unaligned accesses can increase bus access/cache times 4x!

• Don’t pack structures

– Key words to check for:

• “UNALIGNED”

• #pragma(pack) directive

• /Zp compiler option

Excessive Thread Switching

• Threads that switch between each other in sub 100 mS range can be problematic

• Creating multiple threads ‘just because’ isn’t a great idea

– Why is the code multithreaded?

• Know the characteristics of the CPU

– Is it multicore?

• Has your code been recompiled for WEC?

Bad Code or Data Locality

• Results in excessive Translation Lookaside Buffer (TLB) misses

• Very hard to notice without looking

– Use profiler on MIPS and SHx

– Use hardware debugger or In Circuit Emulator to track on ARM and x86

• This can have a massive impact on performance

• Consider hardware debugger to track TLB misses

– Lauterbach debugger

The Page Pool

• The Page Pool is the amount of RAM used for code pages

– Prevents the paging system from using all the RAM for code

• Two Page Pools

– Loader Pool

• Used for demand paging of code and r/o data from apps

– File Pool

• Used for demand paging of memory mapped files

• Registry and Databases use this pool as well

Page Pool Parameters

• Target Preferred size of RAM used

• Maximum Maximum RAM allowable

• Release Increment Amount freed lazily if above target

• Critical Increment Amount freed quickly if within 1 “critical increment” of maximum

• Normal Priority Priority of discard thread during normal operation

• Critical Priority Priority of discard thread during critical operation

Page Pool Default Values

Loader Pool File Pool

Target 3 Meg 1 Meg

Maximum 8 Meg 10 Meg

Release Increment 128 K 64 K

Critical Increment 64 K 64 K

Normal Priority 255 255

Critical Priority 247 251

• Override

– Config.Sys Fixup variables

– IOCTL_HAL_GET_POOL_PARAMETERS

Other Things That Are Slow

• String compares through NLS functions

– CompareString is a slow compare

• Using Mutexes instead of Critical Sections

– If intraprocess, always use Critical Sections

• Mutexes only necessary if timeout needed

– Rule: Never create an unnamed Mutex

System Level Video Performance

• The video subsystem is the slowest part of the system

• Disable Exploding Window animation

• Consider skinning the shell to reduce complexity– Avoid the ‘3D’ look, its slow

– This is what the Windows Phone does

; Disable shell rectangle animation

[HKEY_LOCAL_MACHINE\SYSTEM\GWE]

"Animate"=dword:0

Silverlight For Embedded Performance

• Silverlight demands high performance GPUs

• If only slow GPU available

– Silverlight still useful

• Great for creating unique look and feel

– Avoid

• Alphablends

• Multiple transitions

• Gradients

• Solution

– Have U/I designer test on real hardware

• They’ll soon learn what they can do and what they can’t

Power Management

• Power Management is important

– Even on line-powered machines

• Power Consumption == Heat

– Thermal design

– Fans!

Power Manager

• Provides various levels of operation based on power consumption

– On

– Idle

– Screen Off

– Etc…

• Power Manager sets each driver to a power level depending on system level

– Configurable via registry

• Levels change programmatically or via input

Programming for Lower Power

• Thread Management

– Block, always…

– Sleeps burn power

• Hardware management

– Analyze line drivers (serial, USB)

• Turn off when not needed.

– GPIOs

• Review GPIOs to ensure most efficient use

– Clocks

• Turn off the clocks to components not in use

Summary

• Performance and Power are closely related

– Well designed code will be efficient

• Performance must be designed in

– It can RARELY be engineered in later

• Power leaks from everywhere

– It takes an experienced engineer to track down the leaks

– Knowledge of the hardware is critical

• TEST ON TARGET HARDWARE

Questions…

Doug Boling

Boling Consulting Inc.

www.bolingconsulting.com

dboling @ bolingconsulting.com

© 2011 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

© 2011 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.