Live data from Hacker News

Coming Soon: AWS Graviton2 Processor for AWS

aws.amazon.com

161–170 of 191 posts

Re: Coming Soon: AWS Graviton2 Processor for AWS

#161
post #60

Earlier quoted context omitted.

That was 100G Omni-Path (not Ethernet compatible) which has been subsequently canceled, I guess due to lack of demand. Intel's 100G Ethernet NICs were years behind other vendors due to the 10 nm fiasco.

Intel had always said they were behind because they wanted to be. In other words, they didn't think 100G was on the rise. I tend to believe them since nic asics are much easier to make than an x86 processor.

It's a good tenant of personal responsibility to say that one's owns actions are the result of one's own choices.

So by that logic, I suppose they wanted to be? :-)

Re: Coming Soon: AWS Graviton2 Processor for AWS

#162
post #36

Earlier quoted context omitted.

The capital cost is only one part of the equation. These modern ARM cores have insane per-watt performance and that’s what adds up for horizontally scalable services.

RISC-V chips will handily beat ARM on performance per watt, given similar specs and fabrication technology. The margin is not insanely large but it's definitely substantial in existing benchmarks.

Why?

Re: Coming Soon: AWS Graviton2 Processor for AWS

#163
post #146
post #52

Earlier quoted context omitted.

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…

ARM too.

https://developer.arm.com/tools-and-software/open-source-sof...

See: > AArch64 GNU/Linux big-endian target (aarch64_be-linux-gnu)

Re: Coming Soon: AWS Graviton2 Processor for AWS

#164
post #150
post #107

Earlier quoted context omitted.

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?

One of them: https://xenbits.xen.org/xsa/advisory-156.html

Re: Coming Soon: AWS Graviton2 Processor for AWS

#165
post #153

Earlier quoted context omitted.

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

IoT is a thing .. that Intel failed to get into. They don't have anything that scales down that well. That market is dominated by ARM, implemented by all sorts of lower tier vendors like MediaTek. FPGAs really need a tooling unlock to take off so they can be useful to people who haven't been on the ASIC design course. > It won't make sense for anyone else in the US to compete TSMC?

TSMC isn't a US company.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#166
post #153

Earlier quoted context omitted.

IoT is a thing .. that Intel failed to get into. They don't have anything that scales down that well. That market is dominated by ARM, implemented by all sorts of lower tier vendors like MediaTek. FPGAs really need a tooling unlock to take off so they can be useful to people who haven't been on the ASIC design course. > It won't make sense for anyone else in the US to compete TSMC?

TSMC isn't a US company.

Correct, but they do a lot of fab work for other companies. It's not absolutely necessary to have your own fab to be competitive unless your volumes are huge... at which point you can afford it.

Apple have $245bn on hand, so they could have a dozen $20bn fabs if they felt the need. Bezos has $180bn and no idea what to do with it.

https://www.cnbc.com/2019/01/29/apple-now-has-tk-cash-on-han...

Re: Coming Soon: AWS Graviton2 Processor for AWS

#167
post #143

Earlier quoted context omitted.

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.

Caviun also went ARM, and is now owned by Marvell.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#168
post #64

Earlier quoted context omitted.

You are presenting argument in favor of little endian, yet you're provide enough information that is only useful for someone who already knows the answer.

The answer is also only useful to those who know it? I mean, nerds love to shout about the superiority of this or that, but they're mostly just parroting their tribe motto. If you have reason to really care about endian order, I would encourage you to do more research than you'll find in an HN comment. Perhaps there's even more than one right answer depending on circumstance.

I don't have too much knowledge in that area, but my understanding is as follows: for a software engineer big endian simpler to use, for hardware engineer little endian is simpler to implement.

I think it's similar to scientific calculator vs RPN calculator.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#169
post #148
post #52

Earlier quoted context omitted.

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.

There are two main applications where I find little endian is more logical: big integer implementations, and bit stream encoding.

With big integers, the logic is simple: if you use little endian, you can operate on the same memory representation of the bigints quite easily with machine integers of different sizes.

A similar phenomenon happens with bit encoding. Let's say you want to encode a sequence of 25-bit integers tightly packed in memory. How do you do that? With little endian, you get a somewhat more natural representation especially for seeking into the bitstream (especially for architectures that allow unaligned memory accesses).

Post reply on HN