Intel Problems • Hacker News Board

Re: Intel Problems

#171

Post by exmadscientist » Tue, Jan 19, 2021, 5:43 PM UTC

usefulcat wrote: post #120

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…

I'm not sure that's entirely true. According to this (see "Why can’t Intel and AMD add more instruction decoders?"): https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32... ..a big part of the reason the M1 is so fast is the large reorder buffer, which is enabled by the fact that arm instructions are all the same size, which makes parallel instruction decoding far easier. Because x86 instructions are variable…

That doesn't make any sense. The ROB is after instructions have been cracked into uops; the internal format and length of uops is "whatever is easiest for the design", since it's not visible to the outside world.

This argument does apply to the L1 cache, which sits before decode. (It does not apply to uop caches/L0 caches, but is related to them anyway, as they are most useful for CISCy designs, with instructions that decode in complicated ways into many uops.)

Re: Intel Problems

#172

Post by sf_rob » Tue, Jan 19, 2021, 5:43 PM UTC

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…

Isn't most of M1's performance success due to being a SoC / increasing component locality/bandwidth? I think ARM vs x86 performance on its own isn't a disadvantage. Instead the disadvantages are a bigger competitive landscape (due to licensing and simplicity), growing performance parity, and SoCs arguable being contrary to x86 producers' business models.

Re: Intel Problems

#173

Post by okl » Tue, Jan 19, 2021, 5:45 PM UTC

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/"brain drain".

Re: Intel Problems

#174

Post by echelon » Tue, Jan 19, 2021, 5:46 PM UTC

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…

> Building server software on Graviton ARM creates a vendor lock-in to Amazon

Amazon already has lock-in. Lambda, SQS, etc. They've already won.

You might be able to steer your org away from this, but Amazon's gravity is strong.

Re: Intel Problems

#175

Post by Spooky23 » Tue, Jan 19, 2021, 5:46 PM UTC

JoshTko wrote: post #157

WoodenChair wrote: post #110

The thing about all of these articles analyzing Intel's problems is that nobody really knows the details of Intel's "problems" because it comes down to just one "problem" that we have no insight into: node size. What failures happened in Intel's engineering/engineering management of its fabs that led to it getting stuck at 14 nm? Only the people in charge of Intel's fabs know exactly what went wrong, and to my knowle…

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.

Wasn’t the issue that the whole industry did a joint venture, but Intel decided to go it alone?

I worked at a site (in a unrelated industry) where there was a lot of collaborative semiconductor stuff going on, and the only logo “missing” was Intel.

Re: Intel Problems

#176

Post by DreadY2K » Tue, Jan 19, 2021, 5:47 PM UTC

dfgdghdf wrote: post #143

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…

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.

Many people do code against some sort of VM, but there are still people writing code in C/C++/Rust/Go/&c that gets compiled to machine code and run directly.

Also, even if you're running against a VM, your VM is running on an ISA, so performance differences between them are still relevant to your code's performance.

Re: Intel Problems

#177

Post by okl » Tue, Jan 19, 2021, 5:49 PM UTC

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…

SemiAccurate has written a lot about the reasons, for me the essence from that was: complacency, unrealistic goals, they didn't have a plan B in case schedule slips.

Re: Intel Problems

#178

Post by Joe_Cool » Tue, Jan 19, 2021, 5:49 PM UTC

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.

They already have that: https://www.amd.com/en/amd-opteron-a1100

Didn't sell very well.

Re: Intel Problems

#179

Post by AnimalMuppet » Tue, Jan 19, 2021, 5:49 PM UTC

usefulcat wrote: post #120

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…

I'm not sure that's entirely true. According to this (see "Why can’t Intel and AMD add more instruction decoders?"): https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32... ..a big part of the reason the M1 is so fast is the large reorder buffer, which is enabled by the fact that arm instructions are all the same size, which makes parallel instruction decoding far easier. Because x86 instructions are variable…

Well, if we can have speculative execution, why not speculative decode? You could decode the stream as if the next instruction started at $CURRENT_PC+1, $CURRENT_PC+2, etc. When you know how many bytes the instruction at $CURRENT_PC takes, you could keep the right decode and throw the rest away.

Sure, it would mean multiple duplicate decoders, which eats up transistors. On the other hand, we've got to find something useful for all those transistors to do, and this looks useful...

Re: Intel Problems

#180

Post by billiam » Tue, Jan 19, 2021, 5:50 PM UTC

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…

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.