Sandy Bridge: Inside the Core Microarchitecture

In the modern era, we are talking about chips roughly the size of 100-200mm2 having up to eight high performance cores on the latest variants of Intel’s 14nm process or AMD’s use of GlobalFoundries / upcoming with TSMC. Back with Sandy Bridge, 32nm was a different beast. The manufacturing process was still planar without FinFETs, implementing Intel’s second generation High-K Metal Gate, and achieving 0.7x scaling compared to the larger 45nm previous. The Core i7-2600K was the largest quad core die, running at 216 mm2 and 1.16 billion transistors, which compared to the latest Coffee Lake processors on 14nm offer eight cores at ~170 mm2 and over 2 billion transistors.

The big leap of the era was in the microarchitecture. Sandy Bridge promised (and delivered) a significant uplift in raw clock-for-clock performance over the previous generation Westmere processors, and forms the base schema for Intel’s latest chips almost a decade later. A number of key innovations were first made available at retail through Sandy Bridge, which have been built upon and iterated over many times to get to the high performance we have today.

Through this page, I have largely used Anand’s initial report into the microarchitecture back in 2010 as a base, with additions based on the modern look on this processor design.

A Quick Recap: A Basic Out-of-Order CPU Core

For those new to CPU design, here’s a quick run through of how an out-of-order CPU works. Broadly speaking, a core is divided into the front end and back end, and data first comes into the front end.

In the front end, we have the prefetchers and branch predictors that will predict and pull in instructions from the main memory. The idea here is that if you can predict what data and instructions are needed next before they are needed, then you can save time by having that data close to the core when needed. The instructions are then placed into a decoder, which transforms the byte code instruction into a number of ‘micro-operations’ that the core can then use. There are different types of decoders for simple and complex instructions – simple x86 instructions map easily to one micro-op, whereas more complex instructions can decode to more – the ideal situation is a decode ratio as low as possible, although sometimes instructions can be split into more micro-ops if they can be run in parallel together (instruction level parallelism, or ILP).

If the core has a ‘micro-operation cache’, or uOp cache, then the results from each decoded instruction ends up there. The core can detect before an instruction is decoded if that particular instruction has been decoded recently, and use the result from the previous decode rather than doing a full decode which wastes power.

Now the uOps are now in an allocation queue, which for modern cores usually means that the core can detect if the instructions are part of a simple loop, or if it can fuse uOps together to make the whole thing go quicker, it can. The uOps are then fed into the re-order buffer, which forms the ‘back end’ of the core.

In the back end, starting with the re-order buffer, uOps can be rearranged depending on where the data each micro-op needs is. This buffer can rename and allocate uOps depending on where they need to go (integer vs FP), and depending on the core, it can also act as a retire station for complete instructions. After the re-order buffer, uOps are fed into the scheduler in a desired order to ensure data is ready and the uOp throughput is as high as possible.

In the scheduler, it passes the uOps into the execution ports (what does the compute) as required. Some cores have a unified scheduler between all the ports, however some split the scheduler depending on integer operations or vector style operations. Most out-of-order cores can have anywhere from 4 to 10 ports (or more), and these execution ports will do the math required on the data given the instruction passed through the core. Execution ports can take the form of a load unit (load from cache), a store unit (store into cache), an integer math unit, a floating point math unit, vector math units, special division units, and a few others for special operations. After the execution port is complete, the data can then be held for reuse in a cache, be pushed to main memory, while the instruction feeds into the retire queue, and finally retired.

This brief overview doesn’t touch on some of the mechanisms that modern cores use to help caching and data look up, such as transaction buffers, stream buffers, tagging, etc., some of which get iterative improvements every generation, but usually when we talk about ‘instructions per clock’ as a measure of performance, we aim to get as many instructions through the core (through the front end and back end) as many as possible – this relies on the decode strength of the front end, the prefetchers, the reorder buffers, and maximising the execution port use, along with retiring as many completed instructions as possible every clock cycle.

With this in mind, hopefully it will give context to some of Anand’s analysis back when Sandy Bridge was launched.

Sandy Bridge: The Front End

Sandy Bridge’s CPU architecture is evolutionary from a high level viewpoint but far more revolutionary in terms of the number of transistors that have been changed since Nehalem/Westmere. The biggest change for Sandy Bridge (and all microarchitectures since) is the micro-op cache (uOp cache).

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/uopcache.jpg

