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

211–220 of 431 posts

Re: Intel Problems

#211

Post by PKop »

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…

>I'm astounded

Our political system and over financialized economy seem to suffer from same hyper short term focus that many corporations chasing quarterly returns run in to. No long term planning or focus, and perpetual "election season" thrashing one way or another while nothing is followed through with.

Plus, in 2, 4 or 8 years many of the leaders are gone and making money in lobbying or corporate positions. No possibly short-term-painful but long term beneficial policy gets enacted, etc.

And many still uphold our "values" and our system as the ideal, and question any that would look towards the Chinese model as providing something to learn from. So, I anticipate this trend will continue.

Re: Intel Problems

#212

Post by mchusma »

WoodenChair wrote: post #158
JoshTko wrote: post #157

Earlier quoted context omitted.

We actually have a lot of insight in that Intel still doesn't have a good grasp on the problem. Their 10nm was supposed to enter volume production in mid 2018, and they still haven't truly entered volume production today. Additionally Intel announced in July 2020 that their 7nm is delayed by at least a year which means they figured out their node delay problem.

> We actually have a lot of insight in that Intel still doesn't have a good grasp on the problem. Their 10nm was supposed to enter volume production in mid 2018, and they still haven't truly entered volume production today. Additionally Intel announced in July 2020 that their 7nm is delayed by at least a year which means they figured out their node delay problem. Knowing something happened is not the same as knowing…

A key issue is volume. Intel is doing many times less volume than the mobile chipmakers. So intel cant spend as much to solve the problem.

It's a bad strategic position to be in, and I agree with Ben's suggestions as one of the only ways out of it.

Re: Intel Problems

#213

Post by rjmunro »

totalZero wrote: post #142
morganw wrote: post #114

Earlier quoted context omitted.

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

I thought Boeing had many issues pre-covid, not just the 737 Max. Starliner immediately springs to mind.

Re: Intel Problems

#214

Post by remexre »

acoard wrote: post #65
ashtonkem wrote: post #17

Earlier quoted context omitted.

Emulation is no way to estimate performance.

Sure, but as a counter example Docker performance on Mac has historically been abysmal[0][1], but everyone on Mac I know still develops using it. We ignore the performance hit on dev machines, knowing it won't affect prod (Linux servers). I don't see why this pattern would fail to hold, but am open to new perspectives. [0] https://dev.to/ericnograles/why-is-docker-on-macos-so-much-w... [1] https://www.reddit.com/r/do…

The VM that uses takes advantage of hardware-accelerated virtualization, for running amd64 VMs on amd64 CPUs. You don't have hardware-accelerated virtualization for amd64 VMs on any ARM CPUs I know of...

Re: Intel Problems

#215

Post by oblio »

optimiz3 wrote: post #165
rapsey wrote: post #108

Earlier quoted context omitted.

Why would it be lock in. If you can compile for arm you can compile for x86.

Memory model, execution units, simd instructions...

The real question is, can you compile for ARM and move the binary around as easily as you can for x86?

I'm reasonably sure that you can take a binary compiled with GCC on a P4 back in the day and run it on the latest Zen 3 CPU.

Re: Intel Problems

#216

Post by oblio »

billiam wrote: post #180
chasil wrote: post #131

Earlier quoted context omitted.

As I understand it, ARM's new willingness to allow custom op-codes is dependent upon the customer preventing fragmentation of the ARM instruction set. In theory, your software could run faster, or slower, depending upon Amazon's use of their extensions within their C library, or associated libraries in their software stack. Maybe the wildest thing that I've heard is Fujitsu not implementing either 32-bit or Thumb on…

It's interesting that if you step back and look at what Amazon has been most willing to just blow up and destroy, it is the idea of intellectual property of any kind. It comes out clearly in their business practices. This muscle memory may make it hard for ARM to have a long term stable relationship with a company like ARM.

What do you mean?

Also, I think there's a typo in your last phrase.

Re: Intel Problems

#217

Post by MangoCoffee »

thoughtsimple wrote: post #55

How does Moore's law figure into this? I suspect that TSMC runs into the wall that is quantum physics at around 1-2nm. Considering that TSMC has said that they will be in full production of 3nm in 2022, I can't see 1nm being much beyond 2026-2028. What happens then? Does a stall in die shrinks allow other fabs to catch up? It appears to me that Intel stalling at 14nm is what opened the door for TSMC and Samsung to ca…

> I can't see 1nm being much beyond 2026-2028. What happens then?

whatever marketing people come up? Moore's law is not a law but an observation. it doesn't really matter tho. we are going to 3D chip, chiplet, advance packaging ...etc.

Re: Intel Problems

#218

Post by easton »

oblio wrote: post #215
optimiz3 wrote: post #165

Earlier quoted context omitted.

Memory model, execution units, simd instructions...

The real question is, can you compile for ARM and move the binary around as easily as you can for x86? I'm reasonably sure that you can take a binary compiled with GCC on a P4 back in the day and run it on the latest Zen 3 CPU.

As far as I can tell, yes. Docker images compiled for arm64 work fine on the Macs with M1 chips without rebuilding. And as another commenter said, you can compile a binary on a Raspberry Pi 4 and move it to a EC2 graviton instance and it just works.

Re: Intel Problems

#219

Post by stephencanon »

chasil wrote: post #131
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…

As I understand it, ARM's new willingness to allow custom op-codes is dependent upon the customer preventing fragmentation of the ARM instruction set. In theory, your software could run faster, or slower, depending upon Amazon's use of their extensions within their C library, or associated libraries in their software stack. Maybe the wildest thing that I've heard is Fujitsu not implementing either 32-bit or Thumb on…

> Maybe the wildest thing that I've heard is Fujitsu not implementing either 32-bit or Thumb on their new supercomputer. Is that a special case?

What's wild about this? Apple dropped support for 32b (arm and thumb) years ago with A11. Supporting it makes even less sense in an HPC design than it does in a phone CPU.

Re: Intel Problems

#220

Post by rapsey »

optimiz3 wrote: post #165
rapsey wrote: post #108

Earlier quoted context omitted.

Why would it be lock in. If you can compile for arm you can compile for x86.

Memory model, execution units, simd instructions...

The vast majority of code running is in python, js, jvm, php, ruby, etc. Far removed these concerns.
Post reply on HN