Slashdot Mirror
Intel Fights For Its Future (mondaynote.com)
An anonymous reader shares a post: The Smartphone 2.0 era has destroyed many companies: Nokia, Blackberry, Palm... Will Intel be another victim, either as a result of the proposed Broadcom-Qualcomm combination, or as a consequence of a suicidal defense move? Intel sees the Qualcomm+Broadcom combination as an existential threat, an urgent one. But rather than going to the Feds to try and scuttle the deal through a long and uncertain process, Intel is rumored to be "working with advisors" (in plainer English, the company's Investment Bankers) on a countermove: acquire Broadcom. Why the sudden sense of urgency? What is the existential threat? And wouldn't the always risky move of combining two cultures, employees, and physical plants introduce an even greater peril?
To begin with, the threat to Intel's business isn't new; the company has been at risk for more than a decade. By declining Steve Jobs' proposal to make the original iPhone CPU in 2005, Intel missed a huge opportunity. The company's disbelief in Apple's ambitious forecast is belied by the numbers: More than 1.8 billion iOS devices have been sold thus far. Intel passed on the biggest product wave the industry has seen, bigger than the PC. Samsung and now TSMC manufacture iPhone CPUs. Just as important, there are billions of Android-powered machines, as well. One doesn't have to assume 100% share in the smartphone CPU market to see Intel's gigantic loss.
To begin with, the threat to Intel's business isn't new; the company has been at risk for more than a decade. By declining Steve Jobs' proposal to make the original iPhone CPU in 2005, Intel missed a huge opportunity. The company's disbelief in Apple's ambitious forecast is belied by the numbers: More than 1.8 billion iOS devices have been sold thus far. Intel passed on the biggest product wave the industry has seen, bigger than the PC. Samsung and now TSMC manufacture iPhone CPUs. Just as important, there are billions of Android-powered machines, as well. One doesn't have to assume 100% share in the smartphone CPU market to see Intel's gigantic loss.
That monopoly is ironically called the AMD64 architecture today. This comes with a number of problems. While Intel managed to keep AMD small after the last time AMD (not Intel, they did not have the skills) not only came up with the only viable 64 bit extension to the x86 architecture, for a while they also had the fastest CPUs. AMD engineering in the CPU space has basically always been significantly superior to Intel, except for raw speed. Meltdown and Spectre have now nicely illustrated what Intel did to get that speed. And AMDs weakness is over, with a brand-new architecture that is very well designed indeed while Intel has nothing. It helps to understand that Intel it not actually a CPU company, they are a memory company and have struggled with CPUs since they began making them. AMD, on the other hand, came from signal-processors to x86 and _is_ a CPU company. This nicely explains Intel's incompetence, incredible as it sounds. They do not have the right culture.
One other instance of that problem is also that while AMD can do extreme customization of their CPUs since the FX generation, Intel is completely incapable in this space. And just look how long it took Intel to get the memory controller into the CPU after AMD did it.
Now, Intel also did never manage to come up with anything x86 that was suitable for a smartphone. AMD did not even try, because they understand CPUs and knew this architecture is not suitable for that field. But they went one step farther: They have server processors that include ARM cores. So AMD has real experience in that field, but Intel is, again, lost. Yet AMD is far smaller and does not need the smartphone market to survive, while Intel likely does. And they messed it up.
My take is that finally Intel found out with much delay that they managed to screw themselves, in addition to their customers.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Seriously, Intel needs to get out of the mobile chipset game because they are pretty shit at it.
I have been in the mobile certification business for a long time. We do 10's of thousands of tests on protocol stack and hardware layers of modules integrating these chipsets. Intel based products are always a pain. Their support is crap too. Most say, ok.. never again with Intel. We will use Marvell or something. QC tends to be 4 or 5 times the price, so it often doesnt make sense for high volume, low cost stuff.
Anyhow.... they started way too late in this game and missed the boat.
I am thinking this might be planted news by Intel to justify their acquisition as otherwise it would be rejected as a major monopoly already fined for abusing their monopoly expanding its monopoly further.
For business, smart terminals, simply easier to manager
Thin client vs thick client has been a tick-tock ever since the first mainframes entered the business market.
Desktops are inevitably doomed but they can stretch out the next few decades
That's as close to living as we've ever had... Decades are an eternity in computing.
This is a real question. I don't have anything against Intel, and my current workstation has Intel Inside.
Does Intel have anything that plays well in the phone/tablet market? My understanding is that Qualcom and/or Samsung don't own the market just because they were there first, but because their products are designed specifically for the application, whereas Intel's offerings in that arena all appear to be relatively low power x86 chips. Key term being "relatively". Like Microsoft's early struggles with hand held devices, trying to shoehorn a desktop OS into something with a 4 inch screen, Intel appeared to be trying to leverage existing designs in a market where they weren't appropriate.
I could be missing something, but it seems like Intel's largest current issue is that they make the best possible processor for an increasingly smaller market, and don't make anything particularly appropriate for the most aggressively expanding markets. An issue they share to a certain extent with Microsoft.
It'll be interesting to see what happens should Intel acquire Broadcom. I think there's a good chance -- maybe 40% that after acquisition Intel will drop or severely de-emphasize Broadcom's SoC products in favor of one of their lower power laptop x86 processors. And fail miserably at it.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
I went though a short, thirty-year obsession with all things microarchitecture. The appalling stupidity of accepted memes in this space I'll surely carry to my lonely grave.
Crufty x86: here's how it broke down.
First, about 50% of the original cruft drank the shrink-me fluid, and shrank down so small you can barely see it now (e.g. some extra microcode entries in a rarely used, unpopular spiral annex of the instruction decode table for misbegotten 286-era CISC call gates.) Jesus, people, exponential happens.
Second, about 25% of the cruft turned out to not nearly be so crufty as legend would have it. The RISC camp soils itself over the read-modify-write instruction group. But generating a complex address once (yes, x86 does complex address generation within the context of a single instruction) rather than twice alleviates substantial pressure on the address look-aside unit. It's also a very handy and compact addressing mode for minor stack spill (e.g. function variables that don't quite manage to stay in registers all the time). With a 30% instruction encoding density advantage over the original ARM32, you need many fewer transistors in your i-cache to achieve the same i-cache hit ratio. The bigger your caches, the more free transistors to apply elsewhere. x86 is still a bit short on registers despite rmw, but you gain a bunch of this back on lighter context switches, so it's not a complete write-off.
The other 25% is an eternal pain in the ass. Here's how the PITA component breaks down. The majority of it has little impact on peak throughput at all, but it comes at a thermal efficiency cost. The thermal cost is mostly irrelevant if you are sucking juice from a wall socket, and your processor is not hitting the thermal wall. The other side of this is a hideous sunk-cost in the engineering trickery required to pull this off (for a company the size of Intel, however, hideous is mostly peanuts, and nice barrier to entry you've got there, shame if a different device category became prominent).
A minority of the PITA aspects of the instruction set are just permanently a PITA. Deep OOO requires extensive hazard detection, and x86 has hazards up the wazoo (many partial register writes, and seventeen different flavours of flag register update subsets). This costs silicon, this costs power, this costs cycle time, this costs pipeline stages. Lose, lose, lose.
Considering the architecture is now 40-years old, that's not exactly a resounding F on the old report card, by a sane grader.
Because of aspects like instruction decode alignment (with those blasted variable prefix bytes) and extremely complex hazard detection x86 is just always going to produce twice as much heat arriving at the same result 20% faster than any reasonable design that was originally power conscious.
I suspect most of this fixed thermal inefficiency resides in the front end and not the back end. Meaning that an alternative x86 instruction set could be devised (somewhat more drastically different than Thumb-2 vs. Thumb) with vastly more efficient instruction decode (thermally) and vastly fewer implicit scheduling hazards. Caches, register sets, dispatch pipelines, retirement unit, memory ports, execution units, these could all remain the same. Perhaps the only register you'd want to muck with is the flags register, and maybe you'd trash the ability to write to AH (though you'd probably keep partial register writes to AL to handle common byte operations).
[*] Fifteen years ago, the ugly details of this stuff was more in my head, so my examples predate AMD64, but mutatis mutandis.
Maybe by doing so you'd even close the gap enough to compete with ARM. But: a huge redevelopment and validation cost (what, me validate?), another substantially different code generation mode for every major compiler, another by