In Sandy Bridge, there’s now a micro-op cache that caches instructions as they’re decoded. There’s no sophisticated algorithm here, the cache simply grabs instructions as they’re decoded. When SB’s fetch hardware grabs a new instruction it first checks to see if the instruction is in the micro-op cache, if it is then the cache services the rest of the pipeline and the front end is powered down. The decode hardware is a very complex part of the x86 pipeline, turning it off saves a significant amount of power.

The cache is direct mapped and can store approximately 1.5K micro-ops, which is effectively the equivalent of a 6KB instruction cache. The micro-op cache is fully included in the L1 instructioncache and enjoys approximately an 80% hit rate for most applications. You get slightly higher and more consistent bandwidth from the micro-op cache vs. the instruction cache. The actual L1 instruction and data caches haven’t changed, they’re still 32KB each (for total of 64KB L1).

All instructions that are fed out of the decoder can be cached by this engine and as I mentioned before, it’s a blind cache - all instructions are cached. Least recently used data is evicted as it runs out of space. This may sound a lot like Pentium 4’s trace cache but with one major difference: it doesn’t cache traces. It really looks like an instruction cache that stores micro-ops instead of macro-ops (x86 instructions).

Along with the new micro-op cache, Intel also introduced a completely redesigned branch prediction unit. The new BPU is roughly the same footprint as its predecessor, but is much more accurate. The increase in accuracy is the result of three major innovations.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/BPU.jpg

The standard branch predictor is a 2-bit predictor. Each branch is marked in a table as taken/not taken with an associated confidence (strong/weak). Intel found that nearly all of the branches predicted by this bimodal predictor have a strong confidence. In Sandy Bridge, the bimodal branch predictor uses a single confidence bit for multiple branches rather than using one confidence bit per branch. As a result, you have the same number of bits in your branch history table representing many more branches, which can lead to more accurate predictions in the future.

Branch targets also got an efficiency makeover. In previous architectures there was a single size for branch targets, however it turns out that most targets are relatively close. Rather than storing all branch targets in large structures capable of addressing far away targets, SNB now includes support for multiple branch target sizes. With smaller target sizes there’s less wasted space and now the CPU can keep track of more targets, improving prediction speed.

Finally we have the conventional method of increasing the accuracy of a branch predictor: using more history bits. Unfortunately this only works well for certain types of branches that require looking at long patterns of instructions, and not well for shorter more common branches (e.g. loops, if/else). Sandy Bridge’s BPU partitions branches into those that need a short vs. long history for accurate prediction.

A Physical Register File

Compared to Westmere, Sandy Bridge moves to a physical register file. In Core 2 and Nehalem, every micro-op had a copy of every operand that it needed. This meant the out-of-order execution hardware (scheduler/reorder buffer/associated queues) had to be much larger as it needed to accommodate the micro-ops as well as their associated data. Back in the Core Duo days that was 80-bits of data. When Intel implemented SSE, the burden grew to 128-bits. With AVX however we now have potentially 256-bit operands associated with each instruction, and the amount that the scheduling/reordering hardware would have to grow to support the AVX execution hardware Intel wanted to enable was too much.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/PRF.jpg

A physical register file stores micro-op operands in the register file; as the micro-op travels down the OoO engine it only carries pointers to its operands and not the data itself. This significantly reduces the power of the out of order execution hardware (moving large amounts of data around a chip eats tons of power), and it also reduces die area further down the pipe. The die savings are translated into a larger out of order window.

The die area savings are key as they enable one of Sandy Bridge’s major innovations: AVX performance.

AVX

The AVX instructions support 256-bit operands, which as you can guess can eat up quite a bit of die area. The move to a physical register file enabled Intel to increase the OoO buffers to properly feed a higher throughput floating point engine. Intel clearly believes in AVX as it extended all of its SIMD units to 256-bit wide. The extension is done at minimal die expense. Nehalem has three execution ports and three stacks of execution units:

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/AVX1.jpg

Sandy Bridge allows 256-bit AVX instructions to borrow 128-bits of the integer SIMD datapath. This minimizes the impact of AVX on the execution die area while enabling twice the FP throughput, you get two 256-bit AVX operations per clock (+ one 256-bit AVX load).

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/AVX2.jpg

Granted you can’t mix 256-bit AVX and 128-bit integer SSE ops, however remember SNB now has larger buffers to help extract more instruction level parallelism (ILP).

Load and Store

The improvements to Sandy Bridge’s FP performance increase the demands on the load/store units. In Nehalem/Westmere you had three LS ports: load, store address and store data.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/memory1.jpg

