Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Problems

stratechery.com

Post reply on HN
Print view View original

91–100 of 431 posts

Re: Intel Problems

#91

Post by phkahler »

api wrote: post #45
dogma1138 wrote: post #36

Earlier quoted context omitted.

At that point if it will be trouble for Intel it would be a death sentence for AMD... Intel has fabs, yes it’s what maybe holding them back atm but it also a big factor in what maintains their value. If x86 dies and neither Intel nor AMD pivot in time Intel can become a fab company they already offer these services, yes no where near the scale of say TSMC but they have a massive portfolio of fabs and their fabs are l…

How hard would it be for AMD to make an ARM64 based partly on the IP of the Zen architecture? Seems like AMD could equal or beat M1 if they wanted.

>> Seems like AMD could equal or beat M1 if they wanted.

Sometime around 5? years ago AMD was planning to have an ARM option. You'd get essentially an ARM core in an AMD chip with all the surrounding circuitry. They hyped it so much I wondered if they might go further than just that.

Further? Maybe a core that could run either ISA, or a mix of both core types. I dunno, but they dumped that (or shelved it) to focus on Zen, which saved them. No doubt the idea and capability still exist within the company. I'd like to see them do a RISCV chip compatible with existing boards.

Re: Intel Problems

#92

Post by Const-me »

ashtonkem wrote: post #10

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…

Building server software on Graviton ARM creates a vendor lock-in to Amazon, with very high costs of switching elsewhere. Despite using A64 ISA and ARM’s cores, they are Amazon’s proprietary chips no one else has access to. Migrating elsewhere gonna be very expensive.

I wouldn’t be surprised if they sponsor their Graviton offering taking profits elsewhere. This might make it seem like a good deal for customers, but I don’t think it is, at least not in the long run.

This doesn’t mean Graviton is useless. For services running Amazon’s code as opposed to customer’s code (like these PAAS things billed per transaction) the lock-in is already in place, custom processors aren’t gonna make it any worse.

Re: Intel Problems

#93

Post by scythe »

mhh__ wrote: post #21
sitkack wrote: post #19

Earlier quoted context omitted.

Very little user code generates binaries that can _tell_ it is running on non-x86 hardware. Rust is Arm Memory Model safe, existing C/C++ code that targets the x86 memory model is slowly getting ported over, but unless you are writing multithreaded C++ code that cuts corners it isn't an issue. Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than y…

It's not the memory model I'm thinking of but the cache design, ROB size etc. Obviously this is fairly niche but the friction to making something fast is hugely easier locally.

If you use a VM language like Java, Ruby, etc, that work is largely abstracted.

Re: Intel Problems

#94

Post by twblalock »

totalZero wrote: post #8

> 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 culture. It might be easier to achieve that by actually splitting the fab business off.

Re: Intel Problems

#95

Post by klelatti »

blinkingled wrote: post #85
stefan_ wrote: post #72

Earlier quoted context omitted.

Why are people so hung up about the x86 thing? ARM continues to be sold on because everyone has now understood they don't really matter; they are not driving the innovations, they were simply the springboard for the Apples, Qualcomms and Amazons to drive their own processor designs, and they are not setup to profit from that. ARMs reference design isn't competitive, the M1 is. Instruction set architecture at this poi…

Well put. People are being their usual teamsport participants on x86 vs ARM. Intel has execution problems in two departments - manufacturing and integration. ISA is not an issue - they can very well solve the integration issues and investing in semiconductor manufacturing is the need of the hour for the US so I can imagine they getting some traction there with enough money and will. IOW even if Intel switched ISA to…

Intel / AMD had a duopoly on desktop / server because of x86 for a large number of years.

Loss of that duopoly - even with competitive manufacturing - has profound commercial implications for Intel. M1 and Graviton will be followed by others that will all erode Intel's business.

Re: Intel Problems

#96

Post by ZeroCool2u »

garaetjjte wrote: post #67
totalZero wrote: post #8

