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

161–170 of 431 posts

Re: Intel Problems

#161

Post by MaxBarraclough »

treve wrote: post #107
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…

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 odds are pretty good that things will 'just work', but you'd still want to do testing.

Re: Intel Problems

#162

Post by timthorn »

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…

Ubuntu 64 looks the same on Graviton as on a Raspberry Pi. You can take a binary you've compiled on the RPi, scp it to the Graviton instance and it will just run. That works the other way round too, which is great for speedy Pi software builds without having to set up a cross-compile environment.

Re: Intel Problems

#163

Post by iamgopal »

Solution three : Invest to make x86 to become power efficient to reach at par or better than arm counter part, while outsourcing manufacturing to TMSC to fill the gap. Reach to the level Future Apple M chip will achieve. At the same time, start building bare metal cloud hosting solutions that allow other companies to provide their own cloud solutions, ( and using energy efficiency at your advantage ), also use that energy efficiency to create mobile platform that can enable Mozilla and Ubuntu like provider to make operating syatem on.

Re: Intel Problems

#164

Post by dboreham »

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.

Having worked some on maintaining a stack on both Intel and ARM, it matters less than it did, but it's not a NOOP. e.g. Node packages with native modules are often not available prebuilt for ARM, and then the build fails due to ... .

Re: Intel Problems

#165

Post by optimiz3 »

rapsey wrote: post #108
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…

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

Memory model, execution units, simd instructions...

Re: Intel Problems

#166

Post by cbozeman »

chaorace wrote: post #139
jng wrote: post #101

Earlier quoted context omitted.

Modern process node designations (5nm, 3nm...) are not measurements any more, they are marketing terms. The actual measure of shrinking is a lot smaller than the name would mean to indicate, and not approaching the quantum limits as fast as it may seem.

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 performance and power usage, then when Intel unfucks themselves and refines their 10nm node and 7nm node and whatever-node after that, they'll clearly be more performant than AMD... and Apple's M1.

Process technology is holding Intel back. They fix that, they get scary again.

Re: Intel Problems

#167

Post by yaantc »

dragontamer wrote: post #147
Const-me wrote: post #137

Earlier quoted context omitted.

> you'd expect performance-portability between Graviton ARM and Ampere Altra I agree, that would what I would expect too. Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail. Also, AFAIK on ARM the parts…

> Also, AFAIK on ARM the parts where CPUs integrate with the rest of the hardware are custom. The important thing for servers, disk and network I/O differs across ARM chips of the same ISA. Linux kernel abstracts it away i.e. stuff is likely to work, but I’m not so sure about performance portability. Indeed. But Intel Xeon + Intel Ethernet integrates tightly and drops the Ethernet data directly into L3 cache (bypassi…

> > Also, AFAIK on ARM the parts where CPUs integrate with the rest of the hardware are custom. The important thing for servers, disk and network I/O differs across ARM chips of the same ISA. Linux kernel abstracts it away i.e. stuff is likely to work, but I’m not so sure about performance portability.

> Indeed. But Intel Xeon + Intel Ethernet integrates tightly and drops the Ethernet data directly into L3 cache (bypassing DRAM entirely).

This will be less of a problem on ARM servers as direct access to the LLC from a hardware master is a standard feature of ARM's "Dynamic Shared Unit" or DSU, which is the shared part of a cluster providing the LLC and coherency support. Connect a hardware function to the DSU ACP (accelerator coherency port) and the hardware can control, for all write accesses, whether to "stash" data into the LLC or even the L2 or L1 of a specific core. The hardware can also control allocate on miss vs not. So any high performance IP can benefit from it.

And if I understand correctly, the DSU is required with modern ARM cores. As most (besides Apple) tend to use ARM cores now, you have this in the package.

More details here in the DSU tech manual: https://developer.arm.com/documentation/100453/0002/function...

Re: Intel Problems

#168

Post by billiam »

Though provoking, to be sure, but the problem with his solution of building up Intel's manufacturing arm through spinoff and subsidy is that we simply don't have the labor force to support it, and with much more controlled immigration in the future, it will take decades to build up the engineering education needed to make the US compete with Taiwan, South Korea, and of course China.

Re: Intel Problems

#170

Post by Spooky23 »

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…

That’s a good comparison... CPUs are increasingly a commodity.
Post reply on HN