8 ms·

So Intel and AMD are capable of building a chip like this, but the ambitious size meant it was more economically feasible for Apple to build it themselves? (No

by natchy 6y ago

So Intel and AMD are capable of building a chip like this, but the ambitious size meant it was more economically feasible for Apple to build it themselves? (Not a hardware guy)

ArchOversight 6y ago
Read the article linked, it explains why Intel and AMD are unable to throw more decoders at the problem.
outworlder 6y ago
Maybe they are, assuming there's sufficient area in the die for this. They would likely still be massive power hogs.
masklinn 6y ago
It's not that it was more economical, but that at least some of these AMD and Intel would not benefit from due to the ISA: x64 instructions can be up to 15 bytes, so just finding 8 instructions to decode would be costly, and I assume Intel and AMD think more so than the gains from more decoders (you couldn't keep them fed enough to be worth it, basically).
- SlipperySlope 6y ago
  When ARM migrated to 64 bits, wisely they left the 32 bit instructions behind. So easy to decode and uniform instruction length. On the other hand, AMD64 can run 8088 16 bit instructions, which means that it must handle a variety of instruction lengths.
lmilcin 6y ago
Neither Intel nor AMD are capable of doing for a very basic reason, there is no market for it. You can't just release a CPU for which there is no operating system. Apple can pull it off because they already own entire stack from hardware to operating system to cloud services and the can swap out a component like CPU for a different architecture and release new version of OS that supports it. Apple, by creating new CPU, replace a part of the stack that is owned by Intel by their own which only strengthens them position even if it did not improve any performance. Apple is invulnerable to other companies copying the CPU and creating their own because they are not really a competition here. Apple sells an integrated product of which CPU is just one component.
- throwaway_pdp09 6y ago
  > You can't just release a CPU for which there is no operating system sure you can. That's what compilers are for.
  - loeg 6y ago
    GP probably means that you won't be able to sell it, even if there is a compiler. (Not true in the super embedded space, sure.)
  - skavi 6y ago
    Intel had such an attitude once before.
    - throwaway_pdp09 6y ago
      Donald Knuth said "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."[82] https://en.wikipedia.org/wiki/Itanic https://en.wikipedia.org/wiki/Itanic So they didn't have the needed compiler
      - pjmlp 6y ago
        I wonder how HP and Microsoft managed to port HP-UX and Windows without a compiler.
        Dylan16807 6y ago
        That's kind of the point. Compilers existed just fine to do the porting, and solved that problem. Intel's failure is that they were unable to solve a different problem because that compiler didn't exist, one that went well beyond merely porting. In other words, "That's what compilers are for." is a perfectly fine attitude when those compilers exist, and a bad attitude when they don't exist. Porting is the former, making VLIW efficient is the latter.
      - 6y ago
skavi 6y ago
Not necessarily. Samsung used to make custom cores that were just as large if not larger than Apple’s (amusingly the first of these was called M1). Unfortunately, Samsung’s cores always performed worse and used significantly more power than the contemporary Apple cores. Apple’s chip team has proven capable of making the most of their transistor budget, and there’s reason to believe neither Intel nor AMD could achieve Apple’s efficiency even if they had the same process, ISA, and area to work with.
- The_Colonel 6y ago
  > and there’s reason to believe neither Intel nor AMD could achieve Apple’s efficiency even if they had the same process, ISA, and area to work with. What's that reason?
  - Accujack 6y ago
    I think it's "faith".
    - yazaddaruvala 6y ago
      Faith implies no data. Why will Apple always out compete Intel and other non-vertically-integrated systems? Margins, future potential, customer relationship and compounding growth/virtuous cycle. The margins logic is simple, iPhones and MacBooks make tons more money per unit compared with a CPU. Imagine if improving the performance of a CPU by 15% makes the demand increase by 1%. For Apple improving the performance of a CPU by 15% makes the demand increase by 1% for the whole iPhone or MacBook. For this reason alone, Apple can invest 2-5x more R&D into their chips than everyone else. The future potential logic is more nuanced: 1. Intel's/whoever's 10 year vision is to build a better CPU/GPU/RAM/Screen/Camera because their customers are the companies buying CPUs/GPUs/Screens/Cameras/RAM. They are focused on the metrics the market has previously used to measure success and want to build to optimize for those metrics e.g. performance per dollar. Intel doesn't pay for the electricity in the datacenter nor through its customers' complaints about battery life. RAM manufacturers aren't looking at Apple's products and asking, "do consumers even replace still RAM?" i.e. they are focused on "micro"-trends. 2. Apple's vision is to build the best product for customers. They look at "macro"-trends into the future and apply their personal preferences at scale. For example, do people even still need replaceable RAM? Will they want 5G in the future, or can we improve the technology to replace it with direct connections to a LEO satellite cluster? The customer relationship logic: Lets take one such example of a macro-trend, VR and other wearables. Apple is tracking these trends and can "bet on" them because its in full control but Nvidia, Intel, etc typically don't want to "bet on" these numbers because even if they are fully invested, their partners (which sell to consumers) might back out. Apple also isn't "betting on" because it has a healthy group of early adopters that trust Apple and will buy and try it even tho a "better" product in the same market segment isn't purchased. Creating/retaining that customer relationship lets Apple over invest into keeping heat (i.e. power) low because its thinking about the whole market segment that Apple's VR headset can start to compete in and collect more revenue from. Compounding growth/virtuous cycle logic is also relatively simple: Improving the metrics in any of these 3 previous pillars manipulatively improves the other pillars. i.e. better customer relationship increases cashflow, increseses R&D funding, 1. improves product, improving customer relationship; or 2. reduces costs, increasing margins, and loops back to increasing cash flow.
