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

191–200 of 431 posts

Re: Intel Problems

#191

Post by tgtweak »

Covzire wrote: post #149
twblalock wrote: post #94

Earlier quoted context omitted.

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?

Global Foundries has stopped at 12nm and I don't see any plans to go beyond that. A notable amount of their fabs are in South Korea anyway so they would fall into the same bucket.

Re: Intel Problems

#192

Post by kllrnohj »

skohan wrote: post #151
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…

This is kind of what should happen right? I'm not an expert, but my understanding is that one of the takeaways from the M1 success has been the weaknesses of x86 and CISC in general. It seems as if there is a performance ceiling which exists for x86 due to things like memory ordering requirements, and complexity of legacy instructions, which just don't exist for other instruction sets. My impression is that we have b…

> weaknesses of x86 and CISC in general

"RISC" and "CISC" distinctions are murky, but modern ARM is really a CISC design these days. ARM is not at all in a "an instruction only does one simple thing, period" mode of operation anymore. It's grown instructions like "FJCVTZS", "AESE", and "SHA256H"

If anything CISC has overwhelmingly and clearly won the debate. RISC is dead & buried, at least in any high-performance product segment (TBD how RISC-V ends up fairing here).

It's largely "just" the lack of variable length instructions that helps the M1 fly (M1 under Rosetta 2 runs with the same x86 memory model, after all, and is still quite fast).

Re: Intel Problems

#193

Post by Lopiolis »

okl wrote: post #173
ineedasername wrote: post #152

I found the geopolitical portion to be the most important aspect here. China has shown a willingness to flex its muscles on enforcing its values beyond their borders. China is smart, and plays a long game. We don't want to wake up one day and find they've flexed their muscles on their regional neighbors similar to their rare earths strong-arming from 2010-2014 and not have fab capabilities to fall back on in the West…

> [...] and not have fab capabilities to fall back on in the West. I'm not too concerned: - There are still a number of foundries in western countries that produce chips which are good enough for "military equipment". - Companies like TSMC are reliant on imports of specialized chemicals and tools mostly from Japan/USA/Europe. - Any move from China against Taiwan would likely be followed by significant emigration/"bra…

The issue isn't just military equipment though. When your entire economy is reliant on electronic chips, it's untenable for all of those chips to come from a geopolitical opponent. That gives them a lot of influence over business and politics without having to impact military equipment.

Re: Intel Problems

#194

Post by eloisant »

foobarian wrote: post #64
mhh__ wrote: post #20

Earlier quoted context omitted.

You miss my point - if I am seriously optimizing something I need to be on the same chip not the same ISA. Graviton2 is a Neoverse core from Arm and it's totally separate from M1. Besides, Apple don't let you play with PMCs easily and I'm assuming they won't be publishing any event tables any time soon so unless they get reverse engineered you'll have to do it through xcode.

We have MBPs on our desks but our cloud are Centos Xeon machines. The problems I run into are not squeezing every last ms of performance, since it's vastly cheaper to just add more instances. The problems I care about is that some script I wrote suddenly doesn't work in production because of BSDisms, or Python incompatibilities, or old packages in brew, etc. Would be nice if Apple waved a magic wand and replaced its…

I just wish my employer would let me work on a Linux PC rather than a MBP, then I wouldn't have this mismatch between my machine and server...

Re: Intel Problems

#195

Post by ralph84 »

jorblumesea wrote: post #115
Const-me wrote: post #92

Earlier quoted context omitted.

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…

Really, you could make the argument for any AWS service and generally using a cloud service provider. You get into the cloud, use their glue (lambda, kinesis, sqs etc) and suddenly migrating services somewhere else is a multi-year project. Do you think that vendor lock in has stopped people in the past (and future)? Thinking about those kinds of things are long term and many companies think short term.

Heck, Amazon themselves got locked-in to Oracle for the first 25 years of Amazon's existence. Vendor lock-in for your IT stack doesn't prevent you from becoming a successful business.

Re: Intel Problems

#196

Post by wmf »

jayd16 wrote: post #135
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…

I guess I don't understand why the M1 makes developing on Graviton easier. It doesn't make Android or Windows ARM dev any easier. I guess the idea is to run a Linux flavor that supports both the M1 and Graviton on the macs and hope any native work is compatible?

It's not hope; ARM64 is compatible with ARM64 by definition. The same binaries can be used in development and production.

Windows ARM development (in a VM) should be much faster on an M1 Mac than on an x86 computer since no emulation is needed.

