Hacker News Reader

Comment by forty | Hacker News Reader

Some anecdotal experience:

- we switched our nodejs workload to graviton (c6g from c5), and it resulted in needing more instances, which ended up costing nearly exactly the same price

- ARM is annoying in practice for some stuff (we build our docker images on our CI which is on premise and not ARM)

- AWS pushed a bit to have us move to graviton

- Where are the c6a ? :)

View on HN

I moved a .net core project to t4g from t3 and it resulted in lower cpu utilisation and requests being returned quicker.

Can you describe more about the nature of your workloads?

Those are HTTP APIs which are mostly reading from MySQL and S3.

They are running on nodejs 12 (soon 16 ^^). They are using quite a lot of CPU, probably mostly due to having to parse large amount of JSON, and a bunch of cryptographic operations (mostly hmacs, AES - we are only using nodejs built-in crypto primitive) - but I don't know for sure to be honest - hence the choice of C type instances.

This workload looks really well suited for x86 cores. The x86 architecture has big advantages in both crypto and fast string parsing. It's interesting that graviton got cost parity given what you said.

Hmm, I wish this sort of stuff was mentioned more on HN threads. Love to know when things are best suited for ARM and x86, etc.

My experience with today's cloud arm offerings (gravaton/ampere) is node.js overperforms on arm relative to benchmark scores. Crypto has a definite handicap on arm. I've found that AMD underperforms on node.js. Seems the arm offerings are slanted to integer style workloads.

Other packages and databases have brought me pain to use on arm. And anywhere I encounter pain I just don't migrate.

I'd say it's a good idea to try out on your specific workload and figure out what works best for your use case. The good news is that it's probably very very easy to switch and try all the CPUs offered by your cloud provider.

The only "big advantage" I can think of is that libraries like simdjson usually are still written for AVX first, NEON later. Otherwise it's not so clear cut, especially if not using any libraries like that.

And SVE even later.

SVE hardware has been made of unobtainium so far. Graviton3 will change that pretty soon though.

Also, the datapath is a lot wider: NEON only does 16 bytes per vector, while Intel has fixed most of its frequency issues and can go up to 32 bytes per vector without throttling. AVX is also a lot more expressive, and can do more per instruction.

I have no idea if nodejs is taking advantage of this to be honest.

SVE2 seems great though [0]. It looks at least as nice to use as AVX512. Graviton3 has SVE2, though I'm not sure what vector length they use.

[0]: https://developer.arm.com/documentation/ddi0602/2021-09/SVE-...

Reply on news.ycombinator.com