Intel Problems • Hacker News Board

Re: Intel Problems

#231

Post by yourapostasy » Tue, Jan 19, 2021, 6:54 PM UTC

DoofusOfDeath wrote: post #116

yourapostasy wrote: post #83

Earlier quoted context omitted.

It was more economics and political policy wonks, economists and politicians in general, who didn't just ask that question, but thrust forth the prescriptive rhetoric through a large grid of trade agreements, "Globalism is here to stay! Get over it! Comparative Advantage!" This is only the first in a long, expensive series of lessons these people will be taught by reality in the coming decades. I'm guessing this kind…

> financialization propping up abstracted processes of how to lead massive organizations as big blocks on diagrams instead of highly fractal, constantly shifting networks of ideas and stories repeatedly coalescing around people, processes, and resources into focused discrete action in continguous and continuous OODA feedback loops absorbing and learning mistakes along the way. I had trouble reading this without falli…

Thanks for introducing me to that, it was enjoyable to listen to Allen.

[1] https://www.youtube.com/watch?v=MVGoY9gom50

Re: Intel Problems

#232

Post by TheOperator » Tue, Jan 19, 2021, 6:55 PM UTC

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?

The point wouldn't be to sell laptops.

Re: Intel Problems

#233

Post by cozzyd » Tue, Jan 19, 2021, 6:56 PM UTC

oblio wrote: post #229

cozzyd wrote: post #222

Earlier quoted context omitted.

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 :-)

Encountering SIGILLs is not super uncommon on heterogeneous academic computer clusters (since -march=native).

But yeah, typically binaries built for redistribution use a reasonably crusty minimum architecture. Reminds me of this discussion for Fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fe...

Re: Intel Problems

#234

Post by volta87 » Tue, Jan 19, 2021, 6:58 PM UTC

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.

> can you compile for ARM and move the binary around as easily as you can for x86?

Yes.

Re: Intel Problems

#235

Post by wmf » Tue, Jan 19, 2021, 7:00 PM UTC

ncmncm wrote: post #201

DreadY2K wrote: post #176

Earlier quoted context omitted.

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.

C, C++, Rust, & Go compile to an abstract machine, instead. It is quite hard these days to get it to do something different between x86, ARM, and Power, except relying on memory model features not guaranteed on the latter two; and on M1 the memory model apes x86's. Given a compatible memory model (which, NB, ARM has not had until M1) compiling for the target is trivial. The x86 memory model makes it increasingly hard…

Note that M1 only uses TSO for Rosetta; ARM code runs with the ARM weak memory model.

Re: Intel Problems

#236

Post by oblio » Tue, Jan 19, 2021, 7:03 PM UTC

altcognito wrote: post #89

TheOtherHobbes wrote: post #76

Earlier quoted context omitted.

The point is Intel can't compete as a fab or as a design house. It's doubtful if Intel would have been able to design an equivalent to the M1, even with access to TSMC's 5nm process and an ARM license. Which suggests there's no point in throwing money at Intel because the management culture ("management debt") itself is no longer competitive. It would take a genius CEO to fix this, and it's not obvious that CEO exist…

AMD looked just as bad not so long ago.

Plus even though Intel has been super fat for 3 decades or so, everyone has predicted their death for at least another 3 decades (during their switch from memory to CPUs and then afterwards when RISCs were going to take over the world).

So they do have a bit of history with overcoming these predictions. We'll just have to see if they became too rusty to turn the ship around.

Re: Intel Problems

#237

Post by nine_k » Tue, Jan 19, 2021, 7:04 PM UTC

MangoCoffee wrote: post #221

ineedasername wrote: post #202

Earlier quoted context omitted.

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

I bet TSMC has a number of bombs planted around the most critical machines, much like Switzerland has bombs planted around most critical tunnels and bridges.

Trying to grab Taiwan with force alone, even if formally successful, would mean losing its crown jewels forever.

Re: Intel Problems

#238

Post by matwood » Tue, Jan 19, 2021, 7:07 PM UTC

MaxBarraclough wrote: post #161

treve wrote: post #107

Earlier quoted context omitted.

Maybe I'm missing something, but don't the vast majority of applications don't care about what architecture they run on? The main difference for us was lower bills.

> Maybe I'm missing something, but don't the vast majority of applications don't care about what architecture they run on? There can be issues with moving to AArch64, for instance your Python code may depend on Python 'wheels' which in turn depend on C libraries that don't play nice with AArch64. I once encountered an issue like this, although I've now forgotten the details. If your software is pure Java I'd say the…

Sure, but you're talking about short term problems. RPi, Graviton, Apple Silicon, etc... are making AArch64 a required mainstream target.

Re: Intel Problems

#239

Post by adrian_b » Tue, Jan 19, 2021, 7:13 PM UTC

cbozeman wrote: post #188

This was a well-written article, but I don't think it came from someone with a deep understanding of semiconductor technology and fabrication. Intel hasn't lost to Apple and AMD because they employ idiots, or because of their shitty company culture (in fact, they're doing surprisingly well in spite of their awful company culture). Intel lost because they made the wrong bet on the wrong type of process technology. 10…

I agree with most of what you say, except that AMD was also technically superior during these last years.

Intel certainly has the potential of being technically superior to AMD, but they do not appear to have focused on the right things in their roadmaps for CPU evolution.

Many years before the launches of Ice Lake and Tiger Lake, the enthusiastic presentations of Intel about the future claimed that these will bring some sort of marvelous improvements in microarchitecture, but the reality has proven to be much more modest.

While from Skylake in 2015 to Ice Lake in 2019 there was a decent increase in IPC, it was still much less than expected after so many years. While they were waiting for a manufacturing process, they should have redesigned their CPU cores to get something better than this.

Moreover the enhancements in Ice Lake and Tiger Lake seem somewhat unbalanced and random, there is no grand plan that can be discerned about how to improve a CPU.

On the other hand the evolution of Zen cores was perfect, every time the AMD team seems to have been able to add precisely all improvements that could give a maximum performance increase with a minimum implementation effort.

Thus they were able to pass from Zen 1 (2017) with an IPC similar to Intel Broadwell (2014), to Zen 2 (2019) with an IPC a little higher than Intel Skylake (2015) and eventually to Zen 3 (2020) with an IPC a little higher than Intel Tiger Lake (2020).

So even if the main advantage of AMD remains the superior CMOS technology they use from TSMC, just due to the competence of their design teams, they have passed from being 3 years behind Intel in IPC in 2017, to being ahead of Intel in IPC in 2020.

If that is not technical superiority, I do not know what is.

Like I have said, I believe that Intel could have done much better than that, but they seem to have done some sort of a random walk, instead of a directed run, like AMD.

Re: Intel Problems

#240

Post by ogre_codes » Tue, Jan 19, 2021, 7:14 PM UTC

gchamonlive wrote: post #134

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…

I think OP was talking about managed services, like lambda, Ecs and beanstalk internal control, EC2 internal management system, that is systems that are transparent for the user. AWS could very well run their platform systems entirely on graviton. After all, serverless and cloud is in essence someone else's server. AWS might as well run all their paas software on in-house architecture

While there is vendor lock in with those services, it also has nothing to do with what CPU you are running. At that layer, CPU is completely abstract.