Haswell's Wide Execution Engine

Conroe introduced the six execution ports that we've seen used all the way up to Ivy Bridge. Sandy Bridge saw significant changes to the execution engine to enable 256-bit AVX operations but without increasing the back end width. Haswell does a lot here.

Just as before, I put together a few diagrams that highlight the major differences throughout the past three generations for the execution engine.


The reorder buffer is one giant tracking structure for all of the micro-ops that are in various stages of execution. The size of this buffer is directly impacted by the accuracy of the branch predictor as that will determine how many instructions can be kept in flight at a given time.

The reservation station holds micro-ops as they wait for the data they need to begin execution. Both of these structures grow by low double-digit percentages in Haswell.

Simply being able to pick from more instructions to execute in parallel is one thing, we haven't seen an increase in the number of parallel execution ports since Conroe. Haswell changes that.

From Conroe to Ivy Bridge, Intel's Core micro-architecture has supported the execution of up to six micro-ops in parallel. While there are more than six execution units in the system, there are only six ports to stacks of execution units. Three ports are used for memory operations (loads/stores) while three are on math duty. Over the years Intel has added additional types and widths of execution units (e.g. Sandy Bridge added 256-bit AVX operations) but it hasn't strayed from the 6 port architecture.

Haswell finally adds two more execution ports, one for integer math and branches (port 6) and one for store address calculation (port 7). Including both additional compute and memory hardware is a balanced decision on Intel's part.

The extra ALU and port does one of two things: either improve performance for integer heavy code, or allow integer work to continue while FP math occupies ports 0 and 1. Remember that Haswell, like its predecessors, is an SMT design meaning each core will see instructions from up to two threads at the same time. Although a single app is unlikely to mix heavy vector FP and integer code, it's quite possible that two applications running at the same time may produce such varied instructions. Having more integer ALUs is never a bad thing.

Also using port 6 is another unit that can handle x86 branch instructions. Branch heavy code can now enjoy two independent branch units, or if port 0 is occupied with other math the machine can still execute branches on port 6. Haswell moved the original Core branch unit from port 5 over to port 0, the most capable port in the system, so a branch unit on a lightly populated port makes helps ensure there's no performance regression as a result of the change.

Sandy Bridge made ports 2 & 3 equal class citizens, with both capable of being used for load or store address calculation. In the past you could only do loads on port 2 and store addresses on port 3. Sandy Bridge's flexibility did a lot for load heavy code, which is quite common. Haswell's dedicated store address port should help in mixed workloads with lots of loads and stores.

The other major addition to the execution engine is support for Intel's AVX2 instructions, including FMA (Fused Multiply-Add). Ports 0 & 1 now include newly designed 256-bit FMA units. As each FMA operation is effectively two floating point operations, these two units double the peak floating point throughput of Haswell compared to Sandy/Ivy Bridge. A side effect of the FMA units is that you now get two ports worth of FP multiply units, which can be a big boon to legacy FP code.

Fused Multiply-Add operations are incredibly handy in all sorts of media processing and 3D work. Rather than having to independently multiply and add values, being able to execute both in tandem via a single execution port increases the effective execution width of the machine. Note that a single FMA operation takes 5 cycles in Haswell, which is the same latency as a FP multiply from Sandy/Ivy Bridge. In the previous generation a floating point multiply+add took 8 cycles, so there's a good latency improvement here as well as the throughput boost from having two FMA units.

Intel focused a lot on adding more execution horsepower in Haswell without creating a power burden for legacy use cases. All of the new units can be shut off when not in use. Furthermore, Intel went in and ensured that this applied to the older execution units as well: in Haswell if you're not doing work, you're not consuming power.

Prioritizing ILP Feeding the Beast: 2x Cache Bandwidth in Haswell
Comments Locked

245 Comments