amluto 6y ago
x86 instructions are variable length with byte granularity, and the length isn’t known until you’ve mostly decoded an instruction. So, to decode 4 instructions in parallel, AIUI you end up simultaneously decoding at maybe 20 byte offsets and then discarding all the offsets that turn out to be in the middle of an instruction. So the Intel and AMD decoders may well be bigger and more power hungry than Apple’s.
WhyNotHugo 6y ago
The problem is the market. Windows only a single architecture, so they can't really deviate from that. Sure, windows can switch (or, apparently, run on ARM), but due to the fact that windows applications are generally distributed as binaries, lots of apps wouldn't work. Linux users would have far less issues, and would be a great clientele for a chip like this, but probably too niche a market, sadly.
- kjs3 6y ago
  Windows only a single architecture People forget that at launch Windows NT ran on MIPS & DEC Alpha in addition to x86. The binary app issue was a killer for the alternative archs.
  - monocasa 6y ago
    DEC Alpha NT could run X86 code thanks to FX!32, and faster than a core you could buy from Intel at the time.
    - pjmlp 6y ago
      Indeed, but it didn't had anything that justified actually paying big bucks for an Alpha.
    - foobiekr 6y ago
      well, for some things. fx32 for the apps people wanted though was deficient. The NT3.1-era Alphas didn't have byte-level performance so things like Excel, Word, etc. all ran terribly, as did Emacs and X. I supported a lab of Alphas running Ultrix and they were dogs for anything interactive and fantastic for anything that was a floating point application.
      - kjs3 6y ago
        Yeah...anyone who thinks fx32 was faster in the real world than a native Intel core never actually ran it.
  - 6y ago
redraga 6y ago
I can't comment on the economics of it but I can comment on the technical difficulties. The issue for x86 cores is keeping the ROB fed with instructions - no point in building a huge OoO if you can't keep it fed with instructions. Keeping the ROB full falls on the engineering of the front-end, and here is where CISC v RISC plays a role. The variable length of x86 has implications beyond decode. The BTB design becomes simpler with a RISC ISA since a branch can only lie in certain chunks in a fetched instruction cache line in a RISC design (not so in CISC). RISC also makes other aspects of BPU design simpler - but I digress. Bottom line, Intel and AMD might not have a large ROB due to inherent differences in the front-end which prevent larger size ROBs from being fed with instructions. (Note that CISC definitely does have it's advantages - especially in large code foot-print server workloads where the dense packing of instructions help - but it might be hindered in typical desktop workloads) Source: I've worked in front-end CPU micro-architecture research for ~5 years
- hajile 6y ago
  How do you feel about RISC-V compact instructions? The resulting code seems to be 10-15% smaller than x86 in practice (25-30% smaller than aarch64) while not requiring the weirdness and mode-switching associated with thumb or MIPS16e. Has there actually been much research into increasing instruction density without significantly complicating decode? Given the move toward wide decoders, has there been any work on the idea of using fixed-size instruction blocks and huffman encoding?
  - redraga 6y ago
    I can't really comment on the tradeoffs between specific ISAs since I've mainly worked on micro-arch research (which is ISA agnostic for most of the pipeline). As for the questions on research into looking at decode complexity v instruction density tradeoff - I'm not aware of any recent work but you've got me excited to go dig up some papers now. I suspect any work done would be fairly old - back in the days when ISA research was active. Similar to compiler front-end work (think lex, yacc, grammar etc..) ISA research is not an active area currently. But maybe it's time to revisit it? Also, I'm not sure if Huffman encoding is applicable to a fixed-size ISA. Wouldn't it be applicable only in a variable size ISA where you devote smaller size encoding to more frequent instructions?

by natchy 6y ago

So Intel and AMD are capable of building a chip like this, but the ambitious size meant it was more economically feasible for Apple to build it themselves? (Not a hardware guy)

ArchOversight 6y ago

Read the article linked, it explains why Intel and AMD are unable to throw more decoders at the problem.

outworlder 6y ago

Maybe they are, assuming there's sufficient area in the die for this. They would likely still be massive power hogs.

masklinn 6y ago

It's not that it was more economical, but that at least some of these AMD and Intel would not benefit from due to the ISA: x64 instructions can be up to 15 bytes, so just finding 8 instructions to decode would be costly, and I assume Intel and AMD think more so than the gains from more decoders (you couldn't keep them fed enough to be worth it, basically).