In SNB, the load and store address ports are now symmetric so each port can service a load or store address. This doubles the load bandwidth compared to Westmere, which is important as Intel doubled the peak floating point performance in Sandy Bridge.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/memory2.jpg

There are some integer execution improvements in Sandy Bridge, although they are more limited. Add with carry (ADC) instruction throughput is doubled, while large scale multiplies (64 * 64) see a ~25% speedup.

https://images.anandtech.com/reviews/cpu/intel/sandybridge/arch/otherarch.jpg

Upgrading from an Intel Core i7-2600K: Testing Sandy Bridge in 2019 Sandy Bridge: Outside the Core
POST A COMMENT

206 Comments

View All Comments

  • mode_13h - Saturday, May 11, 2019 - link

    If you get a gun, you'll just have to waste more money on ammo.

    And the thing about targets is they don't shoot back. So, it gets boring pretty quickly. Paintball is more fun.
    Reply
  • Ghodzilla5150 - Saturday, May 11, 2019 - link

    I just built an AMD Rig with a Ryzen 7 2700X, ASRock X470 Taichi Ultimate, Sapphire Nitro+ RX 590, 32gb G.SKILL RIPJAWS Series V & 2x 1TB M.2 drives (1 for OS and other for Gaming). Boots to Win 10 Pro in 8 seconds. Blazing fast in games.

    I just bought a Smith & Wesson 686 Plus 357 Magnum so I know what it's like to want a gun as well. I'm looking at getting a LMT Valkyrie 224.
    Reply
  • mode_13h - Saturday, May 11, 2019 - link

    Get a Ryzen 9 with 16 cores. Reply
  • MrCommunistGen - Friday, May 10, 2019 - link

    I'm in almost exactly the same boat. I have a 3770K on Z77 running at 4.2GHz. That's all that I could get out of my chip without thermal throttling under heavy load with a 212 EVO... already running the lowest possible voltage that it is stable. Remounted the cooler several times, upgraded the fan, and switched out the paste to Thermal Grizzly but it didn't help enough to get me to 4.3GHz.
    I considered throwing a bigger cooler at it but decided to save that money for my next build instead.

    Running 1440p 75Hz Freesync (only 48-75Hz range) display that I picked up before Vega launched with the intention of buying Vega when it released -- but I missed buying it at launch, then it was unavailable, then it was expensive, then the crypto boom meant you couldn't get one... so I bought a 1080Ti instead. Even with the newly added Freesync compatibility I'm getting a reasonable bit of stutter that frustrates me.

    Strongly considering Zen2 when it comes out. I never seriously considered upgrading to anything else so far, not Haswell through KBL due to lack of performance increase for the price, and not CFL or CFL-R due to high cost. 2700X just doesn't quite have enough single-thread performance increase, but based on the swirling rumors I think Zen2 will get there.
    Reply
  • Polyclot - Saturday, May 11, 2019 - link

    I have a 2600k/z77-a. I was under the impression that the mobo wouldn't go above 4.2. At least that's where I'm at. Love the combo. No complaints Reply
  • CaedenV - Saturday, May 11, 2019 - link

    Nope, the cap is for the non-K chips. There you have a 42x multiplier cap with a 100 MHz clock, so you are limited to 4.2... unless you also change the base clock, but that causes other issues that are not worth the effort to address.
    If you have a K chip, the only limits are your RAM, and cooling. Almost all Sandy chips can hit 4.5GHz, with a majority capable of going above 4.8!
    Reply
  • XXxPro_bowler420xXx - Saturday, May 11, 2019 - link

    I have a non k 3770 running at 4.2ghz all core, 4.4 single. It's also undervolted to 1.08V and hits a MAX temp of 55-56C after months of use on a corsair AIO and liquid metal . Usually runs in the high 40s under load. Before de-lidding it, it ran in the high 60s at 4.2ghz on a corsair air cooler and arctic mx4 paste. Why are your temperatures so high?

    AsRock z77 extreme 4 and 16GB 2133 ram.
    Reply
  • XXxPro_bowler420xXx - Saturday, May 11, 2019 - link

    Also I agree with you on zen 2. Finally a worthy successor. Reply
  • CaedenV - Saturday, May 11, 2019 - link

    Yep, if I were to upgrade today, it would be an AMD chip. And that is hard to say/admit with all of my inner Intel fanboy. Reply
  • fangdahai - Friday, May 10, 2019 - link

    Same here, 3770. It's still fast enough......at least no big difference with the last Intel CPU. Reply

Log in

Don't have an account? Sign up now