[SoSoRoCoCo]

Intel innovates in process. Everything else is ruled by backwards compatibility and frenetic management scared to stay the course. (The vast majority of projects are killed if they don't tape out in ~2 years.)

Intel will shift to a TSMC model. They have the best fabs on the planet, and the best fab engineers. I believe it is something like a 3 millions dollars lost per minute if they are idle. They have already started doing that a few years ago, I suspect this will be their final form.

IMHO: The only thing holding them back from the transition are the hundreds of small boondoggle-groups staffed by old-timers too scared to retire, and too scared to do something daring, yet still somehow hang on to their hidey-holes. They lost a ton of key architects to Apple a few years ago, which I also suspect was the reason why the M1 is so badass.

...and if you really want to get sentimental, here's an AMD poster we had in our cubes back in ~1991:

https://linustechtips.com/uploads/monthly_2016_03/Szg2Ppo.jp...

The Sanders-as-Indiana was both funny and infuriating....

(The Farrah Fawcett looking woman was Sander's bombshell wife, compared to Grove at the time, who drove a beat up old car.)

[supernova87a]

>I believe it is something like a 3 millions dollars lost per minute if they are idle.

I think that's overestimating, although you are right it is damn expensive.

Order of magnitude I would say it's more like: Fab has lifetime of 2-3(?) years, and costs $10B to build and amortize. So every minute of idled factory capital = $6,000 in pure cost of the facility.

(although, if you think of it in potential lost revenue terms, then you may be more correct.)

(Actually we can also do that arithmetic, according to https://www.forbes.com/sites/willyshih/2020/05/15/tsmcs-anno...

240,000 wafers per year * 500 chips per wafer * $100? = $12B per year revenue. Also is something like $22k per minute)

[chrisseaton]

> Fab has lifetime of 2-3(?) years

Many Intel fabs are from the early 2000s. Some are from the 90s. What do you mean 2-3 years?

https://en.m.wikipedia.org/wiki/List_of_Intel_manufacturing_...

[monocasa]

I think they're referring to each line as a new fab, rather than the complex of buildings they're in, which is pretty fair.

[ardy42]

>>> Fab has lifetime of 2-3(?) years

>> Many Intel fabs are from the early 2000s. Some are from the 90s. What do you mean 2-3 years?

> I think they're referring to each line as a new fab, rather than the complex of buildings they're in, which is pretty fair.

Even so, wouldn't the 2-3 year number only apply to CPUs? Couldn't they keep the lines running making things that don't require top of the line processes, like USB controllers, etc.

[monocasa]

Yes, for chips that need leading edge density like CPUs.

Of course the lines stay open after that for cases you've laid out, but there's a lot of financial reasons why that needs to be basically gravy train money at that point with the lines being fully amortized and having paid for themselves many times over.

[supernova87a]

For those retired lines, don't they sell them off to lower tier manufacturers pretty quickly? Say, within 5 years?

I am no expert but I didn't think the site would be just accumulating its n-1, n-2 generation lines to produce lower grade stuff in the same fab walls. They take up space that they want to continue producing top of line latest output. I thought.

[supernova87a]

That's correct. A reasonable way to think of it is to calculate the cost of the thing that you're replacing every couple years, and the output it produces in that time. So the CPU producing line at <x>nm process, or whatever unit you choose. The building or site itself ("the fab") isn't the important thing.

[systemvoltage]

3 million dollars might be the cost of one FOSB (carries some 18-24 wafers) if you dropped it :)

[mhh__]

> Intel will shift to a TSMC model.

I think fabbing for outsiders would probably be a good idea, but splitting the fabs out from the designers seems like a bad idea.

[SoSoRoCoCo]

Yeah, agreed. The designers / integration will probably get the newest nodes--and the headaches with getting their yields up! I suspect the older high-yield nodes will be filled with tenants pretty quickly. I don't have much knowledge of how this is going, at least from the inside.

[ChrisIsTaken]

"Higher yield nodes" are full, that's why Intel is outsourcing to TSMC. Intel has already sold every 14nm, 22nm, 32nm and 45nm wafer it can make. They have zero capacity, which is an amazing problem for a "dying" company to have.

Even if they axed all process R&D and returned the cash to shareholders, due to the eye watering costs of designing at 10nm and lower I expect there will be a lot of business to keep their fabs turning over for the next decade.

[mlyle]

Intel has fabbed for (larger) outsiders for a few years (2014):

https://www.intel.com/content/www/us/en/foundry/overview.htm...

In late 2018, it was rumored they were exiting the business because of low uptake and because of constrained supply of their leading edge process, but it doesn't look like that happened.

[userbinator]

Everything else is ruled by backwards compatibility

That's one of the biggest reasons to choose them. If Intel's "x86" stops being x86, they'll lose one of their biggest competitive advantages.

See the first comment here, for example: http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

[SoSoRoCoCo]

This question has raged since the 90's. I worked on the Itanium (Madison and McKinley), and the VLIW architecture was brilliant. This was during the time of the Power4 and the DEC ALPHA, two non-x86 competing architectures that were dominating the "Workstation" market (remember that term?). It looked like the server world was going to have three architectural options (Sun was dying, and Motorola's 68000 line wasn't up to the task.)

Microsoft even had a version of NT3.5 for The Itanic. It seemed we were just about to achieve critical mass in the server world to switch to a new architecture with huge address space, ECC up the wazoo and massive integer performance.

Then the PC revolution took off with Win95, and the second war with AMD happened (and NexGen sorta). This couldn't be solved with legal battles. This put all hands on deck because there was SO much money to be made with x86 compatibility. The presence of x86 "up and down" AMD & Intel's roadmap took over the server market as well: it was x86 all over the place.

And that, chil'ren, is why x86 was reborn in the 90's just as it was close to being wiped out.

Now Apple has proven you can you seamless sneak in a brand-new architecture, get hyooj gainz, and we are none the wiser. This is fantastic news. I think we are truly on the cusp of x86 losing its dominance in the consumer space after almost 35 years of dominance.

[gautamcgoel]

> The Itanic

Lmao, never heard that one before

[fvv]

Thanks for your comment

[Ericson2314]

Yes but loosing that security blanket will make them better.

[fomine3]

Not much, as you can see on Zen3.

[Ericson2314]

Well, I think it gets worse before it's gets better. It's a very bitter pill to have to swallow.

[yjftsjthsd-h]

In fairness, Intel probably has enough people left who remember Itanium and are scared of trying big new innovation for an honestly legitimate reason.

[api]

Lately I've started to wonder if Itanium wasn't a good idea badly executed. I wonder if you went back in time and invested more in compilers and ecosystem if it could have succeeded? VLIW could really reduce complexity by dumping a lot of instruction re-ordering stuff and eliminating the need for tons of baroque vector instructions for specific purposes.

The biggest thing Intel didn't do with Itanium was release affordable AT/ATX form factor boards. They priced it way, way too high, chasing early margins in "enterprise" without realizing that market share is everything in CPUs. This is the same mistake that Sun, DEC, and HP made with their server/workstation CPUs in the previous era. With a new architecture you've got to push hard for market share, wide support, and scale.

If I'd been in charge I would have priced the first iterations of Itanium only a little above fab cost and invested a lot more in compiler support and software.

Edit: also whatever happened to the Mill? The idea sounded tenable but I have to admit that I am not a CPU engineer so my armchair take is dubious.

Anyway the ship has sailed. Later research in out of order execution has yielded at least similar performance gains and post-X86 the momentum is behind ARM and RISC-V.

[jsmith45]

I'm not sure that pushing the complexity to the compiler makes as much sense.

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.

[mark-r]

I thought the majority of their current problems stemmed from having lost the lead in fabs. You can't have the best chips if you don't have the best fab tech.

[mc32]

I mean their Sunnyvale HQ was a kind of mini mimic of the Whitehouse (at least to me, if you use your imagination a tad) --except for the garish storm fences that surrounded it.