Tips and Tricks: Designing Low Power Native and Webapps
Total Page：16
File Type：pdf, Size：1020Kb
Tips and Tricks: Designing low power Native and WebApps Harita Chilukuri and Abhishek Dhanotia Acknowledgements • William Baughman for his help with the browser analysis • Ross Burton & Thomas Wood for information on Tizen Architecture • Tom Baker, Luis “Fernando” Recalde, Raji Shunmuganathan and Yamini Nimmagadda for reviews and comments 2 tizen.org Power – Onus lies on Software too! Use system resources to provide best User WEBAPPS Experience with minimum power NATIVE APPS RUNTIME Interfaces with HW components, DRIVERS / MIDDLEWARE Independent device power management Frequency Governors, CPU Power OS Management ACPI/RTPM Provides features for low power HARDWARE Clock Gating, Power Gating, Sleep States 3 tizen.org Power – Onus lies on Software too! • A single bad application can lead to exceeding power budget • Hardware and OS provide many features for low power – Apps need to use them smartly to improve power efficiency • Good understanding of underlying system can help in designing better apps Images are properties of their respective owners 4 tizen.org Agenda Tips for Power Tools General Low Power Q&A & Metrics guidelines Applications 5 tizen.org Estimating Power - Metrics • CPU utilization • Memory bandwidth • CPU C and P state residencies • Device D states - For non-CPU components • S states – system sleep states • Wakeups, interrupts Soft metrics can help tune the application for optimal power 6 tizen.org Estimating Power - Tools • CPU utilization – Vmstat, Top – VTune, Perf for CPU cycles • Memory bandwidth – Vtune • CPU C and P states, Device D states – VTune, Powertop • Wakeups, Interrupts, Timers – Powertop, /proc stats • Tracing tool in Chrome browser ** VTune is an Intel product and can be purchased, others are publicly available Linux tools * Other names and brands may be claimed as the property of others. 7 tizen.org Tip 1: Minimize wakeups, they are expensive 8 tizen.org Tip 1: Minimize wakeups • Classic case of a single application exhausting the power budget • Wakeups from each app add up – Even if its just 0.5 wakeups/sec 160 140 120 ) 100 mW 80 60 Power ( Power 40 20 0 100wakes 80wakes 60wakes 40wakes 20wakes 10wakes 1 wakes Total system wakeups from all applications 9 tizen.org Tip 1: Minimize wakeups Polling, Frequent I/O Timers 1400 160 1200 140 120 1000 ) 100 800 mW 80 600 60 Power ( Power 400 Background Life (hrs) Battery Activity 40 200 20 0 0 168 78 40 20 17 10 8 Wakeups/sec Power Battery Life 10 tizen.org Tip 1: Minimize wakeups • How to reduce wakeups - Polling - High frequency timers - Avoid frequent I/O + Maximize the work done when the system wakes up, batch operations + Longer sleep time is better than frequent shorter sleep times Apps accessing data from peripheral components/sensors • GPS, Games using accelerometer etc. Apps doing periodic updates • Push notifications instead of polling Images are properties of their respective owners 11 tizen.org Tip 2 Use Hardware Acceleration 12 tizen.org Tip 2: Use hardware acceleration HW Overlay and Decoding in Compositing Rendering in GPU Audio Engine in GPU 120 100 80 60 CPU C0 CPU % 40 20 0 Video Playback Audio Playback HTML5 Video Webapp SW based functions HW Accelerated functions 13 tizen.org Tip 2: Use hardware acceleration Caveats • Benefits from acceleration vary based on use case • HW Acceleration improves performance only when TIME (memcpy + work in HW) < TIME (work in SW) • Power Software Hardware Acc CPU GPU Memory 14 tizen.org Tip 2: Use hardware acceleration • Common formats that are usually accelerated or optimized • Developers should use these when applicable Video Audio Browser MPEG2 MP3 GPU Accelerated Compositing MPEG4 AAC GPU Rendering H264 EGL VC1 • Media apps, local playback and streaming • Games Images are properties of their respective owners 15 tizen.org Tip 3: Don’t shoot for performance beyond what a user can perceive 16 tizen.org Tip 3: Performance Vs. Power Tradeoff • Video playback power use with different frame rates 3 2.5 ~2.5x increase from 2 30-60 fps FPS = 15 1.5 FPS = 30 FPS = 45 1 FPS = 60 0.5 0 CPU% Power * Power here is the difference between system idle and video playback, data normalized to 30 fps. 17 tizen.org Tip3: Performance Vs. Power Tradeoff – Trying to maximize performance without knowledge of user expectation + Make a tradeoff Media Apps • Videos beyond 30 fps are rarely perceivable on mobile devices • Audio bit rates beyond audio HW output capacity won’t sound better Games • Screen refresh rates are 60/120Hz, frames are dropped beyond that • 60 fps may be overkill for some applications Images are properties of their respective owners 18 tizen.org Tip 4: Minimize Latency & JavaScript 19 tizen.org & JavaScript Latency 4: Minimize Tip 20 SOC Power (Watts) 0.5 1.5 2.5 0 1 2 3 1 5 9 13 17 21 25 Average SOC power for power SOC Average 29 latency Server 33 37 41 45 latency Server 49 53 57 61 65 138ms = 69 G Google Search Google 73 oogle search is 919mW, for Ask search, its 1031mW, ~10% difference ~10% 1031mW, its search, Ask for 919mW, is search oogle 77 81 1.2s = 85 89 93 97 101 Time 105 109 113 117 Ask Search Ask 121 125 129 133 137 141 145 149 153 157 161 165 tizen.org 169 173 177 181 185 189 193 197 201 205 209 213 217 221 & JavaScript Latency 4: Minimize Tip 21 SOC Power (Watts) 0.5 1.5 2.5 0 1 2 3 1 5 9 13 17 21 25 29 33 37 41 45 49 53 domains different to requests more Issue JavaScript, 57 61 65 69 Google Search Google 73 77 81 85 89 93 97 101 Time 105 109 113 117 Ask Search Ask 121 125 129 133 137 141 145 149 153 157 161 165 tizen.org 169 173 177 181 185 189 193 197 201 205 209 213 217 221 & JavaScript Latency 4: Minimize Tip 22 SOC Power (Watts) 0.5 1.5 2.5 0 1 2 3 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 Google Search Google 76 data more Receiving 81 86 91 96 101 Time 106 111 116 121 Ask Search Ask 126 131 136 141 146 151 156 161 166 171 tizen.org 176 181 186 191 196 201 206 211 216 221 Tip 4: Minimize Latency & JavaScript + Batch requests + Cache external resources - Many sequential connections - Long latencies • Ask batches some requests, but not all. Web Applications Images are properties of their respective owners 23 tizen.org Tip 5: Minimize Comm. Power 24 tizen.org 25 WiFi Power (watts) 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 power comm. 5: Minimize Tip 0 1 12 23 for time active wider causes latencies response server in Difference 34 45 56 67 78 89 100 111 122 133 144 155 166 177 188 199 210 Time 221 232 243 254 265 276 287 298 309 320 331 342 ASK Wifi ASK 353 364 375 W tizen.org 386 ifi 397 408 419 430 Google Wifi Google 441 452 463 474 485 496 507 26 WiFi Power (watts) 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 5: Minimize Tip 0 1 12 23 34 45 56 67 78 Wide => Connection Active => Request Data 89 100 111 122 133 144 155 166 177 188 c 199 omm. power 210 Time 221 232 243 254 265 276 287 298 309 Wifi 320 331 Power Wakeups => More PowerMore => Wakeups Power 342 ASK Wifi ASK 353 364 375 tizen.org 386 397 408 419 430 Google Wifi Google 441 452 463 474 485 496 507 Tip 5: Minimize comm. power • How can you reduce Wi-Fi power consumption? + Batch processing - Long latencies Web Applications Images are properties of their respective owners 27 tizen.org Some other general guidelines for low power • Context awareness – Minimize system resource use when not in foreground • Subscribe to screen and other system events – Free up temporary cache, files, and images • Clean idle – Use resources only when user is active – Only act on user input • does piggybacking or deferring tasks to the next system wakeup work? – The power profile of an idle app should match system idle – Idle system CPU utilization target is less than 1% 28 tizen.org Summary • Battery life is an important selling factor • Keep power in mind from Day 0 of development • Follow our tips to make a good app-world citizen Enjoy Developing Green Apps ! Email us at [email protected] & [email protected] 29 tizen.org .