16nm ARMv8 SoC for servers and workstations

Re:16nm ARMv8 SoC for servers and workstations by sargun on Friday June 16, 2017 @09:00PM (#14573696)

I did a bunch of testing with ARM (ThunderX) for an IPC workload using this codebase: github.com/sargun/wat. Unfortunately, it no longer runs on ARM, because I'm using inline assembly.

The ThunderX's power comes from the fact it's a 48-core CPU, which is awesome for web workloads. The problem comes in that inter-core transfer is ridiculously slow. To make a 64-byte RPC (return / response), was in the area of ~1100 nanoseconds, whereas x86-64 was on the order of 500 nanoseconds on a 2 generation old CPU. Testing on a more modern CPU cut the time further.

I'd love to see ARM either catch-up in single-core performance, or multi-core performance, but until then I don't feel like it's viable.

[ Parent | on HN ]

Re:16nm ARMv8 SoC for servers and workstations by bhouston on Friday June 16, 2017 @11:05PM (#14574056)

According to the article this CPU as compared to the ThunderX has 80% faster integer performance for the whole CPU and 2x faster integer performance per core - so major a improvement:

http://images.anandtech.com/doci/11189/APM-X-Gene-3-performa...

[ Parent | on HN ]

Re:16nm ARMv8 SoC for servers and workstations by sargun on Tuesday June 20, 2017 @03:56AM (#14592847)

Turns out that number crunching isn't what my CPU is doing most of the time. :-/.

[ Parent | on HN ]

Re:16nm ARMv8 SoC for servers and workstations by m-j-fox on Friday June 16, 2017 @09:31PM (#14573793)

Interesting! Cavium's network processors running bare-metal have features to ensure no core is ever idle. Maybe at the expense of latency. The idea probably doesn't translate to running a bunch of virtual servers. You probably do better with a shared-memory abstraction than a network. Or, disappointing numbers may just reflect the fact that individual cores are slow. Bad news either way.

[ Parent | on HN ]