3 ms·

Intel’s Netburst: Failure Is a Foundation for Success

94 points by zdw 4y ago

Tuna-Fish 4y ago
This article really drives home the commonly ignored point about Intel CPUs: Sandy Bridge is a P4 derivative with all the faults fixed and the sharp edges filed off, not a P6/core 2 derivative.
- bonzini 4y ago
  I don't know if you can say that without the trace cache and super long pipeline (31 stages!). More in general, the problem with Netburst was that it was extremely inefficient (high L1d latency, steep branch prediction cliffs, smallish L1i trace cache) and tried to solve the inefficiencies just by throwing transistors and hertz at it. That's absolutely not how Sandy Bridge is designed. It's clearly a Core derivative with a uop cache, if you look at the overall structure of the pipeline. Yes, other ideas have been successfully integrated into Core derivatives such as SMT, better branch predictors and the Alpha-like OoO engine, but then even the first in-order Atoms had SMT.
  - Tuna-Fish 4y ago
    > It's clearly a Core derivative with a uop cache, if you look at the overall structure of the pipeline. Er, no. The structure of the pipeline is exactly what it took from the P4. P6 derivatives, including core, store in-flight results in the ROB, and then write them back to the RRF at retire. RRF read ports are a limited, shared resource, with full throughput only achieved when most instructions get their operands from the ROB. P4 and SNB store only pointers in the ROB, putting all results directly into the PRF, with no work done on retire. The PRF has enough ports to serve all requests. This is an entirely different way to organize the cpu.
    - bonzini 4y ago
      The PRF is what I meant by "the Alpha-like OoO engine". It was not an innovation specific to Netburst, AMD uses it too nowadays and it's not really possible to do otherwise with 256- and 512-bit AVX registers. The structure of the Netburst front end depended heavily on the trace cache while the Sandy Bridge uop cache is more like an "L0" that can miss sometimes. The back end of Sandy Bridge doesn't need the messy replay system that was in Netburst. So this is what I meant by the pipeline being more similar to Nehalem.
    - n7pdx 4y ago
      You are completely over-complicating things. P6 derivatives stuck with “traditional” Tomasulo algorithm for way too long. Everyone else moved to pointers for arch regs long before Intel did: MIPS 10k, DEC, AMD, Intel P4, etc, it isn’t really that big of a deal and is actually a simplification from the design aspect. There hasn’t been a total overhaul of CPU arch in decades. For whatever reason, Intel called this mechanism “marbles”. There are a bunch of names in the industry for this: PRF, arch pointers, etc… its all the same thing. By the way, moving to arch pointers is precisely what adds additional work on retirement: you need to do a walk or checkpoint restore to revert the arch state back to where it needs to be. With P6/Tomasulo, it is free. You got it backwards.
- masklinn 4y ago
  > Sandy Bridge is a P4 derivative with all the faults fixed and the sharp edges filed off, not a P6/core 2 derivative. That SB reintroduced netburst features doesn't change the history of the µarch. That's like saying Netburst not using a ROB means it was an evolution of Alpha rather than P6. SB was not a renaissance of Netburst, it was a reintroduction, into the Core family, of features which Intel had first introduced in Netburst. Something which had already happened previously (e.g. hyperthreading in Nehalem) and would continue in the future (e. reintroduction of non-unified schedulers). The "faults and sharp edges" of netburst were all caused by features which were at the core of netburst's identity, that's why it was a dead end and intel had to reset back to a sane working slate. As the article notes: > Some of the fundamental ideas behind the architecture were definitely flawed. And that Core was able to successfully integrate over time features first attempted in Netburst is exactly what you'd expect: many (though not all) of the individual features were not intrinsically bad and in fact several had been deployed successfully by other companies. As the article specifically notes, the issues were introducing them all at once: > Netburst debuted a mountain of new microarchitecture techniques. Some of these had been implemented by other companies, but were new to Intel. In general, the more you depart off the known path, the more risk you take. More changes mean more moving parts to tune and validate. Intel clearly took on way too much risk. Especially in an architecture whose fundamental concepts and tradeoffs turned out to be unsound.
  - ghaff 4y ago
    >As the article specifically notes, the issues were introducing them all at once: And you could say the same thing about Itanium. (In fact, Gordon Bell did.) The real problem was Intel's focus on frequency above all else at the time. They were demoing I think a 10 GHz processor at Intel Developer Forum at one point. A few years later as the world had pretty much entirely shifted to multicore, a senior Intel exec I was doing some work for basically told me that of course they knew the challenges around ramping frequency. But Microsoft was apparently very concerned about the ability of Windows to use multiple cores. There was a lot of concern in the industry at the time around how well software--especially on the desktop--would be able to take advantage of multiple cores.
    - 4y ago