Re: Intel Problems

#197

Post by erosenbe0 »

skohan wrote: post #151
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…

This is kind of what should happen right? I'm not an expert, but my understanding is that one of the takeaways from the M1 success has been the weaknesses of x86 and CISC in general. It seems as if there is a performance ceiling which exists for x86 due to things like memory ordering requirements, and complexity of legacy instructions, which just don't exist for other instruction sets. My impression is that we have b…

There isn't any performance ceiling issue. Intel ISA operates at a very slight penalty in terms of achievable performance per watt, but nothing in an absolute sense.

I would argue it isn't time for Intel to switch until we see a little more of the future as process nodes may shrink at a slower rate. Will we have hundreds of cores? Field programmable cores? More fixed function hardware on chip, or less? How will high-bandwidth high-latency gddr style memory mix with lower-latency lower-bandwidth ddr memory? Will there be on die memory like hbm for cpus?

Re: Intel Problems

#198

Post by hajile »

mhh__ wrote: post #51
raverbashing wrote: post #30

Earlier quoted context omitted.

Nah I think the Itanic concept is dead in the water VLIW works (especially in the way it was done in Itanium - IIRC) when either your workload is too predictable or maybe if your compiler manages to be one order of magnitude smarter than it is today (even with llvm, etc) It seems even M1 prefers to reorder scalar operations than work with SIMD ops in some cases (this is one of its processors)

Itanium is dead but VLIW as a concept is still interesting to me. If you look at uops executed per port benchmarks you can see that CPUs are far from all seeing eyes.

AMD and Nvidia both used VLIW in the past and both moved away because they couldn't get it to run efficiently. If embarrassingly parallel problems can't execute efficiently on VLIW architectures, I somehow doubt that CPUs will either.

The final versions of Itanic started adopting all the branch predictors and trappings from more traditional chips.

The problem is that loops theoretically cannot be completely predicted at compile time (the halting problem). Modern OoO CPUs are basically hardware JITs that change execution paths and patterns on the fly based on previous behavior. This (at least at present) seems to get much better data resulting in much better real-world performance compared to what the compiler sees.

Re: Intel Problems

#199

Post by ncmncm »

It's time for more predictions.

1. Apple's CPUs will not improve anywhere near as fast as the competition. Computation per watt of (some) competitors' products will outpace Apple's in just a few years.

2. Intel will come roaring back on the back of TSMC, but first will need to wait on growth of manufacturing capacity, as certain competitors can get more money per mm^2.

3. Intel will fail to address its product-quality problem, but it will not end up hurting them.

Re: Intel Problems

#200

Post by kllrnohj »

cbozeman wrote: post #166
chaorace wrote: post #139

Earlier quoted context omitted.

I did not know that! Though, that answer raises its own questions... If the two are entirely unlinked, what's stopping Intel from slapping "Now 3nm!" on their next gen processors? Surely some components must be at the advertised size, even if it's no longer a clear cut all-or-nothing descriptor, right? What's actually being sized down and why is it seemingly posing so many challenges for Intel's supply chain?

I think it'll be a good thing when people stop worrying about process node technology and start worrying about performance and power usage. Intel's 14nm chips are already competitive with AMD's (TSMC's, really) 7nm chips. The i7-11700 or whatever the newest one coming out soon is called, is going to be pretty much exactly on parity with AMD's Ryzen 5000 series. So if node shrinkage is such a dramatic increase in perf…

> I think it'll be a good thing when people stop worrying about process node technology and start worrying about performance and power usage.

I think it's more that people attribute too much significance to process node technology when trying to understand why performance & power are what they are.

For single-core performance the gains from a node shrink are in the low teen percentage increases. Power improvements at the same performance are a bit better, but still not as drastic as people tend to treat it as.

10-20 years ago just having a better process node was a massive deal. These days it's overwhelmingly CPU design & architecture that dictate things like single-core performance. We've been "stuck" at the 3-5ghz range for something like half a decade now and TSMC has worse performance here than Intel's existing 14nm. Still hasn't been a single TSMC 7nm or 5nm part that hits that magical 5ghz mark reliably enough for marketing, for example. And that's all process node performance is - clock speed. M1 only runs at 3.2ghz - you could build that on Intel's 32nm without any issues. Power consumption would be a lot worse, but you could have had "M1-like" single-core performance way back in 2011 if you had a time machine to take back all the single-core CPU design lessons & improvements, that is.

Post reply on HN