Intel needs to step up their game if they want to stay relevant. I am sure their execs know it so I can't wait to see what they will offer in the next 5 years.
They've been carefully dropping hints of this since July. Through the first week of November the headlines were "Intel to decide soon" whether to outsource, with a decision supposedly appearing sometime in January. This looks like the sort of precision expectation setting one would expect of an experienced zombie corp CEO like Swan.
So don't bet on Intel making any great comeback in fab tech; they've decided they can be 'relevant' without it.
There are essentially 3 leading fabs left: TSMC, Samsung, Intel.
Samsung has yield issues, Intel has yield issues, TSMC somehow has no issues. GlobalFoundries has already dropped out of the race. TSMC is selling every wafer they make, and continues to invest heavily to solidify it's lead.
ALL of these fabs depend on ASML machines. IIRC last year they delivered just over half of the machines that were ordered.
https://www.reuters.com/article/asml-deliveries-idUSL8N1Y817...
That would not surprise me at all. I was hired on contract once to help a system (not ICs) that was having issues and my work was directly obstructed (a coworker said sabotaged) by the guy (foreign) who designed one subsystem. At the time I though maybe it was his ego not liking that his boss brought me in to help and I was succeeding. When it became clear from multiple incidents that he was subtly sabotaging me I started to wonder this very thing. I showed evidence to our boss who said "my hands are tied" because of the corporate structure at the time. My work did make it into production and I moved on for other reasons.
But if you'll allow your question to be answered with pure rumortown and supposition:
Intel has engrained management issues that don't allow for reorganizing to systemically address their 10nm and under process issues as the little fiefdoms that control different parts of the process are spending more time throwing each other under the bus rather than collaborating.
Samsung isn't far off from TSMC (about a single node). They fell a little behind as TSMC grabbed a bunch of their contracts (most notably Apple) which left them with not as much to capital to invest in their newer process nodes at a rather critical point. At a bare minimum they'll be kept alive by TSMC's customers as a viable second source (if you squint hard enough) as a negotiating tactic (see Nvidia's 30 series on Samsung as a shot across TSMC's bow).
GloFlo canceled 7nm and under R&D. I wouldn't be surprised if they bounce back at some point when all of the EUV gotcha workarounds are more or less public knowledge and the equipment doesn't have prices on the order of a small country's GDP. If we hit fundamental limits at ~1nm and Moore's law really dies, then they should be able to jump back in with relatively less work than a newcomer and be the budget option once leading edge chips become a commodity.
They can probably still hammer AMD on both their software and documentation, i.e. roughly a quarter of their sales are to data centres.
It will be interesting to see what happens to X86 post-M1 (i.e. ARM coming of age), I suspect not much but I think the world has changed enough to have another stab at VLIW (for example) even if the cost/benefit is pretty marginal.
I have a beast i7 gaming rig too and my M1 beats it at everything but graphics performance.
What I think Intel will continue to work their enterprise business until this “arm wave” starts to pull up. Engineers at Intel probably have some ideas.
If a company other than apple makes a fast arm chip that'd be very interesting, though. Nvidia have probably thought about it.
This reminds me of when RIM got their hands on an iPhone for the first time.
One of many articles: https://appleinsider.com/articles/10/12/27/rim_thought_apple...
Also apple built in some special instructions that makes macOS software better, like core operations of objective-c, so some of this might be very apple runtime specific optimizations.
They probably just didn’t realize that one day of battery life is enough for most use cases and is less important than a real browser and the other features brought by the iPhone.
1) the display on the iphone was gigantic compared to any other device on the market. The fact the iPhone had the battery life it did was amazing.
2) the software on the iphone destroyed anything RIM had ever put forward.
3) the iPhone was a much better piece of hardware aesthetically and performance-wise than anything RIM had ever put out. Their closest competitor was the Pearl and it was garbage compared to the iPhone.
4) Lastly, RIM had 10 year development cycles. Pivoting to attack the iPhone meant ripping apart 10 years of planned development much of which was already executed. Pivoting that hard is just not something companies at the scale or RIM are designed to do.
RIM should've seen the writing on the wall, shred their hardware business, and gone all in on supporting BES on iPhone. I digress...
Did they even have a way for third parties to make apps? Even though the iPhone originally didn’t have that the jailbreak community pretty quickly showed that was the way forward.
Static compile time VLIW means one cannot really make it wider anymore, or narrower. Dynamically doing it on runtime means a cheaper and smaller core can just be narrower. Remove an instruction slot for one integer ALU? Fine, no issues. Everything still works, albeit slower by that much. Make a beefier chip? Perfect, it got faster by the amount of instruction level parallelism that was available.
In addition a compiler cannot really see across function boundaries (except if it's statically determinable). A jitter can. Modern chips have reordering window of hundreds of instructions, M1 apparently goes up to over 600. That's quite a lot of stuff there that it can dynamically reorder across. A compiler might not have noticed that due to some weird dynamic call that was not visible during compilation time there is now an FPU instruction that could be inserted here, an OoO processor can.
Due to that explicit VLIW is basically dead outside of some highly specific applications, like DPS and whatnot.
In a similar fashion ridculously wide vector units were obsoleted by the approach pioneered by GPU's. Just add few things to allow masking based on branches and you get SIMT approach. Write as if it was scalar code and it'll run on HW that has vector lengths going from none at all up to whatever, NVidia has 32 wide vector units as an example.
I believe this is the real thing that make superscalar OoO (ie. JIT to VLIW in silicon) win.
I consider it to be roughly as important as being able to reorder instructions across non statically determined branches and function calls. And both of these expose the fundamental weakness in explicit VLIW, if it's essentially nondeterministic it cannot be taken advantage of.
Then we naturally have some other benefits, like hyperthreading. Which basically is just compiling two instruction streams together on the fly.
For it to work statically (although it really could be halfway in between), it would probably require a complete paradigm shift away from the current way we think about cpu caches
Regardless of whether it'll work or not, I'll be very happy if the mill ever makes it onto a chip.
Got really confused at first.
From a single thread performance standpoint, the important part is that OoO scheduling is able to dynamically schedule around cache misses to effectively keep more memory accesses in flight, extract more memory level parallelism. In principle you could make an OoO VLIW CPU, but that would negate most of the power benefit while hamstringing the scheduler with unnecessary dependencies. Where in-order VLIW shines is when memory accesses are predictable, like DSP code. There you get an order of magnitude power efficiency gain.
GPUs are effectively still in-order CPUs with large SIMD instructions, some useful instructions to make masked execution simpler and a specialized language and compiler to hide this model from the developers. GPU manufacturers calling these separate data lanes threads is just misleading marketing BS. There is no independent instruction pointer for each lane.
I do not disagree that VLIW is a great for things like DSP where the power consumption is of the essence. One can get ridiculously high perf/watt by going explicit VLIW. I just don't see any way we'd see that approach in general purpose CPU's again.
GPU's do not need to reorder instructions to hide memory latency. It just happens on a different level. While a single threadgroup (as in that single instruction pointer that controls the SIMD unit) will not get reordered at all, one has multiple threadgroups in flight. So if one group stalls at a memory load the unit will just schedule a different threadgroup. Because one generally has tons of them in flight. It's all about throughput. One could think of this as an in order CPU (from viewpoint of a single thread) but with ridiculous amounts of hyperthreading (one thread stalls, we can pick an instruction from another thread but never one from the stalled thread).
I can’t for the life of me figure out why Intel hasn’t already hedged their bets and started working hard on hybrid chips. Especially since this now appears to be a long term industry direction. If the next step blunts the consequences of your current problems, why not jump on it?
Sunk cost fallacy?
[0] https://www.intel.com/content/www/us/en/foundry/emib.html [1] https://en.wikichip.org/wiki/intel/core_i7/i7-8809g [2] https://www.anandtech.com/show/16021/intel-moving-to-chiplet...
Would they be competitive? Or are apple so much further ahead on other things too?