> 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…

>The only comparable data point says that this is a terrible idea. Huh, I would say completely opposite thing. AMD wouldn't have survived if it kept trying to improve their own process instead of going to TSMC.

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 other form, it must take a back seat to preventing the scenario described above from becoming reality. We are on the brink of this happening already with so many people suggesting such a split and ignoring what happened to AMD and GF.

The geopolitical ramifications of completely centralizing the only leading process node in such a sensitive area between the world's super powers cannot be understated.

Full disclosure: I'm a shareholder in Intel, TSMC, and AMD.

Re: Intel Problems

#97

Post by fhrifjr »

vinay_ys wrote: post #70
mhh__ wrote: post #54

Earlier quoted context omitted.

This isn't really about you or me but the libraries that work behind the spaghetti people fling into the cloud.

Yes, and just like Intel & AMD spent a lot of effort/funding for building performance libraries and compilers, we should expect Amazon and Apple invest into similar efforts. Apple will definitely give all the necessary tools as part of Xcode for iOS/MacOS software optimisation. AWS is going to be more interesting – this is a great opportunity for them to provide distributed profiling/tracing tools (as a hosted servic…

So far I found getting started repo for Graviton with few pointers https://github.com/aws/aws-graviton-getting-started

Re: Intel Problems

#98

Post by dragontamer »

Const-me wrote: post #92
ashtonkem wrote: post #10

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…

Building server software on Graviton ARM creates a vendor lock-in to Amazon, with very high costs of switching elsewhere. Despite using A64 ISA and ARM’s cores, they are Amazon’s proprietary chips no one else has access to. Migrating elsewhere gonna be very expensive. I wouldn’t be surprised if they sponsor their Graviton offering taking profits elsewhere. This might make it seem like a good deal for customers, but I…

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.

Now Ampere Altra is like 2x80 core, while Graviton ARM is... a bunch of different configurations. So its still not perfect compatibility. But a single-threaded program probably couldn't tell the difference between the two platforms.

I'd expect that migrating between Graviton and Ampere Altra is going to be easier than Intel Skylake -> AMD Zen.

Re: Intel Problems

#99

Post by vinay_ys »

jeffbee wrote: post #48
secondcoming wrote: post #28

Earlier quoted context omitted.

GCP only offer Epyc CPUs in some regions. None of those regions are ones we use! Gah! Can someone update us on where AWS offer them, if at all?

If you think about how these providers deploy a cloud facility, it makes sense that the offerings in a given place are relatively static. The whole network design, thermal/mechanical design, and floor plan is built with certain assumptions and they can't just go in and rack up some new machines. It evolves pretty slowly and when a facility gets a new machine it is because they refresh the whole thing, or a large subs…

Usually you would have some number of enclosed aisles of racks make up a deployment pod.

You can usually customize machine configuration within a deployment pod while staying within the electrical and thermal envelope of the aisle and without changing the number of core-spine to pod-spine network links.

You could potentially build out a data hall but not fully fill it with aisles. As demand starts to trend up you can forecast two quarters into future and do the build-outs with just one quarter lead time.

I would expect very large operators to have perfected this supply chain song and dance very well.

Re: Intel Problems

#100

Post by twblalock »

sradman wrote: post #42

> Solution One: Breakup > Solution Two: Subsidies Solution Three: lower prices/margins (temporarily) to match the value proposition of AMD on Windows PCs and Linux Cloud servers.

Intel needs to change the way it does business. Simply lowering prices won't achieve that. Becoming the cheap option is likely the beginning of a death spiral the company will never recover from -- it will give the company an excuse to double down on a failing strategy.

Furthermore, AMD is not the biggest threat to Intel. The biggest threat is cloud providers like Amazon designing their own chips, which is already happening. If those succeed, who would build them? Certainly not Intel, if they continue to manufacture only their own designs -- that business, like so much other fab business, will go to TSMC.

Post reply on HN