Original Link: http://www.anandtech.com/show/8327/browser-faceoff-battery-life-explored-2014
Browser Face-Off: Battery Life Explored 2014by Stephen Barrett on August 12, 2014 6:00 AM EST
It has been five years since we did a benchmark of web browsers effect on battery life and a lot has changed. Back then, our testing included Opera 9 & 10, Chrome 2, Firefox 3.5.2, Safari 4, and IE8. Just looking at those version numbers is nostalgic. Not only have the browsers gone through many revisions since then, but computer hardware and the Windows operating system are very different as well.
Windows Timers: Computer Architecture & Google Chrome
Before we get to any testing of battery life, we need to provide some background information on some of the changes, which requires a deeper understanding of how operating systems and hardware interface with each other. If you've browsed tech news recently, there has been coverage of a Google Chrome design decision from 2010. To recap, Google Chrome on Windows requests the operating system use a 1ms timer in an effort to increase web page rendering speed. Faster is better, but there is a problem with this technique.
For those unfamiliar with OS timers, they form a core component of any operating system. There are two fundamentally different ways to handle timing in a computer system, polling and interrupt modes. A polling system consists of software and hardware that continuously checks to see if something of interest has happened. For example, if a driver sets up a hardware device (i.e. a sound card) to acquire input and then continuously reads memory to check for new values, this is a polling system. However, if the driver sets up the device to acquire and then waits for interrupts (hardware notifications) that new data is available in memory, this is an interrupt system.
In general, interrupt mode is preferred as it saves significant resources and allows other threads to work while the corresponding thread sleeps. The vast majority of API calls a software developer has available do not even provide timing mode selection and simply use interrupt mode. Otherwise, a single application using polling could easily eat up an entire CPU core. There are other factors as well, like preemption, but they are out of scope of this article.
There's a problem with interrupt mode, however: it is slower for a variety of reasons. First, there is interrupt latency. Compared to polling mode checking for something to happen over and over, interrupts are always going to lose.
As an example, if I watch someone building a piece of furniture the entire time, I know exactly when they finish and I can use the furniture. On the other hand, if I wait for the builder to tell me, I could do other things in the meantime (work, sleep, play games, etc.). Of course I wouldn't know exactly when the furniture is ready and there would be a delay between when the furniture is complete and when I first begin using it.
General purpose operating systems like Windows are not typically concerned with interrupt latency. This is more important in embedded mechanical controls like those in your car. But there's another reason interrupts are slower than polling: timer coalescing.
To save power, Microsoft uses timer coalescing in Windows. Applications and drivers waiting for an event can specify their timeout in milliseconds, but in most cases the request time will be rounded to a multiple of Window's 15.6ms default timebase (prior to Windows 8, more on that later). For example, if I wrote some code that waits for an event for 200 milliseconds, Windows might actually sleep my thread for 202.8ms. When two threads request timers, this technique helps Windows continue to wake up at roughly 64 times per second instead of twice as much, 128 times per second.
The results of timer coalescing is that a web browser or other application could theoretically wait up to 15.6ms even when it requests to be scheduled in 1ms interrupts. When push comes to shove, some applications bypass the regular timer mechanism and ask Windows to use a 1ms timer, circumventing these delays. This handicaps CPU and OS power saving features because the longest the hardware and operating system can ever sleep is 1ms. Factoring in thread work time and wake time, sleep duration is likely much less than 1ms.
The power penalty of applications requesting a 1ms timer is exacerbated in Windows 8. In Windows 8, Microsoft maintains the same timer coalescing and timer request API calls, but they have implemented a tick-less kernel under the hood. With a tick-less kernel, the operating system doesn’t just try to round sleep times to a 'default timer resolution' of 15.6ms like Windows 7 and prior did, but instead at every wake event, Windows 8 analyzes the upcoming timed events and intelligently schedules its next wake up time. Therefore, sleep times could be either shorter or much longer than the previous default of 15.6ms. Depending on the distribution of wake up times, this could save significant power. Microsoft provided a blog post with some detail and data regarding the move.
Microsoft did not provide detail on what applications were running when they performed this test. However, we can tell from the data that Chrome was not running, otherwise the only values in the distribution would be at 1ms and below. And that's the crux of the problem.
When Intel launched Haswell one of the focus points was idle power consumption. The theory is when you’re staring at a static screen reading an article or the device is ‘locked’, you can save significant battery life. Consider the following charts of power use for a desktop system:
The idle power of even a desktop Haswell is significantly better than Ivy Bridge
But the load power is the same or worse
Intel spent many years designing Haswell as an improvement over Ivy Bridge for power consumption, but they are at the mercy of application developers. If an application wakes the device up for work every 1ms, the idle power benefits of Haswell don’t have nearly the impact they could.
The developers of Chrome are not ignorant to this and optimized Chrome to turn off its 1ms timer request if the system is running on battery power. However, this optimization is not functional and Chrome unfortunately always requests a 1ms timer. Other developers have criticized this timer technique in Chrome, pointing out that other browsers and high performance applications do not follow this same design pattern and that relying on precise interrupts from a general purpose OS is fundamentally a flawed design. They have likened it to old video games that changed speed with the MHz of the CPU.
By way of comparison, IE and Firefox use a frame rate limiting technique, where they use the default timer resolution of 15.6ms but if a website requests a 1ms refresh rate, they check the system clock after waking up and compute how many iterations to perform to achieve a virtual 1ms update rate. For example, if the browser wakes up after 13ms, then perform 13 iterations before sleeping again. The result is that they do more work less often.
Overall, many factors go into web browser battery usage, like GPU accelerated rendering and content caching. Chrome, despite its aggressive timer usage, may still be more battery efficient than other browsers. I should note that AnandTech has historically used Safari on OS X and desktop IE on Windows devices when performing battery life testing.
With this article we are debuting a new browser benchmark tool. Developed in house, this tool automates the usage of a desired web browser as if a user was sitting at the computer. It performs common tasks like launching and closing the browser, opening and closing tabs, loading websites, and scrolling through longer articles. As usual, the websites visited are popular sites cached on the AnandTech server, so the content of the sites does not change between runs. Additionally, the browsers are all run in private browsing mode to prevent local content caching from interfering with reloading our limited set of server-cached sites.
- IE11 Desktop Mode v11.0.9600.17207 (Update versions: 11.0.10 KB2962872)
- IE11 Modern (Metro) Mode
- Firefox 31.0
- Safari 5.1.7
- Chrome 36.0.1985.125 m
- Chrome 37.0.2062.68 beta-m (64-bit)
There are several other browsers we would have liked to test, however, due to the time intensive nature of battery life testing, we chose to focus on the most popular browsers. We also chose to test the beta version of Chrome as it is a significant update. Chrome 37 changes from 32-bit to 64-bit and from GDI (legacy) rendering to DirectWrite (modern) rendering. This makes the browser actually usable and no longer blurry on HiDPI displays.
To take advantage of operating system and hardware advances since our last test, testing was performed on the high end model of the Dell XPS 15 (9530) late 2013 edition running Windows 8.1 with all updates as of this writing.
|Dell XPS 15 (9530) Late 2013 Specifications|
Intel Core i7-4702MQ
(Quad-core 2.2-3.2GHz, 6MB L3, 22nm, 37W)
GeForce GT 750M 2GB GDDR5
(384 cores, 967MHz + Boost 2.0, 5GHz GDDR5)
Intel HD Graphics 4600
(20 EUs at 400-1150MHz)
15.6" Glossy PPS 16:9 QHD+ (3200x1800)
(Sharp LQ156Z1 Touchscreen)
|Storage||512GB mSATA SSD (Samsung SM841)|
802.11ac WiFi (Intel Dual-Band AC-7260)
(2x2:2 867Mbps capable)
Bluetooth 4.0 (Intel)
9-cell, 11.1V, 8000mAh, 91Wh
130W Max AC Adapter
Battery Charge Indicator LEDs
2 x USB 3.0
1 x Mini-DisplayPort
1 x HDMI
AC Power Connection
Flash Reader (MMC/SD)
1 x USB 3.0
1 x USB 3.0 (Sleep Charging)
|Back Side||Exhaust vent (inside LCD hinge)|
|Operating System||Windows 8.1 64-bit|
14.6" x 10.0" x 0.3-0.7" (WxDxH)
(372mm x 254mm x 8-18mm)
|Weight||4.44 lbs (2.01kg)|
720p HD Webcam
87-Key Backlit Keyboard
The latest edition of this laptop upgrades to the "Haswell Refresh" i7-4712HQ with an extra 100 MHz clock rate compared to our test laptop. That should have little to no impact on the browser battery life testing.
Results and Analysis
There is a lot to talk about with these results. While Google Chrome's 1ms timer request certainly uses more power than otherwise, everything else about Google Chrome seems to make up the difference -- at least for Chrome 36. Unfortunately, Chrome 37 takes a dive of almost 25% placing it roughly tied for last place with Firefox. Considering Chrome 36 and Safari are the only browsers on our list that do not support HiDPI displays, that could be the difference. I have added an asterisk on the chart to indicate Chrome 36 is not quite doing the same work as the other browsers. There seems to be a significant battery penalty when natively rendering at 3200x1800 instead of 1600x900 and then scaling up via Windows.
It would be interesting to repeat this test on a lower resolution display, but that would be largely academic, as many laptops today ship with HiDPI displays and more are always on the way. To be honest, I'm not sure anyone could actually use Chrome 36 on a HiDPI display without going crazy anyway, so the fact that Chrome 36 leads the pack here is probably irrelevant.
Update: Chrome has been tested at 1600x900
Just to confirm, I did run a powercfg /energy report and Google Chrome was indeed requesting the high resolution timer.
A few of our test websites also contain flash advertisements, so I was curious if these also caused Firefox and IE11 to increase their timers. Running the same powercfg /energy report did not show any timer increase for those browsers.
As for Safari, unfortunately the browser was having all kinds of trouble being automated by our test suite. The browser window would lose focus every ten seconds and result in lost keyboard inputs. Looking into task manager, whenever Safari would lose focus "Windows Error Reporting" would appear in the processes list. After disabling the Windows Error Reporting Service, Safari instead threw unhandled exceptions every 10 seconds.
Apple's website does not list any known issues regarding this error. Disabling display scaling, running at 1600x900 resolution, and reinstalling Safari did not resolve the issue. Considering Safari for Windows is still on version 5.1.7 from over two years ago and apparently won't be receiving any further updates, we decided it was best to simply exclude the browser from any further testing.
A lot of technology has changed in five years, and not surprisingly, so have our browser battery life results. Nearly everyone is used to changing their display brightness to conserve battery, but changing browsers might be a wise move as well. Most interestingly, changing to Google Chrome 36, despite its known power consumption bug, is apparently a wise move as far as battery life is concerned. However, that may be short lived, as Google Chrome 37 beta moved Chrome from first place to last place in our battery life results. The drop is possibly thanks to Google finally supporting HiDPI displays. Update: Chrome has been tested at 1600x900
It's interesting to note that Google's bug report thread shows they attempted to fix the timer issue in Chrome 37, but they had to revert the fix due to some failing automated tests. As of this writing, they have not yet re-implemented the fix, but they did try to add some power monitoring auto tests to their suite to keep an eye on this topic. Unfortunately, a few days later, they removed those new automated tests due to other unforeseen issues.
In terms of current standings, Microsoft still knows a thing or two about creating a power friendly browser, and the Modern UI version came in second place next to Chrome 36 on our tests. Looking forward, if Google could resolve their timer issue in a future revision (37 or later), they could potentially pass Firefox and maybe even IE. In the future, we hope to test this more often than every five years so we can keep up with browser changes, and possibly test on OS X as well.
Of course, battery life isn't the only factor to consider when choosing a browser. Personally I prefer Firefox due to the "awesome bar" that works better, in my opinion, than other web browser's address bar. Additionally, I can't reasonably use Safari or Chrome 36 on the XPS 15 because they do not properly support HiDPI rendering like IE and Firefox do- at least until Chrome 37.
Hopefully this article keeps the pressure on software authors to use power efficient APIs and autotest for power draw with each subsequent release. You can check for software that abuses the battery yourself with the command line tool powercfg /energy. I've found one other piece of software abusing high resolution timers, and I reported it to the author. Let us know in the comments if there are other applications you've encountered that don't play well with battery power.