6 ms·

Intel has always been a process first, design second company. The company was founded by physicists and chemists. Their process has always been the best in the

Intel has always been a process first, design second company. The company was founded by physicists and chemists. Their process has always been the best in the world until just recently. Intel brings in or buys design talent when needed, but their R&D in process technology is their strongest suit even today.

stcredzero 8y ago
Intel has always been a process first, design second company. The company was founded by physicists and chemists. Their process has always been the best in the world until just recently. So they had a particular advantage, and exploited the heck out of it, but now the potency of that advantage is largely gone?
- n-gatedotcom 8y ago
  I don't know what country you're in but in cricket there's a concept of innings and scoring runs. There's this dude who averaged nearly a 100 in every innings, most others average 50. Now think of the situation as him scoring a few knots. Is he old and retiring? Or is this just a slump in form? Nobody knows! I worked for a design team and we were proud of our material engineers.
  - stcredzero 8y ago
    Back in about 1996, most of the profs were going on about how x86 would crumble under the weight of the ISA, and RISC was the future. One of my profs knew people at Intel, and talked of a roadmap they had for kicking butt for the next dozen years. Turns out, the road map was more or less right. Is there more roadmap?
    - hermitdev 8y ago
      Intel chips are RISC under the hood these days (for a long while - decade or more). They're CISC at the ASM layer before the instructions are decoded and dispatched by the microcode.
      - earenndil 8y ago
        CISC is still an asset rather than a liability, though, as it means you can fit more code into cache.
        n-gatedotcom 8y ago
        What is an example of a commonly used complex instruction that is "simplified"/DNE in RISC? (in asm, not binary)
        gpderetta 8y ago
        Load-op instructions do not normally exist on RISC, but are common on CISC.
        adrianN 8y ago
        You do have to worry about the µ-op cache nowadays.
        wtallis 8y ago
        You can fit more code into the same sized cache, but you also need an extra cache layer for the decoded µops, and a much more complicated fetch/decode/dispatch part of the pipeline. It clearly works, at least for the high per-core power levels that Intel targets, but it's not obvious whether it saves transistors or improves performance compared to having an instruction set that accurately reflects the true execution resources, and just increasing the L1i$ size. Ultimately, only one of the strategies is viable when you're trying to maintain binary compatibility across dozens of microarchitecture generations.
        gpderetta 8y ago
        The fact is that a postdecode cache is desirable even on an high performance RISC design as even there skipping decode and fetch is desirable for both performance and power usage. IBM Power9 for example has a predecode stage before L1. You could say that, in general, riscs can get away without extra complexity for a longer time while x86 must implement it early (this is also true for example for memory speculation due to the more restrictive intel memory model, or optimized hardware TLB walkers), but in the end it can be an advantage for x86 (more mature implementation).
    - tw04 8y ago
      There's just no way that's true. Their roadmap in 1996 was moving everyone to ia64/itanium. That was an unmitigated disaster and they were forced to license x64 from AMD. If it weren't for their illegal activity (threats/bribes to partners) to stifle AMDs market penetration, the market would likely look very different today.
      - antod 8y ago
        > There's just no way that's true. Their roadmap in 1996 was moving everyone to ia64/itanium. That was an unmitigated disaster and they were forced to license x64 from AMD. Yup, and their x86 backup plan (Netburst scaling all the way to 10GHz) was a dead end too.
        gpderetta 8y ago
        but their plan C (revive the pentium III architecture) worked perfectly. We will have to see if they have plan C now(plan B being yet another iteration of the lake architecture with little changes).
        m_mueller 8y ago
        doesn't it look like they're shifting to do chiplets as well at the moment? copying AMD might be their plan C, but it won't help if AMD can steam ahead with TSMC 7nm while Intel is locked to 14nm for a couple of years. That's going to hurt a lot.
        pitaj 8y ago
        TSMC's 7nm and Intel's 14nm are about the same in actual dimensions on silicon IIRC. The names for the processes are mostly fluff.
        gpderetta 8y ago
        AFAIK, supposedly TMSC 7nm and Intel 10nm are about equivalent, but with 10nm being in a limbo, TMSC is ahead now.
    - Symmetry 8y ago
      Those profs were still living in 1990 when the x86 tax was still a real issue. As cores get bigger the extra effort involved in handling the x86 ISA gets proportionally smaller. x86 has a accumulated a lot of features over the years and figuring out how, e.g., call gates interact with mis-speculated branches means an x86 design will take more engineering effort than an equivalent RISC design. But with Intel's huge volumes they can more than afford that extra effort. Of course Intel has traditionally always used their volume to be ahead in process technology and at the moment they seem to be slipping behind. So who knows.
      - bogomipz 8y ago
        >"As cores get bigger the extra effort involved in handling the x86 ISA gets proportionally smaller." Can you elaborate on what you mean here? Do you mean as the number of cores gets bigger? Surely the size of the cores has been shrinking no? >"Of course Intel has traditionally always used their volume to be ahead in process technology" What's the correlation between larger volumes and quicker advances in process technology? Is it simply more cash to put back into R and D?
        Symmetry 8y ago
        When RISC was first introduced its big advantage was that by reducing the number of instructions it could handle the whole processor could be fit onto a single chip whereas CISC chips took multiple chips. In the modern day it takes a lot more transistors and power to decode 4 x86 instructions in one cycle than 4 RISC instructions because you know the RISC instruction are going to start on bytes 0, 4, 8, and 12 whereas the x86 instructions could be starting on any bytes in the window. So you have to look at most of the bytes as if they could be an instruction start until later in the cycle you figure out if they were or not. And any given bit in the instruction might be put to more possible uses increasing the logical depth of the decoder. But that complexity only goes up linearly with pipeline depth in constrast to structures like the ROB that grow as the square of the depth. So it's not really a big deal. An ARM server is more likely to just slap on 6 decoders to the front end because "why not?" whereas x86 processors will tend to limit themselves to 4 but that very rarely makes any sort of difference in normal code. The decode stage is just a small proportion of the overall transistor and power cost of a deeply pipelined out of order chip. In, say, dual-issue in-order processors like an A53 the decode tax of an x86 is actually an issue and that's part of why you don't see BIG.little approaches in x86 land and why atom did so poorly in the phone market. For your second question, yes, spending more money means you can pursue more R&D and tend to bring up new process nodes more quickly. Being ahead means that your competitors can see which approaches worked out and which didn't and so re-direct their research more profitably for a rubber band effect, plus you're all reliant on the same suppliers for input equipment so a given advantage in expenditure tends to lead to finite rather than ever-increasing lead.
  - oblio 8y ago
    Your parallel is hard to follow for people who don't watch cricket. I have no idea how 100 or 50 "innings" relate to a few "knots". Are they like some sort of weird imperial measures? (furlongs vs fathoms?)
    - jholman 8y ago
      I suspect that "knots" was supposed to be "noughts", a.k.a zeros. That is, the last few times the 100-point batsman was at bat, he got struck out without scoring any points. Is he washed up? I don't think it's a very useful analogy. :)
  - ctack 8y ago
    Knots as in ducks?

