Live data from Hacker News

Intel Problems

stratechery.com

141–150 of 431 posts

Re: Intel Problems

#141

Earlier quoted context omitted.

Yeah and I assume we are going to see Graviton/Amazon linux based notebooks any day now.

Honestly, if Amazon spun this right and they came pre-setup for development and distribution and had all the right little specs (13 and 16 inch sizes, HiDPI matte displays, long battery life, solid keyboard, macbook-like trackpad) they could really hammer the backend dev market. Bonus points if they came with some sort of crazy assistance logic like each machine getting a pre-setup AWS Windows server for streaming wi…

> could really hammer the backend dev market

That's worth, what, a few thousand unit sales?

Re: Intel Problems

#142

Earlier quoted context omitted.

The problem here is not the success of AMD after splitting, but the complete retreat of Global Foundries from the SOTA process node. If this happens again with an Intel split then we have only TSMC left, off the coast of mainland China in Taiwan, in the middle of a game of thermonuclear tug of war between the West and China. While Capitalism will likely be part of the solution, through subsidizes for Intel or some ot…

Let's just hope that if Intel's position is protected because of its strategic importance in the tug of war, it doesn't become another Boeing.

This is a bizarre comparison. Boeing made an entire line of planes that could randomly dive into the ground, and insisted that there be no additional training required for the uptake of those planes. Intel, in contrast, was over-ambitious with 10nm and didn't wait a few more months to incorporate EUV into that process node. The government hasn't banned the use of Intel chips, but the 737 Max 8 was grounded for 20 months. While the pandemic slammed air travel, it has been a major tailwind for the PC and server markets alike.

Re: Intel Problems

#143

I think one day we’re going to wake up and discover that AWS mostly runs on Graviton (ARM) and not x86. And on that day intel’s troubles will go from future to present. My standing theory is that the m1 will accelerate it. Obviously all the wholly managed AWS services (Dynamo, Kinesis, S3, etc.) can change over silently, but the issue is EC2. I have a MBP, as do all of my engineers. Within a few years all of these ma…

Aren't most of us already programming against a virtual machine, such as Node, .NET or the JVM? I think the CPU architecture hardly matters today.

Re: Intel Problems

#144
A company that is being cannibalized by companies ripping the rug under them by developing their own chips, yet Intel makes no efforts to return the favor. They need to make an open source OS phone, maybe that will make a dent and serve as a carrier for the chips. They dont need to do all the work they can partner.

Re: Intel Problems

#145
post #81
post #32

Earlier quoted context omitted.

The vast majority of developers never profile their code. I think this is much less of an issue than anyone on HN would rank it. Only when the platform itself provides traces do they take it into consideration. And even then, I think most perf optimization is in a category of don't do the obviously slow thing, or the accidentally n^2 thing. I partially agree with you though, as the penetration of Arm goes deeper into…

"The vast majority of developers never profile their code." Protip: New on the job and want to establish a reputation quickly? Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent. Another bit of evidence developers rarely profile their code is that I can tell my mental model of how expensive some…

> Find the most common path and fire a profiler at it as early as you can. The odds that there's some trivial win that will accelerate the code by huge amounts is fairly decent.

I've found that a profiler isn't even needed to find significant wins in most codebases. Simple inspection of the code and removal of obviously slow or inefficient code paths can often lead to huge performance gains.

Re: Intel Problems

#146
post #126
post #24

Earlier quoted context omitted.

The likelihood of Intel moving to ARM is probably nil. They have enough software to drag whatever ISA they choose with them, whereas AMD bringing up an ARM core could be fairly herculean as they have to convince their customers to not only buy their new chip but also trust AMD with a bunch of either missing or brand new software.

AMD has already done an ARM 8 core chip. Then abandoned it. ISA changes require a long term investment and building up an ecosystem. Which were out of scope for AMD at the time. I think the market has changed somewhat, and they don't have to do all the heavy lifting. Would be interesting to see what happens there.

They still have an architecture license I think.