- n7pdx 4y ago
  No, it wasn’t. Sandybridge started with the Nehalem code base. I was there when it happened.
  - benreesman 4y ago
    I love about HN that we can be having the (totally normal) speculation food fight and then someone just casually drops by with: “It was X, I was in the room when it happened”.
retskrad 4y ago
Apple’s M1 instantly made Windows laptops obsolete. Why go back to much worse battery life and loud fans? I checked Intels roadmap and it looks promising. They seem to aim for parity with TSMC before 2025. It’s going to be interesting if they win some of Apple’s business and make ARM chips for them.
- rbinv 4y ago
  What roadmap are you referring to specifically? Historically speaking, Intel's roadmaps have always looked quite promising. However, they're also known for not really delivering on them. I seriously doubt they can catch up to TSMC by 2025 (if ever).
  - deleted 4y ago
    [deleted]
- Macha 4y ago
  Because it's not like windows laptops stood still in the face of the m1, and we're already seeing them get ahead in many use cases for lower power chips than the m1 pro when you look at the comparisons with the 1260P/6800U: https://www.youtube.com/watch?v=UK5T4SvTgeQ https://www.youtube.com/watch?v=UK5T4SvTgeQ
- tambourine_man 4y ago
  Intel's only hope in the short to medium term is to manufacture at TSMC, like everyone else.
  - BirAdam 4y ago
    Nah. Just having tons of manufacturing capacity on 14nm and 10nm and being able to sell cheap can guarantee Intel a place at the table for a while. They don’t compete for manufacturing at TSMC and this is their current advantage. Apple M1 and Intel have continued to do well, because it was silicon you could actually get for the last two years.
    - 4y ago
scrlk 4y ago
Was NetBurst the last clean sheet Intel microarchitecture design?
- bonzini 4y ago
  No, Atom came later.
  - throwaheyy 4y ago
    Wasn’t Atom based off the P5 (original Pentium) core and not a clean sheet, making Itanium the last clean sheet design?
    - bonzini 4y ago
      They had similar superscalar abilities (2 instructions per cycle, in order) but it was not based on the P5 as far as I know. It was a pretty deep pipeline, unlike the one in the P5, and didn't have any AGU stalls. Larrabee was based on the P5 though.
      - throwaheyy 4y ago
        Ah, that’s the one I was confusing it with, thank you.
