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

181–190 of 191 posts

Re: Coming Soon: AWS Graviton2 Processor for AWS

#181

Post by takeda »

atq2119 wrote: post #178
takeda wrote: post #168

Earlier quoted context omitted.

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.

I don't think big vs little endian makes a difference in terms of hardware implementation. It's just a simple swap of wires.

it's more optimal when you're doing pipelining, for example adding two numbers to do the operation you start from the lowest byte and add them together and move up. With little endian bytes are already positioned in the order you want.

x86 architecture also was big on backward compatibility. You have registers that can be accessed as 8bit, 16bit, 32bit (and I believe 64bit) adding the extra bytes after similarly makes it easier, because the little significant bits are always in the same place.

Again, I don't have extensive understanding of hardware side, so I might be wrong.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#182

Post by privateSFacct »

3fe9a03ccd14ca5 wrote: post #108
privateSFacct wrote: post #63

Earlier quoted context omitted.

It's very hard to buy prebuilt AMD products into the enterprise still in my experience

It’s generally hard to buy AMD CPUs period.

I can buy lots of AMD CPUs and motherboards online - tons available. But prebuild AMD from Dell? No SKU's. I think it's going to be a MAJOR lag there.

In part this may be because AMD bios stability has historically been poor - perhaps folks don't want the headaches? But intel bios security with ME has also been poor - soo...

Re: Coming Soon: AWS Graviton2 Processor for AWS

#183

Post by solidasparagus »

goosehonk wrote: post #180
solidasparagus wrote: post #101

Earlier quoted context omitted.

Uhh source on AVX512 not downclocking on modern CPUs? We benchmarked ML workloads on the newest chips the cloud had to offer and the slowdown was a significant problem because, as the parent comment said, it is very hard to reason about whether the benefits of vectorized ops will outweigh the the reduced clock speed. Sometimes it does and sometimes it does not - which is a major problem when you have to specify instr…

It is a major problem to figure out what instructions to use but it's a lot more nuanced than you seem to imply. In the first place you seem to assume that "not running at the max turbo speed that's printed in the marketing literature" is equivalent to "downclocking". However, there are a huge number of reasons why a core might not clock up, including the number of active cores on the package. The first Xeons that sh…

No, when we used MKL, the workload was slower and turning off MKL made the workload faster. The marketing is irrelevant - using vectorized instructions slowed down the workload in practice which is all that really matters. The Intel teams we were working with explained it as being due to the slower clock speeds caused by vectorized instructions. I don't really know, but it seems fair to assume that they do.

It will be interesting to test Ice Lake when they make it to the cloud, hopefully some time late next year, but until we can actually use Ice Lake, Sky Lake is what AVX512 will be judged on.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#184

Post by goosehonk »

solidasparagus wrote: post #183
goosehonk wrote: post #180

Earlier quoted context omitted.

It is a major problem to figure out what instructions to use but it's a lot more nuanced than you seem to imply. In the first place you seem to assume that "not running at the max turbo speed that's printed in the marketing literature" is equivalent to "downclocking". However, there are a huge number of reasons why a core might not clock up, including the number of active cores on the package. The first Xeons that sh…

No, when we used MKL, the workload was slower and turning off MKL made the workload faster. The marketing is irrelevant - using vectorized instructions slowed down the workload in practice which is all that really matters. The Intel teams we were working with explained it as being due to the slower clock speeds caused by vectorized instructions. I don't really know, but it seems fair to assume that they do. It will b…

It's a good thing you measured it :-) Programs that do a little bit of 512x512 FMA mixed in with other stuff will not benefit from AVX-512 but can suffer from the heat it generates, or from the hiccup when the CPU turns the FMA unit on and back off.

Codes that can do a lot of 512b FMA consecutively will benefit very greatly, and pay a small penalty (up to 25%) in terms of throughput for everything else.

Codes that use non-multiplier stuff that's just marketed as AVX-512, like VBMI2, also benefit greatly and without any penalty.

People with AMD CPUs don't get a choice. Hard to see how this accrues to Intel's mistakes column.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#186

Post by solidasparagus »

goosehonk wrote: post #184
solidasparagus wrote: post #183

Earlier quoted context omitted.