Given that x86 still has an advantage on servers makes sense for them to push that for then time being. When the Arm ecosystem is fully established I can't imagine it would be that hard to introduce a new Arm CPU using the innovation they've brought to x86 (chiplets etc).

Re: Intel Problems

#147

Earlier quoted context omitted.

I'm not necessarily disagreeing with you, but... maybe elaborating in a contrary manner? Graviton ARM is certainly vendor lock-in to Amazon. But a Graviton ARM is just a bog-standard Neoverse N1 core. Which means the core is going to show similar characteristics as the Ampere Altra (also a bog-standard Neoverse N1 core). There's more to a chip than its core. But... from a performance-portability and ISA perspective..…

> you'd expect performance-portability between Graviton ARM and Ampere Altra I agree, that would what I would expect too. Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail. Also, AFAIK on ARM the parts…

> Also, AFAIK on ARM the parts where CPUs integrate with the rest of the hardware are custom. The important thing for servers, disk and network I/O differs across ARM chips of the same ISA. Linux kernel abstracts it away i.e. stuff is likely to work, but I’m not so sure about performance portability.

Indeed. But Intel Xeon + Intel Ethernet integrates tightly and drops the Ethernet data directly into L3 cache (bypassing DRAM entirely).

As such, I/O performance portability between x86 servers (in particular: Intel Xeon vs AMD EPYC) suffers from similar I/O issues. Even if you have AMD EPYC + Intel Ethernet, you lose the direct-to-L3 DMA, and will have slightly weaker performance characteristics compared to Intel Xeon + Intel Ethernet.

Or Intel Xeon + Optane optimizations, which also do not exist on AMD EPYC + Optane. So these I/O performance differences between platforms are already on the status-quo, and should be expected if you're migrating between platforms. A degree of testing and tuning is always needed when changing platforms.

--------

>Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail.

A fair point. Still, since Neoverse N1 is a premade core available to purchase from ARM, many different companies have the ability to buy it for themselves.

Current rumors look like Microsoft/Oracle are just planning to use Ampere Altra. But like all other standard ARM cores, any company can buy the N1 design and make their own chip.

Re: Intel Problems

#148
Companies that use millions of micros will grow tired of paying royalties for ARM & other IP. I'm putting my money on RISC-V. If Intel is smart, they will too and offer design customization and contract manufacturing of RISC-V.

Re: Intel Problems

#149

> This is why Intel needs to be split in two. Yes, integrating design and manufacturing was the foundation of Intel’s moat for decades, but that integration has become a straight-jacket for both sides of the business. Intel’s designs are held back by the company’s struggles in manufacturing, while its manufacturing has an incentive problem. The only comparable data point says that this is a terrible idea. AMD spun ou…

AMD had to go through that in order to become a competitive business again. Look at them now! Maybe Intel's chip design business needs to go through the same thing. Maybe there is a way for Intel to open up its fab business to other customers and make it more independent, without splitting it off into another company. However, it seems like that would require a change in direction that goes against decades of company…

But look at Global Foundries now. The article does suggest that Intel's spun off fabs would need state funding to survive but is that really tenable for the long term? Is that TSMC's secret thus far?

Re: Intel Problems

#150

Earlier quoted context omitted.

Self-immolation is only a path to growth if you're a magical bird -- it's not a reasonable strategy for a healthy public company. AMD went through seven years of pain and humiliation between that spinoff and its 2015 glow-up. I understand that sometimes the optimal solution involves a short-term hit, but you don't just sell your organs on a lark (nor because some finance bros at Third Point said so). There are obviou…

> Intel is nowhere near that kind of crisis; it may have some egg on its face but the company still dominates market share in its core businesses and is making profits hand over fist. Years from now, people looking back will be amazed at how fast that changed. The time to react to disruption is now, when the company still has the ability to do so.

It's easy to make that kind of prediction, and in fact people made the same prediction about AMD in far worse circumstances -- and were still wrong. Semiconductors are extremely important to the world's economy right now, not just in PC and server but all over the tech marketplace.
Post reply on HN