All the Performance, and Good Battery Life As Well!

We’ve just finished showing that CPU and GPU performance has basically more than doubled compared to last year’s Arrandale offerings. That’s great news, but what happens to battery life? We’ve got 35W TDP Arrandale parts compared to a 45W TDP Sandy Bridge quad-core; doesn’t that mean battery life will decrease by around 25%? The answer is happily no; as we’ve point out in the past, TDP isn’t really a useful measurement of power requirements. All the TDP represents in this case is the maximum amount of power Sandy Bridge should draw. So worst-case battery life under full load might drop, but the real question is going to be what happens under typical workloads.

Intel’s use of power gating and variable clock speeds is put to good use, with the result being battery life that is nothing short of exceptional when compared to previous generation products. We’ve seen ULV and Atom netbooks and ultraportables get battery life into the 8+ hour range, but such designs have always required serious compromise in the performance department. SNB certainly won’t beat out Atom for pure battery life, but that doesn’t mean it’s a power hog. Our Compal test system comes with a 71Wh battery, which is larger than what we’ve seen in many 15.6” and smaller designs but still reasonable for a 17.3” chassis. Here are the results of our standard battery life testing.

Battery Life - Idle

Battery Life - Internet

Battery Life - H.264 Playback

Relative Battery Life

Yes, those figures are accurate. Best-case, running at 100nits, quad-core Sandy Bridge still lasted nearly eight hours on a single charge! What’s more interesting is that our standard Internet battery life test that loads four pages with Flash ads every sixty seconds still checks in just shy of seven hours. Finally, H.264 playback also comes in at the top of our charts, providing more than four hours of demanding video playback. If 240 minutes of content off your HDD/SSD isn’t enough, we also were able to watch a Blu-ray disc and still get 220 minutes of 35Mbit VLC playback. Wow!

So Sandy Bridge comes out on the top of the above charts, but we didn’t include some of the other long battery life alternatives. Just to put things in perspective, ASUS’ U30JC—with an SSD and an 84Wh battery—has long been our king for matching reasonable performance with long battery life. It managed 588 minutes idle, 476 minutes Internet, and 254 minutes H.264 playback. That’s 25% more idle life, but only 14% better Internet and actually slightly lower H.264 battery life, and you need to factor in the 18% higher capacity battery and 13.3” (versus 17.3”) LCD.

We have to wonder just how small of a form factor manufacturers can manage to cram the quad-core Sandy Bridge into. Idle and low usage power requirements are clearly very good, but with maximum TDP still at 45W the chassis needs to be able to handle the heat. We’d really love to see some 14” designs with quad-core CPUs, and the icing on the cake would be sticking a reasonably fast discrete GPU with graphics switching technology into the case as well. Intel doesn’t have any LV/ULV quad-core parts listed—yet!—so we may have to wait for ultraportable quad-core laptops, but certainly 15.6” designs should be able to combine SNB with reasonably fast Optimus GPUs to provide an optimal blend of performance and mobility.

Extended Compatibility and Performance Results – Medium Detail Performance and Power Investigated
Comments Locked


View All Comments

  • tipoo - Monday, January 3, 2011 - link

    Sorry if I missed this somewhere in the review, but does the graphics component support OpenCL?
  • RyuDeshi - Monday, January 3, 2011 - link

    Second to last paragraph on the "Extended compatibility and performance results:"

    "Ultimately, Sandy Bridge’s IGP is far more capable than many would have expected. Sure, it doesn’t even try to support DX11 or OpenCL, but at least for gaming DX11 is typically too much for even midrange GPUs."
  • CharonPDX - Monday, January 3, 2011 - link

    An Intel rep has said that Sandy Bridge will support OpenCL. ( ) The trick is that it may be a combo CPU+GPU to do it. So it may not be what you are thinking by OpenCL being solely GPU, but OpenCL code should be able to run.

    And in the end, what does it matter, really, as long as it runs? As the desktop Sandy Bridge review points out, video encoding is just as fast using solely the x86 codepaths as using nVidia's CUDA or ATI's Stream.
  • Voldenuit - Monday, January 3, 2011 - link

    OpenCL was designed from the outset to run on heterogenous resources, including CPU.

    So intel claiming that they "support" OpenCL is nothing special - they just needed the right drivers/API.

    However, don't expect OpenCL code running solely on the CPU (my guess as to how SB will handle it) to be any faster than the x86 codepath running on the same CPU.

    Checkbox feature.
  • jameskatt - Monday, January 3, 2011 - link

    What Intel wants to do is to have the CPU run OpenCL code.

    This totally defeats the purpose of OpenCL.

    OpenCL is suppose to allow both the GPU and the CPU to run code simultaneously. This is to allow significant acceleration in running OpenCL code compared to using just the CPU.

    Sure. OpenCL code will run. But it will run MORE SLOWLY than with a discrete GPU. And the 16 GPUs in Sandy Bridge will be wasted.

    Intel's Sandy Bridge has non-programmable GPUs. This is a serious limitation and deal killer when it comes to running OpenCL code.

    I expect Apple to continue use nVidia's or AMD's discrete GPUs with the MacBooks and Mac Book Pros.

    This is very disappointing. It shows that Intel still doesn't have the talent to produce decent GPUs.
  • PlasmaBomb - Monday, January 3, 2011 - link

    And the 16 GPUs in Sandy Bridge will be wasted.

    *cough* I think you mean 12 EU *cough*
  • Guspaz - Monday, January 3, 2011 - link

    <i>What Intel wants to do is to have the CPU run OpenCL code.

    This totally defeats the purpose of OpenCL.

    OpenCL is suppose to allow both the GPU and the CPU to run code simultaneously. This is to allow significant acceleration in running OpenCL code compared to using just the CPU.</i>

    No, this is the *primary* purpose of OpenCL. The goal of OpenCL is not to "allow the GPU and CPU to run code simultaneously", but to provide a single unified code path that can be used with any hardware, be it CPU or GPU. There are/were already code paths specific to each vendor/type (CUDA for nVIDIA GPUs, Stream for AMD/ATI GPUs, x86 for Intel/AMD CPUs). The problem is that fully supporting all three platforms requires three separate code paths.

    OpenCL unifies this, and allows a single codepath to be used regardless of the GPU's type or existence. You've completely misunderstood the purpose of OpenCL.
  • Wiggy McShades - Tuesday, January 4, 2011 - link

    You need to ask what applications on a desktop actually use OpenCL in a meaningful way? Intel added hardware for media transcoding, which makes transcoding on something besides the cpu useless and that was roughly all openCL can be used for on the desktop, laptop, or cellphone.
    OpenCL is for vector calculations, AVX is for vector calculations. All four cores running AVX instructions would just be a faster choice than OpenCL on a low end gpu. Intel most likely could get sandybridge's gpu running OpenCL, but it would be pointless. OpenCL just is not a desktop feature.
  • strikeback03 - Wednesday, January 5, 2011 - link

    Given how much money they have, I doubt Intel is lacking the "talent" to do anything they want. OpenCL execution on the GPU portion of the SNB chips was probably just not that big a deal to them, and given the number of other things (such as speed and battery life) SNB brings to the table they probably won't have trouble selling lots of these to the average consumer.
  • 8steve8 - Monday, January 3, 2011 - link

    which mobile cpus on pg1 support TXT or VT-d or AES-NI or VT-x or Quick Sync?

Log in

Don't have an account? Sign up now