Intel is dying and we can’t save it

1. https://www.reuters.com/article/us-intel-manufacturing/intel...

2. https://www.wsj.com/articles/trump-and-chip-makers-including...

Not that they’re entirely without merit; Intel faces challenges that, left resolved, will spell the end of the company. Just like any other firm that ignores problems.

Most of these arguments, especially the ones of “what are they going to do about AMD?” seem short-sighted. Intel has been here plenty of times before, facing down strong AMD competition only to come back and crush them a few product cycles later. Jim Keller can only come around so often. No, AMD’s issue is that they can never hold onto that lead through enough product cycles to really make a lasting dent in market share. It’s especially unfortunate for AMD right now, as supply constraints are choking what is its best performing product in years. Can’t really claw back a ton of market share when no one can get your chips.

It’s asked by the tech tubers and other observers why Intel continues to ship old Skylake variants. Process issues with 10nm are a factor here. But I suspect there’s a big one that no one’s really discussing.

And that’s the fallout from Spectre and Meltdown.

Keep in mind that the exploits in these flaws were found in products that were 10 years back at the time they were discovered. Each new chip isn’t a ground up design, but iterations on designs that stretch back years. I suspect, that the reason we haven’t seen truly new designs in over several product cycles is that Intel is having to redo large parts of their architecture that would have otherwise been carried forward in a normal setting. Gamers and enthusiasts may not have seen much of an impact to their apps as a result of these; none of the microcode updates results in big FPS drops in any games that I am aware of. But there were notable enterprise workloads that did. It’s often overlooked that the consumer marketplace is just one part of the larger IT ecosystem, so a redesign there is a must.

The timing of this is horrible of course, as it comes right when their new process is failing. So double-whammy there. Fortunately, or unfortunately, worldwide lack of fab capacity I think is preventing their rivals from exploiting this as much as they could. As for RISC, I think that is an entirely different threat, and to me, far more threatening and plausible. Intel saw this and tried to get into mobile chips, But I feel x86 is intrinsically at a disadvantage there.

I’m interested to see where Intel will be at once they have a new design ready to go. We’ve been here before. Pentium 4 ended up scaling far better than the Athlon XP did, and Core 2 and Nehalem utterly crushed AMD’s offerings when they were launched after a few years of AMD on top. There’s good reason to believe they can do so again, and a big reason why we haven’t seen an attempt is because they’re continuing to undo their mistakes of the past. We’ll have to see if they can.

My two cents.

(Disclaimer: Not a fanboy, I’m writing this on my AMD 3700X. =P )

One good side of x86 style instruction sets is that there is a lot you can do in the cpu to optimize existing programs more. While some really advanced compiler optimizations may make some use of the internal details of the implementation to choose what sequence to output, these details are not part of the ISA, and thus you can change them without breaking backwards compatibility. Changing them could slow down certain code optimized with those details in mind, but the code will still function. And I'm not even talking just about things like out of order execution. Some ISA's leak enough details that just moving from multi-cycle in-order execution to pipelined execution was awkward.

This ability of the implementation to abstract away from the ISA is very handy. And some RISC processors that exposed implementation details like branch-delay slots ended up learning this lesson the hard way. Now the Itanium ISA does largely avoid leaking the implementation details like number of scalar execution units or similar, but it's design does make certain kinds of potential chip-side optimizations more complicated.

In the Itanium ISA the compiler can specify groups of instructions that can run in parallel, specify speculative and advanced loads, and set up loop pipelining. But this is still more limited than what x86 cores can do behind the scenes. For an Itanium style design, adding new types of optimizations generally requires new instructions and teaching the compilers how to use them, since many potential optimizations could only be added to the chip if you add back the very circuitry that you were trying to remove by placing the burden on the compiler.

Even some of the types of optimizations Itanium compilers can do that mimic optimizations x86 processors do behind the scenes can result in needing to write additional code, reducing the effectiveness of the instruction cache. This is not surprising. The benefits of static scheduling are that you pre-compute things that are possible to pre-compute like which instructions can run in parallel, and where you can speculate etc. And thus you don't need to compute that stuff on-die, and don't need to compute it each and every time you run a code fragment. But obviously that information still needs to make it to the CPU, so you are trading that runtime computation for additional instruction storage cost. (I won't deny that the result could still end up more I-cache efficient than x86 is, because x86 is not by any means the most efficient instruction encoding, especially since some rarely used anymore opcodes hog some prime encoding real-estate.)

Basically I'm not sold on static scheduling for high performance but general purpose CPUs, and am especially not sold on the sort of peudo-static scheduling used by Itanium where you are scheduling for instructions with unknown latency, that can differ from model to model. The complete static scheduling where you must target the exact CPU you will run on, and thus know all the timings (like the Mill promised) feels better to me. (But I'm not entirely sure about install type specialization like they mention.)

But I'm also no expert on CPU design, a hobbyist at best.