- bogomipz 4y ago
  What does "clean sheet" mean here?
  - scrlk 4y ago
    A completely new design, typically breaking away from the previous design (AMD's Zen microarchitecture being a more recent example).
    - glowingly 4y ago
      That did keep some previous aspects of AMD design, notably subclusters of shared last level cache on a single chip. Zen1 and Zen2 used 4 core clusters of shared L3, with accesses to the other 4 core cluster requiring a bit more latency as it was going outside of the CCX. Zen3 changed this, so it no longer applies in the same way. The result was some latency graphs such as: https://www.anandtech.com/show/15708/amds-mobile-revival-redefining-the-notebook-business-with-the-ryzen-9-4900hs-a-review/2 https://www.anandtech.com/show/15708/amds-mobile-revival-red...
sassy_quat 4y ago
If failure really was a foundation for success, we reimplement all these technologies we software emulate now and where the patent has expired so we could implement them in hardware, including the firmware by hardbaking it as an ASIC (certainly ASIC memory is more dense than flash and obviously more so than SRAM). For example, putting a pre-Y2K pentium on a chip with soundblaster, using diodes for power, and using wireless communication. It'd make the RISC-V ESP32 look wimpy. The state of modern technology is shameful.
- raverbashing 4y ago
  > It'd make the RISC-V ESP32 look wimpy. It wouldn't. Not to mention you'd have to bring all the x86 arch crap with it. But you can now do that reimplementation, the P5 is more than 20 yrs old now.
  - hakfoo 4y ago
    I wonder where the cutoff is where the value in the existing (legacy) x86 ecosystem beats the performance offered by a new platform like RISC-V. The software stacks available are probably going to be more battle-tested. I'm also curious if there's more potential in resuscitating legacy code at the "application" level, if you knew you could run it in an embedded box which drew a fraction of a watt. Maybe all you really need is something that already existed as a DOS application. However, it's comparing apples and freight locomotives. The main part of the x86 historic story revolved around desktop computing and keyboard-mouse-screen interactions[1], and the ESP32's is about internet-of-things and GPIOs, so even if the x86 module is beefier, it's tooling and connectivity may not be what you want out of the box if you were considering an ESP32. On the other hand, we do see some places where they're clearly trying to hammer things like low-end ARM and ESP32 into vaguely more screen-and-keyboard things. I'm thinking of things like dedicated word-processor appliances (Alphasmart, etc.) or 300-in-1 knockoff consoles, where you could reasonably implement them as a 586-class CPU running off-the-shelf-software. [1] Yes, I know full well there are loads of embedded x86 environments that look nothing like a PC. In university, our assembly language course involved setting up an 80186 developer board tethered to an ADM-3 terminal to be the world's most expensive digital clock.
granularity 4y ago
> we’ll use period-correct graphs, created on Office XP So beautiful.
- deleted 4y ago
  [deleted]
eigenform 4y ago
Nice article, love retrospective pieces like this! Maybe also worth mentioning that there's an Intel Technology Journal issue dedicated to P4: https://www.intel.com/content/dam/www/public/us/en/documents/research/2001-vol05-iss-1-intel-technology-journal.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
GeekyBear 4y ago
Watching Intel once again go through a period where pushing frequency is the main way to gain performance has definitely led to a sense of deja vu. How long until modern laptops can boil pasta the way a Pentium 4 desktop famously could? https://www.youtube.com/watch?v=veALz35LV9U https://www.youtube.com/watch?v=veALz35LV9U
simne 4y ago
I remember, how many hate calls appear of "near same" cpus, with near same frequency and near same cache size, but one on P3 microarchitecture and other - netburst :-E

94 points by zdw 4y ago

This article really drives home the commonly ignored point about Intel CPUs: Sandy Bridge is a P4 derivative with all the faults fixed and the sharp edges filed off, not a P6/core 2 derivative.

bonzini 4y ago
I don't know if you can say that without the trace cache and super long pipeline (31 stages!). More in general, the problem with Netburst was that it was extremely inefficient (high L1d latency, steep branch prediction cliffs, smallish L1i trace cache) and tried to solve the inefficiencies just by throwing transistors and hertz at it. That's absolutely not how Sandy Bridge is designed. It's clearly a Core derivative with a uop cache, if you look at the overall structure of the pipeline. Yes, other ideas have been successfully integrated into Core derivatives such as SMT, better branch predictors and the Alpha-like OoO engine, but then even the first in-order Atoms had SMT.
- Tuna-Fish 4y ago
  > It's clearly a Core derivative with a uop cache, if you look at the overall structure of the pipeline. Er, no. The structure of the pipeline is exactly what it took from the P4. P6 derivatives, including core, store in-flight results in the ROB, and then write them back to the RRF at retire. RRF read ports are a limited, shared resource, with full throughput only achieved when most instructions get their operands from the ROB. P4 and SNB store only pointers in the ROB, putting all results directly into the PRF, with no work done on retire. The PRF has enough ports to serve all requests. This is an entirely different way to organize the cpu.
  - bonzini 4y ago
    The PRF is what I meant by "the Alpha-like OoO engine". It was not an innovation specific to Netburst, AMD uses it too nowadays and it's not really possible to do otherwise with 256- and 512-bit AVX registers. The structure of the Netburst front end depended heavily on the trace cache while the Sandy Bridge uop cache is more like an "L0" that can miss sometimes. The back end of Sandy Bridge doesn't need the messy replay system that was in Netburst. So this is what I meant by the pipeline being more similar to Nehalem.
  - n7pdx 4y ago
    You are completely over-complicating things. P6 derivatives stuck with “traditional” Tomasulo algorithm for way too long. Everyone else moved to pointers for arch regs long before Intel did: MIPS 10k, DEC, AMD, Intel P4, etc, it isn’t really that big of a deal and is actually a simplification from the design aspect. There hasn’t been a total overhaul of CPU arch in decades. For whatever reason, Intel called this mechanism “marbles”. There are a bunch of names in the industry for this: PRF, arch pointers, etc… its all the same thing. By the way, moving to arch pointers is precisely what adds additional work on retirement: you need to do a walk or checkpoint restore to revert the arch state back to where it needs to be. With P6/Tomasulo, it is free. You got it backwards.
masklinn 4y ago
> Sandy Bridge is a P4 derivative with all the faults fixed and the sharp edges filed off, not a P6/core 2 derivative. That SB reintroduced netburst features doesn't change the history of the µarch. That's like saying Netburst not using a ROB means it was an evolution of Alpha rather than P6. SB was not a renaissance of Netburst, it was a reintroduction, into the Core family, of features which Intel had first introduced in Netburst. Something which had already happened previously (e.g. hyperthreading in Nehalem) and would continue in the future (e. reintroduction of non-unified schedulers). The "faults and sharp edges" of netburst were all caused by features which were at the core of netburst's identity, that's why it was a dead end and intel had to reset back to a sane working slate. As the article notes: > Some of the fundamental ideas behind the architecture were definitely flawed. And that Core was able to successfully integrate over time features first attempted in Netburst is exactly what you'd expect: many (though not all) of the individual features were not intrinsically bad and in fact several had been deployed successfully by other companies. As the article specifically notes, the issues were introducing them all at once: > Netburst debuted a mountain of new microarchitecture techniques. Some of these had been implemented by other companies, but were new to Intel. In general, the more you depart off the known path, the more risk you take. More changes mean more moving parts to tune and validate. Intel clearly took on way too much risk. Especially in an architecture whose fundamental concepts and tradeoffs turned out to be unsound.
- ghaff 4y ago
  >As the article specifically notes, the issues were introducing them all at once: And you could say the same thing about Itanium. (In fact, Gordon Bell did.) The real problem was Intel's focus on frequency above all else at the time. They were demoing I think a 10 GHz processor at Intel Developer Forum at one point. A few years later as the world had pretty much entirely shifted to multicore, a senior Intel exec I was doing some work for basically told me that of course they knew the challenges around ramping frequency. But Microsoft was apparently very concerned about the ability of Windows to use multiple cores. There was a lot of concern in the industry at the time around how well software--especially on the desktop--would be able to take advantage of multiple cores.
  - 4y ago
n7pdx 4y ago
No, it wasn’t. Sandybridge started with the Nehalem code base. I was there when it happened.
- benreesman 4y ago
  I love about HN that we can be having the (totally normal) speculation food fight and then someone just casually drops by with: “It was X, I was in the room when it happened”.

retskrad 4y ago

Apple’s M1 instantly made Windows laptops obsolete. Why go back to much worse battery life and loud fans? I checked Intels roadmap and it looks promising. They seem to aim for parity with TSMC before 2025. It’s going to be interesting if they win some of Apple’s business and make ARM chips for them.

rbinv 4y ago
What roadmap are you referring to specifically? Historically speaking, Intel's roadmaps have always looked quite promising. However, they're also known for not really delivering on them. I seriously doubt they can catch up to TSMC by 2025 (if ever).
- deleted 4y ago
  [deleted]
Macha 4y ago
Because it's not like windows laptops stood still in the face of the m1, and we're already seeing them get ahead in many use cases for lower power chips than the m1 pro when you look at the comparisons with the 1260P/6800U: https://www.youtube.com/watch?v=UK5T4SvTgeQ https://www.youtube.com/watch?v=UK5T4SvTgeQ
tambourine_man 4y ago
Intel's only hope in the short to medium term is to manufacture at TSMC, like everyone else.
- BirAdam 4y ago
  Nah. Just having tons of manufacturing capacity on 14nm and 10nm and being able to sell cheap can guarantee Intel a place at the table for a while. They don’t compete for manufacturing at TSMC and this is their current advantage. Apple M1 and Intel have continued to do well, because it was silicon you could actually get for the last two years.
  - 4y ago

scrlk 4y ago

Was NetBurst the last clean sheet Intel microarchitecture design?

bonzini 4y ago
No, Atom came later.
- throwaheyy 4y ago
  Wasn’t Atom based off the P5 (original Pentium) core and not a clean sheet, making Itanium the last clean sheet design?
  - bonzini 4y ago
    They had similar superscalar abilities (2 instructions per cycle, in order) but it was not based on the P5 as far as I know. It was a pretty deep pipeline, unlike the one in the P5, and didn't have any AGU stalls. Larrabee was based on the P5 though.
    - throwaheyy 4y ago
      Ah, that’s the one I was confusing it with, thank you.
bogomipz 4y ago
What does "clean sheet" mean here?
- scrlk 4y ago
  A completely new design, typically breaking away from the previous design (AMD's Zen microarchitecture being a more recent example).
  - glowingly 4y ago
    That did keep some previous aspects of AMD design, notably subclusters of shared last level cache on a single chip. Zen1 and Zen2 used 4 core clusters of shared L3, with accesses to the other 4 core cluster requiring a bit more latency as it was going outside of the CCX. Zen3 changed this, so it no longer applies in the same way. The result was some latency graphs such as: https://www.anandtech.com/show/15708/amds-mobile-revival-redefining-the-notebook-business-with-the-ryzen-9-4900hs-a-review/2 https://www.anandtech.com/show/15708/amds-mobile-revival-red...

sassy_quat 4y ago

If failure really was a foundation for success, we reimplement all these technologies we software emulate now and where the patent has expired so we could implement them in hardware, including the firmware by hardbaking it as an ASIC (certainly ASIC memory is more dense than flash and obviously more so than SRAM). For example, putting a pre-Y2K pentium on a chip with soundblaster, using diodes for power, and using wireless communication. It'd make the RISC-V ESP32 look wimpy. The state of modern technology is shameful.

raverbashing 4y ago
> It'd make the RISC-V ESP32 look wimpy. It wouldn't. Not to mention you'd have to bring all the x86 arch crap with it. But you can now do that reimplementation, the P5 is more than 20 yrs old now.
- hakfoo 4y ago
  I wonder where the cutoff is where the value in the existing (legacy) x86 ecosystem beats the performance offered by a new platform like RISC-V. The software stacks available are probably going to be more battle-tested. I'm also curious if there's more potential in resuscitating legacy code at the "application" level, if you knew you could run it in an embedded box which drew a fraction of a watt. Maybe all you really need is something that already existed as a DOS application. However, it's comparing apples and freight locomotives. The main part of the x86 historic story revolved around desktop computing and keyboard-mouse-screen interactions[1], and the ESP32's is about internet-of-things and GPIOs, so even if the x86 module is beefier, it's tooling and connectivity may not be what you want out of the box if you were considering an ESP32. On the other hand, we do see some places where they're clearly trying to hammer things like low-end ARM and ESP32 into vaguely more screen-and-keyboard things. I'm thinking of things like dedicated word-processor appliances (Alphasmart, etc.) or 300-in-1 knockoff consoles, where you could reasonably implement them as a 586-class CPU running off-the-shelf-software. [1] Yes, I know full well there are loads of embedded x86 environments that look nothing like a PC. In university, our assembly language course involved setting up an 80186 developer board tethered to an ADM-3 terminal to be the world's most expensive digital clock.

granularity 4y ago

> we’ll use period-correct graphs, created on Office XP So beautiful.

deleted 4y ago
[deleted]

eigenform 4y ago

Nice article, love retrospective pieces like this! Maybe also worth mentioning that there's an Intel Technology Journal issue dedicated to P4: https://www.intel.com/content/dam/www/public/us/en/documents/research/2001-vol05-iss-1-intel-technology-journal.pdf https://www.intel.com/content/dam/www/public/us/en/documents...

GeekyBear 4y ago

Watching Intel once again go through a period where pushing frequency is the main way to gain performance has definitely led to a sense of deja vu. How long until modern laptops can boil pasta the way a Pentium 4 desktop famously could? https://www.youtube.com/watch?v=veALz35LV9U https://www.youtube.com/watch?v=veALz35LV9U

simne 4y ago

I remember, how many hate calls appear of "near same" cpus, with near same frequency and near same cache size, but one on P3 microarchitecture and other - netburst :-E