Live data from Hacker News

Coming Soon: AWS Graviton2 Processor for AWS

aws.amazon.com

141–150 of 191 posts

Re: Coming Soon: AWS Graviton2 Processor for AWS

#142

Earlier quoted context omitted.

they weren't "Caught" - binning is a common practice in the cpu industrty. this isn't a problem

I wasn't talking about binning, I was talking about when you have binned at a certain level, but the product is sold under its capability because you want to maintain the illusion of scarcity of the better parts. AKA its a perfect part, but its being sold with a couple cores disabled or at a frequency below whats its capable of.

You won't even know if it's a perfect part. There is likely a microscopic defect on a part of the cpu they can turn off that disqualified it from being perfect or having a feature of the high end part.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#143
post #114

Earlier quoted context omitted.

MIPS processors have mostly been replaced by ARM already.

Not in routers.

I work in that area. All consumer-grade router/gateway SoCs from Broadcom have been exclusively ARM for several years now. They were MIPS before.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#144

Earlier quoted context omitted.

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.

A commercial EDA tool was one of the use cases benchmarked in the source article.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#145
post #82

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...

And ARM processors these days tend to do the same, translating from the Thumb-2 variable-width instruction encoding into whatever each processor uses internally.

Thumb-2 is for microcontrollers (and not all of them even). Anything unix-capable (Cortex-A series and custom cores) reads fixed width AArch64 instructions.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#146
post #52

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…

Little endian has nothing to do with CISC vs RISC or x86 though. Everybody is little endian today. x86 helped with that historically, certainly, but fundamentally endianness just doesn't matter most of the time, and when it does, little endian makes more sense from first principles.

> Everybody is little endian today.

ACKCHYUALLY, PowerPC (POWER9 included) supports both big and little endian. Software wise, last I checked the Linux kernel, Debian (PPC port), Gentoo, FreeBSD, and several other major projects supported both. I believe KVM also supports flipping VM endianness versus the hypervisor.

Acknowledged, of course, that the spirit of what you said is indeed correct - the majority of systems in active use are little endian.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#147

Earlier quoted context omitted.

This comment seems kinda slanted. AVX-512 debuted on Xeon because datacenter operators asked for it. It does not “downclock a whole chip”, it gates the core where it is active and there’s not even that penalty on the current generation parts. “10nm” is marketing fluff which has little or nothing to do with actual semiconductor construction. “Chiplet” is also marketing-speak for “wow this memory topology is hard to pr…

> AVX-512 debuted on Xeon because datacenter operators asked for it. It deputed on workstation accelerator cards. > It does not “downclock a whole chip”, it gates the core where it is active and there’s not even that penalty on the current generation parts. It very much could thermally throttle more than the one core. > “10nm” is marketing fluff which has little or nothing to do with actual semiconductor construction…

Thank God for this comment I couldn't upvote this enough, got into much more detail that I could have bothered to reply.

2nd Comment into the page and literally everything said in that were wrong.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#148
post #52

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…

Little endian has nothing to do with CISC vs RISC or x86 though. Everybody is little endian today. x86 helped with that historically, certainly, but fundamentally endianness just doesn't matter most of the time, and when it does, little endian makes more sense from first principles.

>and when it does, little endian makes more sense from first principles

Could you explain why little endian would make more sense? While I dont take side in this debate, I have always thought Big Endian would make more sense from First principles.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#149
post #102

Earlier quoted context omitted.

Also, Intel is bizarrely behind on PCIe. Historically, a data center machine with big expensive GPUs or other accelerators also had a couple of expensive Xeons in it. Right now, AMD has a much better offering even ignoring cost. I’m sure someone outside x86 (Amazon? ARM itself? POWER?) will jump in, too.

I think they were intentionally behind. None of their products used/supported pcie4, so it was to their advantage to limit their competitors.

I would bet they were not, PCI-E 4.0 has always been on their Roadmap for 10nm+. The whole 10nm fiasco shifted all of their product roadmap from Modem, Chipset, Controller, to Custom Foundry off the wrong path.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#150
post #107

Earlier quoted context omitted.

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 suspect that, at least for lower-power or lower-area designs, a compact ISA with a friendlier encoding than x86 would be a win. A significant problem with x86 is that a high-performance core needs to decode multiple instructions per cycle, but x86 has a nasty problem that the length of an instruction can’t be determined until it’s fully decoded. I think that modern front-ends try all possible offsets at once and th…

Can you provide a link to the infinite-loop microcode issue?
Post reply on HN