The next-gen MacBook Pro with Retina Display Review
by Anand Lal Shimpi on June 23, 2012 4:14 AM EST- Posted in
- Mac
- Apple
- MacBook Pro
- Laptops
- Notebooks
Battery Life
For much of the past year I haven’t been pleased with just how good Apple’s caching has become both on OS X and iOS. Aggressively caching our test web pages produces artificially inflated battery life numbers and that’s no fun for anyone. I’m happy to say that I’ve fixed that problem with our OS X battery life tests.
The suite is completely redone although conceptually it’s quite similar to what I’ve run in the past. I have three separate workloads: light, medium and heavy, each one representing a different stress level on the machine and all three giving you a decent idea of the dynamic range of battery life you can expect from one of these notebooks. All three tests are run with the displays set to 100 nits (a little above the halfway brightness point on most MacBook Pros).
The light and medium suites are inherently related - they use the same workload and simply vary the aggressiveness of that workload. The light test hits four different websites every minute, pausing for nearly the entire time to simulate reading time. Flash is enabled and present on three of the sites. The long pause time between page loads is what really makes this a light test. Web browsing may be the medium for the test but if all you’re doing is typing, watching Twitter update and maybe lazily doing some other content consumption this is a good representation of the battery life you’ll see. It’s a great way of estimating battery life if you’re going to be using your notebook as a glorified typewriter (likely a conservative estimate for that usage model).
The medium test hits the same webpages (Flash and all) but far more aggressively. Here there’s less than 10 seconds of reading time before going onto the next page. It sounds like a small change but the impact on battery life is tremendous.
Both the light and medium tests are run in their default state with processor graphics enabled, as well as with the discrete GPU forced on. I run with the dGPU on as well because it’s far too often that a single application open in the background will fire up the dGPU and contribute to draining your battery. The goal here is to deliver useful numbers after all.
The final test is very similar to our old heavy multitasking battery life tests, but with some updates. Here I’m downloading large files at a constant 1MB/s from a dedicated server, while playing back a looped 1080p H.264 movie (the Skyfall trailer) all while running the medium battery life test. The end result is a workload that gives you a good idea of what a heavy multitasking usage model will do in terms of battery life. I’ve found that OS X tends to fire up the dGPU anyway while running this workload so I saw no reason to run a separate set of numbers for processor and discrete graphics.
Overall the rMBP pretty much behaves as expected. Apple claims up to 7 hours of battery life and using our light workload we see a bit over that. Fire up the dGPU and even a light workload will get cut down to around 5.5 hours. Moderate usage will drop battery life to around 5 hours, and if you fire up the dGPU you’ll see that cut down to 3.5. The heavy multitaskers in the audience will see a bit above 2 hours out of a single charge. Note that all of these numbers are at 100 nits, drive the 2880 x 1800 panel at its full brightness and you can expect a tangible reduction in battery life.
The rMBP’s integrated 95Wh battery is ginormous by today’s standards, but it’s really necessary to drive both the silicon and that impressive panel. Subjectively I did find the rMBP lasted longer than last year’s MacBook Pro, despite the similar max battery life ratings. My experiences were echoed by the results in our tests.
I suspect most users will see around 5 hours of battery life out of the system compared to a bit under 4 hours out of last year’s machine. At minimum brightness, typing a long document (similar to what I’m doing right now) you can significantly exceed Apple’s 7 hour estimate. As always it really depends on usage model. Professional users doing a lot of photo and video editing aren’t going to see anywhere near the max battery life, while the writers and general users will be quite happy.
One trick to maximizing battery life on light or moderate workloads is to keep an eye on what the discrete GPU is doing. I still find that OS X will wake up the discrete GPU far too frequently, even when in my opinion its services aren’t needed. As always I turn to Cody Krieger’s excellent gfxCardStatus app for keeping an eye on which GPU is driving the panel. The app has been updated and is now fully compatible with the rMBP.
Facebook
Twitter
RSS
471 Comments
View All Comments
Manni01 - Tuesday, July 17, 2012 - link
Great review as usual, but I would really like to know how Anand was able to check if Speedstep and Turboboost worked. In the last Macbook review (2011), he used MSR Tools, but I could not get these to work on Lion on my June 2012 MBP 13. He remains very vague about how, although he does confirm this works as expected on the MBP 15r .This isn't my experience. I tried using Intel's MacCPUID in Lion, and a few other tools, and it looks like the CPU is locked at nominal speed (2.9GHz in my case), so neither speedstep nor Turboboost seem to work in Lion. They work as intended in Win7/Bootcamp, going down to 1GHz to save battery or up to 3.6GHz when only one core needs more power.
So here are my questions:
1) Anand please could you tell us which tools you have used?
2) Has anyone tested this on the new macs (June 2012), using which tools, and what is the result?
Speedstep definitely worked in Snow Leopard on my MBP 13 2011, so it must be a limitation in Lion.
kenancagri - Thursday, July 19, 2012 - link
It is very good article. I loved it. Thanks for Lal Shimpi.williamsj - Friday, July 27, 2012 - link
Even the iPhone 4 is physically easier to maintain/upgrade than this thing.Check http://www.ifixit.com
The worst maintainable piece of hardware they have ever looked at!!
John
Throckmorton - Tuesday, August 7, 2012 - link
You didn't address whether pixel doubling is supported for games. IE rendering each pixel as 4 screen pixels. That's very different from upscaling, because with pixel doubling there's no blurring.Dubious1968 - Thursday, August 9, 2012 - link
I've given up waiting for Apple to refresh the iMac, and am thinking of buying the Macbook Pro Retina instead. My only concern is that Apple should have equipped this laptop with a more powerful graphics card, given it is driving such a high res screen.I will be using it for Photoshop and HD video editing along with some gaming.
Any help appreciated.
Dubious
sleddoggin - Saturday, August 11, 2012 - link
So, I've done my best to read (skim) through all 46 pages of comments for this post, and have been reading other threads on more-or-less the same topic, so forgive me if I've missed something.I own a base model rMBP w/ 16mb ram (for safety), and am really quite unimpressed by openGL performance in games that were fluid (30-60fps ANYway) on my old Mac Pro 2006 w/ an ATI Radeon 5770 HD graphics card (I guess it helps, too, that the Mac Pro GPU is sitting in an x16 PCIe lane, not an x8, as with the rMBP). The Mountain Lion upgrade has been some improvement.
When I first read Anandtech's article, I sort of thought, why not shut the lid on my MacBook Pro Retina, and plug in my old Apple Cinema display when I want to play games (I plan on using my desktop display when I'm at home for most stuff anyway). Then, the discreet NVIDIA GeForce GT 650M wouldn't be overworked by having to render all those extra pixels, right? Wrong. Gauging from the tests I've done, anyway, I'm getting the same choked performance on my relatively low-res external display (with the rMBP lid shut) as I do when I play those games on the rMBP screen (either at native OR scaled resolutions).
So my question becomes, isn't this a software issue? Shouldn't the Apple/NVIDIA engineers be able to re-route ALL of that sexy mobile GPU processing power to a single, lower-res external display, and save us gamers the hassle of trading in our rMBPs for regular 2012 MBPs?
This computer upgrade is really a no-brainer for me, otherwise. With the Thunderbolt ports, and the built in HDMI, I've been easily able to retire my old Mac Pro, and still keep my various displays (HDTV, etc.), and extensive array of USB/Firewire accessories fully operational. It just blows my mind that I get better gaming performance from my creaky old 2006 Mac Pro.
Thanks for reading my contribution to this thread. Does my thought hold ANY water? I sure as heck don't want to give up this beautiful-looking piece of hardware if I don't have to...
Cheers,
-SledDoggin' (another reluctant Apple fanboy)
vml_ - Saturday, August 25, 2012 - link
Here's what I don't get and haven't seen answered anywhere. If there are performance issues at 1800p, can they be alleviated by downscaling (eg to 1080p)?S J - Friday, August 31, 2012 - link
That sounds like great. good effort. Also have seen nice article on http://techinlead.com/apple-introducing-macbook-pr...LookupOEM - Saturday, September 22, 2012 - link
maybe i'm wrong, but i always thought that OEM means "Original Equipment Manufacturer", a company that makes equipement that is sold by others under their own name.Toshiba making hard drives for Apple makes it an OEM, just as Intel, Samsung and others
but, Apple IS NOT AN OEM, and there is no such thing as a PC OEM !!
a PC OEM would be a company that supplies parts to build a PC, not the PC maker itself.
did i miss something here ?
Penzi - Thursday, October 4, 2012 - link
Now that Mountain Lion has been out for a bit and several programs have been "retinized" are you planning on updating your review or crafting a mini-review that addresses changes, improvements and new caveats? I, for one, would love to hear about scrolling performance and resolution impact to common software (the OS and iWorks, FinalCut, etc), such as setting the display to "more space" (1920) and clocking the Safari FB news feed, and so on...