Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coming Soon: AWS Graviton2 Processor for AWS

aws.amazon.com

Post reply on HN
Print view View original

71–80 of 191 posts

Re: Coming Soon: AWS Graviton2 Processor for AWS

#71

Post by goosehonk »

localhost wrote: post #6
ChuckMcM wrote: post #2

This is an interesting twist in the processor wars, here is the #1 cloud company that is turning its profits in providing cloud services in to processor R&D to build new CPUs. This is a much more important announcement than the press is giving it credit for. I have argued in the past the Intel "lost" the smartphone CPU war because Apple decided not to wait for them to come up with some high margin processor compromis…

AMD is also eating Intel's lunch in datacenter. Last time I checked (I don't keep track of Intel pricing) AMD had a 5x price/performance advantage over Intel at the launch of EPYC ROME.

Have there been any published benchmarks of relevant datacenter workloads on this CPU? I certainly haven’t seen any. The previous generation EPYC was really slow on branchy code, despite looking ok on ffmpeg benchmarks and the like.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#72

Post by pepemon »

dogma1138 wrote: post #66
jonstewart wrote: post #47

Earlier quoted context omitted.

Well, and for 25-30 years, everyone’s been crowing about how they were doomed to fail because of x86 as a CISC design. Intel killed off most RISC competitors as Moore’s Law held in the 90 and they could just add more transistors to turn x86 into a facade. But that increase in transistors and doing whatever possible to keep x86 performant meant they were doomed to lose the power/performance war that came with mobile p…

All modern x86 CPUs are essentially “RISC” CPUs that translate x86 instructions into uOPS so they already do what you want to do. I’m not seeing why the higher level x86 instruction set needs to be jettisoned or killed off...

> All modern x86 CPUs are essentially “RISC” CPUs

Where can I read more about that?

Re: Coming Soon: AWS Graviton2 Processor for AWS

#73

Post by spamizbad »

goosehonk wrote: post #69
jonstewart wrote: post #47

Earlier quoted context omitted.

Well, and for 25-30 years, everyone’s been crowing about how they were doomed to fail because of x86 as a CISC design. Intel killed off most RISC competitors as Moore’s Law held in the 90 and they could just add more transistors to turn x86 into a facade. But that increase in transistors and doing whatever possible to keep x86 performant meant they were doomed to lose the power/performance war that came with mobile p…

ARM has never enjoyed a Op/J advantage over x86. They have low-power designs, yes, but they don’t do more work for a given amount of energy. x86 won fair and square. The risc people failed to foresee that instruction density would be extremely important to performance. Intel didn’t beat them with physics. CISC is just fundamentally better.

The writing was on the wall in the early 90s. The SuperH ISA basically gave you the best of both world's: Fixed-width, relatively easy to decode instructions that were 16-bit, rather than 32 bits of many RISC ISAs.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#74

Post by Twirrim »

walrus01 wrote: post #12

Whatever happened with the Qualcomm Centriq ARM based server CPU? It never became available at any reasonable price in small quantities for software development/test/prototyping as something you could actually buy an ATX motherboard + CPU together and install (redhat, centos, debian, freebsd, whatever) on. https://en.wikipedia.org/wiki/Qualcomm_Centriq https://www.tomshardware.com/news/qualcomm-server-chip-exit-... h…

Amazon can afford to go all-in on building their own chips, with a solid goal of moving (almost?) all their AWS services over to them (I would bet good money that will become a requirement for services). They're also more forward thinking and experimental than most companies are, or can afford to be. The x86 is the "no one ever got fired for buying IBM" of CPUs.

This promises to be quite interesting. If Amazon can prove ARM as viable on their scale, that'll help companies like Qualcomm who were struggling to drum up attention from the more traditional markets.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#75

Post by grantisu »

pepemon wrote: post #72
dogma1138 wrote: post #66

Earlier quoted context omitted.

All modern x86 CPUs are essentially “RISC” CPUs that translate x86 instructions into uOPS so they already do what you want to do. I’m not seeing why the higher level x86 instruction set needs to be jettisoned or killed off...

> All modern x86 CPUs are essentially “RISC” CPUs Where can I read more about that?

If you can work around the formatting issues, there's some classic articles on Ars Technica, e.g. http://archive.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

Re: Coming Soon: AWS Graviton2 Processor for AWS

#77

Post by ninkendo »

tverbeure wrote: post #49
zozbot234 wrote: post #30

Earlier quoted context omitted.

How many of those "precompiled binaries" are truly performance critical? If it's just a single component, you can run it in qemu-user mode and still come out ahead overall.

How many of those precompiled binaries are performance critical? How about all? From the software that runs for hours to compile a model, the software that calculates results, to the interactive analysis software that needs to load GBs of data. The whole reason to run these things on a server farm is that you need large and fast machines that are better shared to make sure they get optimal use of the machine and of t…

Is this the archetypal AWS customer that drives the majority of intel’s sales to AMZN? That not only has lock-in with a closed source vendor, but that vendor is not agile enough to give ARM binaries for AWS workloads? Doubtful IMO. Maybe for EDA and CAD/CAM setups, but somehow I doubt those are enough to keep Intel as we know them afloat. Intel has huge reason to fear ARM on the server.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#79

Post by Abishek_Muthian »

dman wrote: post #10

If Intel makes it out of the current soup with its dominance intact it will make for an interesting case study. Think they are facing the perfect storm on multiple fronts. a. The 10nm process fiasco b. Missing the chiplet concept c. ISA fragmentation - AVX512 which was supposed to be the next big thing was server CPU side only till recently and downclocks the entire chip when used making it extremely hard to reason a…

>ARM eating their lunch in mobile.

Not just mobile. Obviously, that's the content of the OP. But, ARM based servers have been available for quite a while for dirt cheap prices[1] and they are great for workloads where ARM libs are available.

Edge ML inference[2].

[1]https://www.scaleway.com/en/virtual-instances/arm-instances/

[2]https://developer.nvidia.com/embedded/jetson-nano-developer-...

Re: Coming Soon: AWS Graviton2 Processor for AWS

#80

Post by etaioinshrdlu »

goosehonk wrote: post #69
jonstewart wrote: post #47

Earlier quoted context omitted.

Well, and for 25-30 years, everyone’s been crowing about how they were doomed to fail because of x86 as a CISC design. Intel killed off most RISC competitors as Moore’s Law held in the 90 and they could just add more transistors to turn x86 into a facade. But that increase in transistors and doing whatever possible to keep x86 performant meant they were doomed to lose the power/performance war that came with mobile p…

ARM has never enjoyed a Op/J advantage over x86. They have low-power designs, yes, but they don’t do more work for a given amount of energy. x86 won fair and square. The risc people failed to foresee that instruction density would be extremely important to performance. Intel didn’t beat them with physics. CISC is just fundamentally better.

I had assumed the opposite, that ARM was better in terms of Op/J. Can you provide a reference to make it certain?

Also, I wonder if the low density of RISC could be countered by introducing execution of compressed/zipped machine code. Some compressors like brotli are highly tuned to the expected type of data to be compressed and are very compact. All entry points to basic blocks in the code are generally known at compile time, so it can be ensured that the jump destinations are decompressible without any context, avoiding the slow process of needing to scan backwards to start decompressing...

Post reply on HN