SlipperySlope 6y ago
When ARM migrated to 64 bits, wisely they left the 32 bit instructions behind. So easy to decode and uniform instruction length. On the other hand, AMD64 can run 8088 16 bit instructions, which means that it must handle a variety of instruction lengths.

lmilcin 6y ago

Neither Intel nor AMD are capable of doing for a very basic reason, there is no market for it. You can't just release a CPU for which there is no operating system. Apple can pull it off because they already own entire stack from hardware to operating system to cloud services and the can swap out a component like CPU for a different architecture and release new version of OS that supports it. Apple, by creating new CPU, replace a part of the stack that is owned by Intel by their own which only strengthens them position even if it did not improve any performance. Apple is invulnerable to other companies copying the CPU and creating their own because they are not really a competition here. Apple sells an integrated product of which CPU is just one component.

throwaway_pdp09 6y ago
> You can't just release a CPU for which there is no operating system sure you can. That's what compilers are for.
- loeg 6y ago
  GP probably means that you won't be able to sell it, even if there is a compiler. (Not true in the super embedded space, sure.)
- skavi 6y ago
  Intel had such an attitude once before.
  - throwaway_pdp09 6y ago
    Donald Knuth said "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."[82] https://en.wikipedia.org/wiki/Itanic https://en.wikipedia.org/wiki/Itanic So they didn't have the needed compiler
    - pjmlp 6y ago
      I wonder how HP and Microsoft managed to port HP-UX and Windows without a compiler.
      - Dylan16807 6y ago
        That's kind of the point. Compilers existed just fine to do the porting, and solved that problem. Intel's failure is that they were unable to solve a different problem because that compiler didn't exist, one that went well beyond merely porting. In other words, "That's what compilers are for." is a perfectly fine attitude when those compilers exist, and a bad attitude when they don't exist. Porting is the former, making VLIW efficient is the latter.
    - 6y ago

skavi 6y ago

Not necessarily. Samsung used to make custom cores that were just as large if not larger than Apple’s (amusingly the first of these was called M1). Unfortunately, Samsung’s cores always performed worse and used significantly more power than the contemporary Apple cores. Apple’s chip team has proven capable of making the most of their transistor budget, and there’s reason to believe neither Intel nor AMD could achieve Apple’s efficiency even if they had the same process, ISA, and area to work with.

The_Colonel 6y ago
> and there’s reason to believe neither Intel nor AMD could achieve Apple’s efficiency even if they had the same process, ISA, and area to work with. What's that reason?
- Accujack 6y ago
  I think it's "faith".
  - yazaddaruvala 6y ago
    Faith implies no data. Why will Apple always out compete Intel and other non-vertically-integrated systems? Margins, future potential, customer relationship and compounding growth/virtuous cycle. The margins logic is simple, iPhones and MacBooks make tons more money per unit compared with a CPU. Imagine if improving the performance of a CPU by 15% makes the demand increase by 1%. For Apple improving the performance of a CPU by 15% makes the demand increase by 1% for the whole iPhone or MacBook. For this reason alone, Apple can invest 2-5x more R&D into their chips than everyone else. The future potential logic is more nuanced: 1. Intel's/whoever's 10 year vision is to build a better CPU/GPU/RAM/Screen/Camera because their customers are the companies buying CPUs/GPUs/Screens/Cameras/RAM. They are focused on the metrics the market has previously used to measure success and want to build to optimize for those metrics e.g. performance per dollar. Intel doesn't pay for the electricity in the datacenter nor through its customers' complaints about battery life. RAM manufacturers aren't looking at Apple's products and asking, "do consumers even replace still RAM?" i.e. they are focused on "micro"-trends. 2. Apple's vision is to build the best product for customers. They look at "macro"-trends into the future and apply their personal preferences at scale. For example, do people even still need replaceable RAM? Will they want 5G in the future, or can we improve the technology to replace it with direct connections to a LEO satellite cluster? The customer relationship logic: Lets take one such example of a macro-trend, VR and other wearables. Apple is tracking these trends and can "bet on" them because its in full control but Nvidia, Intel, etc typically don't want to "bet on" these numbers because even if they are fully invested, their partners (which sell to consumers) might back out. Apple also isn't "betting on" because it has a healthy group of early adopters that trust Apple and will buy and try it even tho a "better" product in the same market segment isn't purchased. Creating/retaining that customer relationship lets Apple over invest into keeping heat (i.e. power) low because its thinking about the whole market segment that Apple's VR headset can start to compete in and collect more revenue from. Compounding growth/virtuous cycle logic is also relatively simple: Improving the metrics in any of these 3 previous pillars manipulatively improves the other pillars. i.e. better customer relationship increases cashflow, increseses R&D funding, 1. improves product, improving customer relationship; or 2. reduces costs, increasing margins, and loops back to increasing cash flow.