stcredzero 8y ago

Intel has always been a process first, design second company. The company was founded by physicists and chemists. Their process has always been the best in the world until just recently. So they had a particular advantage, and exploited the heck out of it, but now the potency of that advantage is largely gone?

n-gatedotcom 8y ago
I don't know what country you're in but in cricket there's a concept of innings and scoring runs. There's this dude who averaged nearly a 100 in every innings, most others average 50. Now think of the situation as him scoring a few knots. Is he old and retiring? Or is this just a slump in form? Nobody knows! I worked for a design team and we were proud of our material engineers.
- stcredzero 8y ago
  Back in about 1996, most of the profs were going on about how x86 would crumble under the weight of the ISA, and RISC was the future. One of my profs knew people at Intel, and talked of a roadmap they had for kicking butt for the next dozen years. Turns out, the road map was more or less right. Is there more roadmap?
  - hermitdev 8y ago
    Intel chips are RISC under the hood these days (for a long while - decade or more). They're CISC at the ASM layer before the instructions are decoded and dispatched by the microcode.
    - earenndil 8y ago
      CISC is still an asset rather than a liability, though, as it means you can fit more code into cache.
      - n-gatedotcom 8y ago
        What is an example of a commonly used complex instruction that is "simplified"/DNE in RISC? (in asm, not binary)
        gpderetta 8y ago
        Load-op instructions do not normally exist on RISC, but are common on CISC.
      - adrianN 8y ago
        You do have to worry about the µ-op cache nowadays.
      - wtallis 8y ago
        You can fit more code into the same sized cache, but you also need an extra cache layer for the decoded µops, and a much more complicated fetch/decode/dispatch part of the pipeline. It clearly works, at least for the high per-core power levels that Intel targets, but it's not obvious whether it saves transistors or improves performance compared to having an instruction set that accurately reflects the true execution resources, and just increasing the L1i$ size. Ultimately, only one of the strategies is viable when you're trying to maintain binary compatibility across dozens of microarchitecture generations.
        gpderetta 8y ago
        The fact is that a postdecode cache is desirable even on an high performance RISC design as even there skipping decode and fetch is desirable for both performance and power usage. IBM Power9 for example has a predecode stage before L1. You could say that, in general, riscs can get away without extra complexity for a longer time while x86 must implement it early (this is also true for example for memory speculation due to the more restrictive intel memory model, or optimized hardware TLB walkers), but in the end it can be an advantage for x86 (more mature implementation).
  - tw04 8y ago
    There's just no way that's true. Their roadmap in 1996 was moving everyone to ia64/itanium. That was an unmitigated disaster and they were forced to license x64 from AMD. If it weren't for their illegal activity (threats/bribes to partners) to stifle AMDs market penetration, the market would likely look very different today.
    - antod 8y ago
      > There's just no way that's true. Their roadmap in 1996 was moving everyone to ia64/itanium. That was an unmitigated disaster and they were forced to license x64 from AMD. Yup, and their x86 backup plan (Netburst scaling all the way to 10GHz) was a dead end too.
      - gpderetta 8y ago
        but their plan C (revive the pentium III architecture) worked perfectly. We will have to see if they have plan C now(plan B being yet another iteration of the lake architecture with little changes).
        m_mueller 8y ago
        doesn't it look like they're shifting to do chiplets as well at the moment? copying AMD might be their plan C, but it won't help if AMD can steam ahead with TSMC 7nm while Intel is locked to 14nm for a couple of years. That's going to hurt a lot.
        pitaj 8y ago
        TSMC's 7nm and Intel's 14nm are about the same in actual dimensions on silicon IIRC. The names for the processes are mostly fluff.
        gpderetta 8y ago
        AFAIK, supposedly TMSC 7nm and Intel 10nm are about equivalent, but with 10nm being in a limbo, TMSC is ahead now.
  - Symmetry 8y ago
    Those profs were still living in 1990 when the x86 tax was still a real issue. As cores get bigger the extra effort involved in handling the x86 ISA gets proportionally smaller. x86 has a accumulated a lot of features over the years and figuring out how, e.g., call gates interact with mis-speculated branches means an x86 design will take more engineering effort than an equivalent RISC design. But with Intel's huge volumes they can more than afford that extra effort. Of course Intel has traditionally always used their volume to be ahead in process technology and at the moment they seem to be slipping behind. So who knows.
    - bogomipz 8y ago
      >"As cores get bigger the extra effort involved in handling the x86 ISA gets proportionally smaller." Can you elaborate on what you mean here? Do you mean as the number of cores gets bigger? Surely the size of the cores has been shrinking no? >"Of course Intel has traditionally always used their volume to be ahead in process technology" What's the correlation between larger volumes and quicker advances in process technology? Is it simply more cash to put back into R and D?
      - Symmetry 8y ago
        When RISC was first introduced its big advantage was that by reducing the number of instructions it could handle the whole processor could be fit onto a single chip whereas CISC chips took multiple chips. In the modern day it takes a lot more transistors and power to decode 4 x86 instructions in one cycle than 4 RISC instructions because you know the RISC instruction are going to start on bytes 0, 4, 8, and 12 whereas the x86 instructions could be starting on any bytes in the window. So you have to look at most of the bytes as if they could be an instruction start until later in the cycle you figure out if they were or not. And any given bit in the instruction might be put to more possible uses increasing the logical depth of the decoder. But that complexity only goes up linearly with pipeline depth in constrast to structures like the ROB that grow as the square of the depth. So it's not really a big deal. An ARM server is more likely to just slap on 6 decoders to the front end because "why not?" whereas x86 processors will tend to limit themselves to 4 but that very rarely makes any sort of difference in normal code. The decode stage is just a small proportion of the overall transistor and power cost of a deeply pipelined out of order chip. In, say, dual-issue in-order processors like an A53 the decode tax of an x86 is actually an issue and that's part of why you don't see BIG.little approaches in x86 land and why atom did so poorly in the phone market. For your second question, yes, spending more money means you can pursue more R&D and tend to bring up new process nodes more quickly. Being ahead means that your competitors can see which approaches worked out and which didn't and so re-direct their research more profitably for a rubber band effect, plus you're all reliant on the same suppliers for input equipment so a given advantage in expenditure tends to lead to finite rather than ever-increasing lead.
- oblio 8y ago
  Your parallel is hard to follow for people who don't watch cricket. I have no idea how 100 or 50 "innings" relate to a few "knots". Are they like some sort of weird imperial measures? (furlongs vs fathoms?)
  - jholman 8y ago
    I suspect that "knots" was supposed to be "noughts", a.k.a zeros. That is, the last few times the 100-point batsman was at bat, he got struck out without scoring any points. Is he washed up? I don't think it's a very useful analogy. :)
- ctack 8y ago
  Knots as in ducks?