Hacker News Reader

Comment by yazaddaruvala | Hacker News Reader

FWIW, it’s unlikely AWS will ever shut down it’s Intel hardware. In a growing Cloud market, Graviton is likely just a way for AWS to access more of the semiconductor production than other clouds. They will likely keep buying from Intel at Intel’s price point, as long as it remains profitable for them.

The biggest thing not being talked about that hurts Intel is AWS’ pool of Intel CPUs that currently run S3, SQS, Dynamo, etc (m3s, c4s, etc) all being released to the public and offered at such a discount (especially on the spot market) that new onprem purchases (i.e. new Intel chips) are not cost effective.

Disclaimer: I used to work at Amazon but never in AWS. This is all based on public speculation.

View on HN

AWS and other compute providers will continue to buy what customers want, but:

1) if their managed services (RDS, DynamoDB, etc) can run on ARM and it provides a better price/performance ratio, they'll use that internally, thus needing less x86 hardware

2) if most customers can run on ARM (interpreted languages run out of the box, compiled ones need more effort but is still doable) and it's better priced than x86 there is less demand on x86 again.

> Compiled ones need more effort

I think Go needs a flag specified at compile time to work on ARM. Instead of `go build`, run `env GOOS=linux GOARCH=arm64 go build`.

Rust is similar, except it requires the appropriate toolchain to be installed first (1-liner).

It’s probably less effort what I’ve described because there are GitHub Actions that will generate appropriate binaries out of the box.

It remains that easy until your Go/Rust project relies on libraries written in other languages, say C.

(This holds true for JS/python/… too.)

Relying on libraries written in C is not an issue if the library doesn't make assumptions about / isn't tied to, a particular architecture. Some do but most (especially newer codebases written to C11 and beyond) don't.

There's also the issue of performance-optimised assembly routines, which impacts many native libraries doing things such as crypto, image processing, etc.

Right. But even then it does not become that much worse.

Just tell Go to use the appropriate cross compilation chain for the C bits, e.g. `apt install gcc-aarch64-linux-gnu` and set the `CC=aarch64-linux-gnu-gcc` environment variable to compile for arm64. Compilation becomes a bit slower, but it's still manageable.

It's that easy thanks to the foundations laid by the distribution that ships a solid cross-compiler setup (in this example, thank you Debian!) and of course the brilliance of the Go design and toolchain.

The issue is that someone has to initially write the code to emit the native assembly/machine code for each architecture that a given compiler supports. (i.e. assuming it actually emits native code and not code for another compiled language like C/C++) The flag simply means that someone has already done that work for a particular language on a particular architecture.

Absolutely, it’s a lot of work. Just saying the work had already been done for Go and Rust even before M1 made it mainstream.

RDS is a huge one. Switching to Graviton meant that our instances are significantly cheaper and just as fast. And there was zero switching friction.

The way I see it, in the long run AWS will stop net-adding Intel instances. Only decommissioning and re-adding the existing ones. While Graviton-based instances will continue growing with the growth of the cloud market (and global economy), Intel will be considered legacy the same way we view mainframes as legacy.

I think when discussing “Intel instances” over a long enough time horizon we need to not couple it with x86.

I do think x86 will be phased out as you suggest. I feel either Intels foundry division and/or chip designs for ARM and/or RISC-V will very likely get incorporated into Graviton-X (and similar) if only as a bargaining tactic between Intel vs TSMC and Intel vs Qualcomm vs ARM.

Reply on news.ycombinator.com