amluto 6y ago

x86 instructions are variable length with byte granularity, and the length isn’t known until you’ve mostly decoded an instruction. So, to decode 4 instructions in parallel, AIUI you end up simultaneously decoding at maybe 20 byte offsets and then discarding all the offsets that turn out to be in the middle of an instruction. So the Intel and AMD decoders may well be bigger and more power hungry than Apple’s.

WhyNotHugo 6y ago

The problem is the market. Windows only a single architecture, so they can't really deviate from that. Sure, windows can switch (or, apparently, run on ARM), but due to the fact that windows applications are generally distributed as binaries, lots of apps wouldn't work. Linux users would have far less issues, and would be a great clientele for a chip like this, but probably too niche a market, sadly.

kjs3 6y ago
Windows only a single architecture People forget that at launch Windows NT ran on MIPS & DEC Alpha in addition to x86. The binary app issue was a killer for the alternative archs.
- monocasa 6y ago
  DEC Alpha NT could run X86 code thanks to FX!32, and faster than a core you could buy from Intel at the time.
  - pjmlp 6y ago
    Indeed, but it didn't had anything that justified actually paying big bucks for an Alpha.
  - foobiekr 6y ago
    well, for some things. fx32 for the apps people wanted though was deficient. The NT3.1-era Alphas didn't have byte-level performance so things like Excel, Word, etc. all ran terribly, as did Emacs and X. I supported a lab of Alphas running Ultrix and they were dogs for anything interactive and fantastic for anything that was a floating point application.
    - kjs3 6y ago
      Yeah...anyone who thinks fx32 was faster in the real world than a native Intel core never actually ran it.
- 6y ago

redraga 6y ago

I can't comment on the economics of it but I can comment on the technical difficulties. The issue for x86 cores is keeping the ROB fed with instructions - no point in building a huge OoO if you can't keep it fed with instructions. Keeping the ROB full falls on the engineering of the front-end, and here is where CISC v RISC plays a role. The variable length of x86 has implications beyond decode. The BTB design becomes simpler with a RISC ISA since a branch can only lie in certain chunks in a fetched instruction cache line in a RISC design (not so in CISC). RISC also makes other aspects of BPU design simpler - but I digress. Bottom line, Intel and AMD might not have a large ROB due to inherent differences in the front-end which prevent larger size ROBs from being fed with instructions. (Note that CISC definitely does have it's advantages - especially in large code foot-print server workloads where the dense packing of instructions help - but it might be hindered in typical desktop workloads) Source: I've worked in front-end CPU micro-architecture research for ~5 years

hajile 6y ago
How do you feel about RISC-V compact instructions? The resulting code seems to be 10-15% smaller than x86 in practice (25-30% smaller than aarch64) while not requiring the weirdness and mode-switching associated with thumb or MIPS16e. Has there actually been much research into increasing instruction density without significantly complicating decode? Given the move toward wide decoders, has there been any work on the idea of using fixed-size instruction blocks and huffman encoding?
- redraga 6y ago
  I can't really comment on the tradeoffs between specific ISAs since I've mainly worked on micro-arch research (which is ISA agnostic for most of the pipeline). As for the questions on research into looking at decode complexity v instruction density tradeoff - I'm not aware of any recent work but you've got me excited to go dig up some papers now. I suspect any work done would be fairly old - back in the days when ISA research was active. Similar to compiler front-end work (think lex, yacc, grammar etc..) ISA research is not an active area currently. But maybe it's time to revisit it? Also, I'm not sure if Huffman encoding is applicable to a fixed-size ISA. Wouldn't it be applicable only in a variable size ISA where you devote smaller size encoding to more frequent instructions?