View All Comments

  • tim851 - Friday, October 5, 2012 - link

    This is a perfect demonstration of the power of competition.

    With AMD struggling badly, Intel was content in pushing Atom. They didn't want to innovate in that sector, they sold 10 year old technology with horribly outdated chipsets. Yes, they were relatively cheap, but I was appalled.

    Step in ARM, suddenly becoming a viable competitor. Now Intel moves its fat ass and tries to actually build something worthwhile.

    Sadly, free markets are an illusion. Intel should pay dearly for the Atom fiasco, but they won't. Just as they didn't pay for the Pentium 4 debacle. They will come 5 years late to the party, but with all their might, they will crush ARM. ARM will fall behind, they can't keep up with that viscious tick-tock-cycle. Who can?

    In 8 years, ARM will have been bought by some company, perhaps Apple. ARM will then no longer be a competitor, it will be just a different architecture, like X86. I don't see Apple having any long-term interest in designing their own hardware, it's way too unsexy. They will just cross-licence ARM with Intel and in 10 years time, Intel will rule supremely again.
  • UpSpin - Friday, October 5, 2012 - link

    You forget that Intel vs. ARM is something bigger than AMD vs. Intel.
    Behind ARM stand Qualcomm, Samsung, Apple, ...
    All new software is written for ARM, not Intel (x86) any longer. Microsoft releases a rewritten ARM Windows RT with a rewritten Office for ARM. Android runs on ARM and everyone supports the ARM version, while only Intel has to keep it compatible with x86.
    Haswell will get released, when exactly? In a year, ARM A15 in maybe two months. Haswell has nice power savings, but it's still a Ultrabook design. The current Atom SoCs are much worse than current A9/Krait SoCs. Intel heavily optimized the software to make it look not that bad (excellent Sunspider results), but they are.
    If Windows 8 is a success, Intel can be lucky. If it's not, what many expect, Intel has a real problem.

    Intel is a single company building and developing their CPU/SoC. ARM SoCs get build and developed by a magnitude of companies.

    If Apple can design their own ARM based SoC which has the same performance as a Haswell CPU (which is easy in the GPU area (the iPad has a faster GPU than the Intel CPUs most probably already, and with A15 and Apples A6 it's possible to get as fast with the CPU, too), they will be able to move Mac OS to ARM. This allows them to build a very very power efficient, lightweight, silent MacBook. They can port apps from iOS to MacOS and vice versa. Because they designed their SoC in-house, they don't have to fear competition the near term.

    Apple always wants a monopoly, so it doesn't make sense for them to cross-license anything.
  • tuxRoller - Friday, October 5, 2012 - link

    Unless your app is doing some serious math you can get by with just using a cross platform key chain.
    Frankly, the hard part is targeting the different apis that are, currently, predominating on each arch. However, assuming those don't change , and the form factor doesn't either, your new app should just be a compile away.
  • Kidster3001 - Monday, October 15, 2012 - link

    Current ATOM SOC's are not "much worse" than A9/Krait. Most CPU benchmarks running in native code will favor the Intel SoC. It's the addition of Android/Dalvik that leans the favor back to ARM. Android has been on ARM for a lot longer and is more optimized for ARM code. Android needs to be tweaked more yet to run optimally on x86.
  • Kidster3001 - Monday, October 15, 2012 - link

    " with A15 and Apples A6 it's possible to get as fast with the CPU, too"

    say what? A15 and A6 are a full order of magnitude slower than Haswell. omg
  • Dalamar6 - Sunday, May 12, 2013 - link

    Nearly all of the software on Android is junk.
    Apple blocks everything at a whim and gives no control.
    I don't know about Windows RT, but I suspect it will suffer the same manner of crap programs Android does if it's not already.

    Even if people are more focused on developing for ARM, the ARM OSes are still way behind in program availability(especially quality). And it's downright sad seeing people charging money for simple, poorly coded programs that can't even compare to existing open source x86 software.
  • jacobdrj - Friday, October 5, 2012 - link

    I agree competition is good/great. However, how you categorize Atom is just not true! Atom filled a very real niche. Cheap mobile computing. Not powerful, but x86 and fast enough to do basic tasks. I loved my Atom netbook and used it until it bit the dust last week. Would I have liked more power? Sure, but not at the expense of (at the time) battery life. Besides, once I maxed it out by putting in a SSD and 2 GB RAM, my netbook often outpaced many peoples' newer more powerful Core based laptops for basic tasks like word processing and web browsing.

    Just because power users were unhappy does not mean Atom was a 'fiasco'. Those old chipsets allowed Atom netbooks to regularly sell, fully functional, for under $200, a price point that Tablets of similar capability are only just starting to hit almost 4 years later...

    Don't bash Atom just because you don't fit into it's niche and don't blame Intel for HP trying to oversell Atom to the wrong customers...
  • Peanutsrevenge - Friday, October 5, 2012 - link

    If competition is 'good/great' what does that make cooperation?

    Imagine the possibility of Intel and AMD working together along with Qualcomm, Imagination etc.....

    Zeitgeist Movement.
  • Kidster3001 - Monday, October 15, 2012 - link

    Intel is not going this way because "ARM stepped in". Intel is going this way because it decided to go play in ARMs playground.
  • krumme - Friday, October 5, 2012 - link

    My Samsung 9 series x3c (ivy bridge), have a usage looking on this page with wifi at bt on ranging from 4.9W to 9.9W from lowest to higest screen brightness, with a normal usage of screen of 7.2W with good brightness (using samsung own measuring tool).

    So screen is by far the most important component on a modern machine. In the complete ecosystem i wonder if it matter how efficient Haswell is. The benefit of 10W tdp for say the same performance is nice, but does it really matter for the market effect. And the idle power is already plenty low.

    I doubt Haswell will have an significant impact - as nice as it is. This is just to late and way to expensive for the mass market. Those days are over.

    At the time it hits market dirt cheap TSMC 28nm A15 and bobcat successor hits the market for next to nothing, and will give 99% of the consumers the same benefits.

Log in

Don't have an account? Sign up now