No, when we used MKL, the workload was slower and turning off MKL made the workload faster. The marketing is irrelevant - using vectorized instructions slowed down the workload in practice which is all that really matters. The Intel teams we were working with explained it as being due to the slower clock speeds caused by vectorized instructions. I don't really know, but it seems fair to assume that they do. It will b…

It's a good thing you measured it :-) Programs that do a little bit of 512x512 FMA mixed in with other stuff will not benefit from AVX-512 but can suffer from the heat it generates, or from the hiccup when the CPU turns the FMA unit on and back off. Codes that can do a lot of 512b FMA consecutively will benefit very greatly, and pay a small penalty (up to 25%) in terms of throughput for everything else. Codes that us…

It's not really an Intel mistake, but it is an Intel problem. In ML, the ASICs are coming. NVIDIA is pretty much guaranteed to maintain a leadership position in this space because their software layers are dominant. Intel's ML leadership position is quite tenuous because the killer ML features don't work quite well enough for the premium. MKL should be a solid moat, similar to NVIDIA's CUDA and CUDNN, but if it requires serious effort to get the benefits, it becomes more palatable to spend that effort on ARM-based servers or custom hardware like Inferentia which are meaningfully cheaper. Maybe Ice Lake will fix this, but Intel is running out of time to convince people that Intel chips should remain the first choice in ML.

AMD isn't relevant in this space AFAIK.

Re: Coming Soon: AWS Graviton2 Processor for AWS

#187

Post by SideburnsOfDoom »

PeterCorless wrote: post #174
SideburnsOfDoom wrote: post #156

Earlier quoted context omitted.

I am gathering that it's a chip, a CPU chip, seem to be ARM architecture not intel x86; and is an important chip or will be due to this? I don't know why though.

Here's our take. This is big. https://www.scylladb.com/2019/12/05/is-arm-ready-for-server-...

I'm still reading between the lines here, which is frustrating and doesn't reflect well on the journalism; So you say:

"AWS announced in late 2018 the EC2 A1 instances, featuring their own AWS-manufactured Arm silicon"

...

"AWS during its annual re:Invent conference announced the availability of their new class of Arm-based servers, the M6g and M6gd instances among others, based on the Graviton2 processor."

So the Graviton2 is made by Amazon as well? Under licence from ARM, I mean, like other ARM design chips.

_edit_ Looks like it, yes. Here is the context necessary to understand the story:

https://www.wired.com/story/new-amazon-chips-cloud-computing...

https://www.nasdaq.com/articles/amazon-amzn-to-release-new-s...

Re: Coming Soon: AWS Graviton2 Processor for AWS

#188

Post by SideburnsOfDoom »

SideburnsOfDoom wrote: post #141

What is "Graviton2" in this context? There's no Wikipedia page for it, and the regular google search results all loop back to this AWS announcement.

Here is the context necessary to understand the story:

https://www.wired.com/story/new-amazon-chips-cloud-computing...

https://www.nasdaq.com/articles/amazon-amzn-to-release-new-s...

Re: Coming Soon: AWS Graviton2 Processor for AWS

#189

Post by mister_hn »

pjc50 wrote: post #158
mister_hn wrote: post #136

Earlier quoted context omitted.

About point i, using different languages than native is really weird and in the age of green computing really not efficient at all. UIs based on JavaScript, Python or even Java are heavier and less efficient than what a platform can do with native compiled code. There are now also loads of possibilities to build native code, squeezing the best performance, especially for critical systems. I still don't understand why…

Speed of development currently trumps everything else. Developers are expensive, electricity is cheap, and software changes at a high rate. If we could reduce the "churn" perhaps people could transition to optimised versions, but optimisation makes rapid change harder.

as PoC sure, but as productive system, I would always rely on the best performance out there

Re: Coming Soon: AWS Graviton2 Processor for AWS

#190

Post by BeeOnRope »

atq2119 wrote: post #169
ksec wrote: post #148

Earlier quoted context omitted.

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

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

That's true with big endian too, but you just have to store your integers in the opposite way as you would on little endian: with the MSB at the lowest address (which of course is the same as the distinction between little and big endian in the first place).

Basically the bigint layout has to be compatible with the the endianess.

I don't know what bignum implementations do in practice on big endian systems though.

Post reply on HN