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

221–230 of 431 posts

Re: Intel Problems

#221

Post by MangoCoffee »

ineedasername wrote: post #202
okl wrote: post #173

Earlier quoted context omitted.

> [...] 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…

National security doesn't just extend to direct military applications. Pretty much every industry and piece of critical infrastructure comes into play here. It won't matter if western fabs can produce something "good enough" if every piece of technological infrastructure from the past 5 years was built with something better. As for moves again at Taiwan, China hasn't given up that prize. Brain drain would be moot if…

>As for moves again at Taiwan, China hasn't given up that prize.

CCP hasn't give up since KMT high-tailed to Taiwan. for more than 40+ yrs American cozy up with the Chinese govrt and doing business with China.

American told Taiwan govrt not to "make trouble" but we all know China is the one who make all the troubles with military threat and flying aircraft over Taiwan, day in and day out.

Taiwan have build up a impressive defensives from buying weapon (US) to develop its own. yes, China can take Taiwan. that's 100% but at what price.

that's what Taiwanese is betting on, China will think twice about invading.

Re: Intel Problems

#222

Post by cozzyd »

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.

it will probably be a similar situation to x86, with various vendors implementing various instructions in some processors that won't be supported by all. I guess the difference is that there may be many more variants than in x86, but performance-critical code can always use runtime dispatch mechanisms to adapt.

Re: Intel Problems

#223

Post by easton »

heartbreak wrote: post #141
agloeregrets wrote: post #84

Earlier quoted context omitted.

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?

If they could get it to $600-800 and have an option for Windows, decent trackpad/keyboard, you could sell them to students just as well. Shoot, if the DE for Amazon Linux was user friendly enough they wouldn’t even need windows, since half of schools are on GSuite these days.

Re: Intel Problems

#224

Post by adrian_b »

kllrnohj wrote: post #200
cbozeman wrote: post #166

Earlier quoted context omitted.

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…

While you are right that due to their design CPUs like Apple M1 can reach the same single-thread performance as Intel/AMD at a much lower clock frequency and such a clock frequency could be reached much earlier, e.g. already Intel Nehalem in 2009 reached 3.3 GHz as turbo, while Sandy Bridge in 2011 had 3.4 GHz as base clock frequency, it would have been impossible to make a CPU like Apple M1 in any earlier technology, not even in Intel's 14 nm.

To achieve its very high IPC, M1 multiplies a lot of internal resources and also uses very large caches. All those require a huge number of transistors.

Implementing an M1-like design in an earlier technology would have required a very large area, resulting in a price so large and also in a power consumption so large that such a design would have been infeasible.

However, you are partially right in the sense that Intel clearly was overconfident due to their clock frequency advantage and they have decided on a roadmap to increase the IPC of their CPUs in the series Skylake => Ice Lake => Alder Lake that was much less ambitious than it should have been.

While Tiger Lake and Ice Lake have about the same IPC, Alder Lake is expected to bring a similar increase like from Skylake to Ice Lake.

Maybe that will be competitive with Zen 4, but it is certain that the IPC of Alder Lake will still be lower than the IPC of Apple M1, so Intel will continue to be able to match the Apple performance only at higher clock frequencies, which cause a higher power consumption.

Re: Intel Problems

#225

Post by usefulcat »

exmadscientist wrote: post #171
usefulcat wrote: post #120

Earlier quoted context omitted.

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

Maybe it wasn't clear, but the article I linked is saying that compared to M1, x86 architectures are decode-limited, because parallel decoding with variable-length instructions is tricky. Intel and AMD (again according to the linked article) have at most 4 decoders, while M1 has 8.

So yes the ROB is after decoding, but surely there's little point in having the ROB be larger than can be kept relatively full by the decoders.

Re: Intel Problems

#226

Post by Causality1 »

The funny thing is, in the time period being addressed first in the article (2013) Intel was better at mobile than it is now. Its Bay Trail and Cherry Trail chips had more performance per dollar than even today's offerings, eight years later. Intel just decided low-margin wasn't a concept in which they were interested.

Re: Intel Problems

#227

Post by usefulcat »

AnimalMuppet wrote: post #179
usefulcat wrote: post #120

Earlier quoted context omitted.

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…

According to the article I linked, that's basically how they do it:

"The brute force way Intel and AMD deal with this is by simply attempting to decode instructions at every possible starting point. That means x86 chips have to deal with lots of wrong guesses and mistakes which has to be discarded. This creates such a convoluted and complicated decoder stage that it is really hard to add more decoders. But for Apple, it is trivial in comparison to keep adding more.

In fact, adding more causes so many other problems that four decoders according to AMD itself is basically an upper limit for them."

Re: Intel Problems

#228

Post by dogma1138 »

nickik wrote: post #44
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…

AMD makes great designs, switching to ARM/RISC-V would make them lose value but not kill them.

And Intel doesn’t?

Re: Intel Problems

#229

Post by oblio »

cozzyd wrote: post #222
oblio wrote: post #215

Earlier quoted context omitted.

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.

it will probably be a similar situation to x86, with various vendors implementing various instructions in some processors that won't be supported by all. I guess the difference is that there may be many more variants than in x86, but performance-critical code can always use runtime dispatch mechanisms to adapt.

It's true that there are extensions to x86, but 99,99% of software out there (the one you'd commonly install on Windows or find in Linux distribution repos) doesn't use those instructions or maybe just detects the features and then uses it.

I don't recall encountering a "Intel-locked" or "AMD-locked" application in more than 20 years of using x86. Ok, maybe ICC, but that one kind of makes sense :-)

Re: Intel Problems

#230

Post by dogma1138 »

oldgradstudent wrote: post #56
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…

> Intel can become a fab company Not unless they catch up with TSMC in process technology. Otherwise, they become an uncompetitive foundry.

You don’t have to be a bleeding edge foundry, there are tons of components that cannot be manufactured on bleeding edge nodes nor need too.

Intel can’t compete right now on the bleeding edge node but they outcompete TSMC by essentially every other factor when it comes to manufacturing.

Post reply on HN