Ampere Altra 80-core ARM CPU | Hacker News Reader

Ampere Altra 80-core ARM CPU

servethehome.com

183 pointscameron_b67 comments

"What we will note is that Ampere de-rated both the AMD EPYC 7742 and Xeon Platinum 8280 results by 16.5% and 24% respectively. This was done to adjust for using GCC versus AOCC2.0 and ICC 19.0.1.144. Ampere disclosed this, and it is a big impact. Arm servers tend to use GCC as the compiler while there are more optimized compilers out there for AMD and Intel."

If I read this right, they reduce their competitors' benchmarks because they have better compilers? Can anyone justify this?

GCC is the open-source compiler that is used all over. Not every AMD EPYC system people are using AOCC2.0 on. Likewise, people do not only compile code on ICC that is used on Intel Xeons. Arm has focused efforts on getting optimizations in GCC because it is so popular.

Generally, that is why we prefer to publish "compiler optimized" as best-case performance as well as "GCC" as more of the least common denominator. Both sets of data points are important.

Official SPECint published numbers will not use GCC because the organizations that submit them always want to see the best performance. Ampere used a scaling factor off of published numbers.

If you want to see the impact, we have some numbers from my ThunderX2 review: https://www.servethehome.com/cavium-thunderx2-review-benchma...

You can see the impact clearly there even though that was from a few years ago. Cray has a better performing compiler for ThunderX2 but we did not get to use it due to licensing restrictions.

I hope that helps. The bigger need is for more data since this is one view of performance. There are other needs as well such as FP performance.

Nice to know both Patrick and Ian ( Anandtech ) are on HN :)

When could we expect a review on Altra?

Ha! Sometimes it surprises people that we know each other and hang out a bit when we are in the same town.

On an Altra review. Great question. I have been bringing it up for some time and live 15 minutes from their headquarters. The invitation is open on our end.

If you assume that most real customers use a regular compiler like GCC or Clang then benchmarks using tuned compilers like AOCC (never heard of it before today) or ICC are unrepresentative. However, the proper way to make such a comparison would be to run benchmarks using GCC on all the chips, not to apply magic derating factors. Shame on Ampere for such voodoo benchmarketing.

Oh, and don't miss the 3.0 vs. 3.3 GHz.

Very little software is actually compiled with AOCC and ICC. Really Intel and AMD are being dishonest by publishing benchmarks that don't match reality. Of course it's different if you're compiling everything yourself, then those benchmarks might be relevant.

> It's different if you're compiling everything yourself, then those benchmarks might be relevant.

And even if you do it's irrelevant. Most common large/important frameworks won't compile with proprietary compilers.

Doing Bench's with ICC, XLC or other is hypocritical and often does not reflect anything useful.

Only the HPC world can afford to recompile everything with proprietary compilers and justify the man power to do so. And even so, they already have passed most compute intensive kernels on GPGPU with cuda a long time ago.

No, the correct thing to do is to publish multiple columns showing performance under the different compilers. Large co do use the specific compiler that will give them better performance. I know many big software compiled with ICC. Then, there is the lack of tlak about MSVC. That's one standard compiler used extensively.

In benchmarking you have two choices: publish the real numbers or not. Which option you choose marks you as honest or not.

You can argue about why the numbers for your product are lower in the discussion section of your report. Not in an asterisk.

IBM, Intel and PGI reign on HPC.

"Really Intel and AMD are being dishonest by publishing benchmarks that don't match reality"

People can discard with the various SPEC* benchmarks as unrealistic -- they generally are -- but this is a bridge way too far.

The whole point of the SPEC* benchmarks is that you bring out the best of the best and do everything you can to achieve the pinnacle of performance.

And those SPEC* benchmarks are most interesting, and most applicable, to HPC users, who actually do use hardware-specific compilers. Of course another person mentioned that "everything is on GPUs now" (it isn't): If it's on a GPU, then you don't need a 60 core CPU. If it's on a GPU, then SPEC* benchmarks aren't relevant.

Assuming you are going to buy a server to run gcc compiled code, that seems fair. After all just about every linux distro uses gcc of clang/llvm to compile their binaries.

Using Intel's compiler or AOCC to compile binaries for normal server use is pretty rare.

STH has the slides and some analysis: https://www.servethehome.com/ampere-altra-80-arm-cores-for-c...

Yes, was about to post that, much better than the PR. Anandtech also has its take on it as well.

https://www.anandtech.com/show/15575/amperes-altra-80-core-n...

Ok, we've changed to that from https://amperecomputing.com/ampere-altra-industrys-first-80-.... Thanks!

Hi dang. I know you did not have to do that but I just wanted to say from the STH team we appreciate it. Have a great day.

192 PCIe Gen4 lanes in 2P platforms - looks like they're optimizing for next-gen storage bandwidth or potentially GPU / TPU integrations. This could be interesting from a company that's been busy working on their B-to-B sales, hopefully solving for problems that cloud platform providers actually have.

For context this is an evolution of the Applied Micro X-gene (I believe this is the 3rd generation). The 1st gen was the famous Mustang, one of the first Aarch64 chips generally available that ran Linux. I still have one in my loft somewhere.

Edit: I should note that if you used the X-gene 1 it was very slow, albeit a reliable workhorse for early 64-bit ARM Linux development. These newer chips have far better performance.

The meandering paths that these different processor families take is interesting on its own. eMag and the Thunder X2 are expensive to develop but so promising that the product seems to find a new gear even when one company runs our of steam developing it. That or they find a new C-Suite group that has the same opinion as me.

Thank You, there were too many ARM Server Startup, merger and acquisition I sort of lost count. I think we are left with Ampere and one from Marvell.

I sort of record Applied Micro were doing POWER as well, is that still the case with Ampere?

Yes, seems like Ampere is the big public server player now.

Marvell bought Cavium which has the ThunderX line. (ThunderX2 being a rather HPC-oriented chip, I think there's a supercomputer already built with it.) Marvell also makes networking-gear-oriented smaller chips (e.g. Armada 8k), one of which is in my little ARM Desktop (MACCHIATObin) :)

NXP (Layerscape) and Mellanox (BlueField) also make network-oriented chips that have around 24 Cortex-A72 cores. NXP's is in SolidRun's newer workstation product.

Meanwhile Amazon bought Annapurna Labs and they make the Graviton (2) for the AWS cloud. This isn't something you can touch physically but it's going to have the biggest impact of all things. This is the real confirmation that Arm servers are legit and the x86/amd64 monopoly is over.

There's also Huawei HiSilicon's Taishan/Kunpeng stuff, which you apparently can buy if you're a serious business, but now it's available in the public Huawei Cloud, but only for the Chinese region it seems??

Oh and Fujitsu is making some epic chip with HBM2 memory and the new Scalable Vector Extensions. But that's only available if you're making supercomputers.

And Nuvia is going to be a thing eventually.. they have not announced anything yet, we have no idea which ISA they are even going to use (could be RISC-V or POWER or SPARC for all we know) but a prominent UEFI/ACPI-on-Arm person is now their VP of Software and is still referring to the Arm ecosystem as "we" https://twitter.com/jonmasters/status/1234734345350369281 :)

And yeah.. press F to pay respects for Qualcomm Centriq and AMD Seattle.

>And Nuvia is going to be a thing eventually..

According to techcrunch they have confirmed it will be built on top ARM.

Edit: That is assuming they sort out their lawsuit with Apple.

[1] https://techcrunch.com/2019/11/15/three-of-apple-and-googles...

I see Ampere eMag is supported by OpenBSD (https://www.openbsd.org/arm64.html) :-)

It had "only" 32 cores. I still find it a lot.

I guess it would be easy to port OpenBSD to the Altra since it boots from UEFI.

Yes. There is no "porting" with new SBSA/SBBR systems — only fixing bugs and/or adding quirks :)

On FreeBSD for the eMAG, we've had to:

- ignore a wrong value for UART access width https://svnweb.freebsd.org/base?view=revision&revision=34622... (IIRC Ampere did fix the value in the newer FW revisions)

- restore another register after calling EFI runtime services https://svnweb.freebsd.org/base?view=revision&revision=34699...

- fix some PCIe things we were doing wrong https://svnweb.freebsd.org/base?view=revision&revision=34792... https://svnweb.freebsd.org/base?view=revision&revision=34793...

- fix some memory map things https://svnweb.freebsd.org/base?view=revision&revision=34958...

Ampere eMAG was X-Gene 3 but Altra appears to have little or no X-Gene IP in it.

the key issue when compared to Epyc is that this is mono-die, and not much faster (even with metrics straight from Ampere). Mono-die means that the die is huge, the yield is low, it's probably pretty expensive to produce (and the reason why they went for 32MB cache, well below Arm's recommendations, core count is a bigger seller than cache it seems). Unless they get massively better performance (they don't), this has no chance vs a multi-die solution which has a much better yield. Intel is cornered in a similar situation right now. The same applies to Graviton, this stands absolutely no chance in the long run.

Not saying that the future has to be multi-die, but if it is not, then it has to be way faster than the cheaper-to-manufacture competition.

Huge die doesn't really matter if you have the ability to suffer defects on it and still turn out a quality product.

If they put 100 cores on every die but only activate 80 of them then that means they can tolerate absolutely HORRIBLE per-processor yields and still make chips that work. Their yields could actually be BETTER than with chiplets because they can afford so many problems.

Not saying that this is true, BTW, just that it's theoretically and practically possible.

The larger the die the greater the likelihood of defects. Also the larger the number of defects per mm/sq.

>the key issue when compared to Epyc is that this is mono-die,

This die cost metrics is way overblown and its narrative is too narrowly focused. Especially on ARM Server where unit cost dynamics with ARM IP along with much higher margin on server CPU lower the multi die BOM benefits. And the same definitely does not apply to Graviton, which Amazon owns the whole stack.

Amazon owns nothing, not the ARM IP nor the manufacturing chain (TSMC or Samsung most probably), in that field it's not a big player. It owns what it does with Graviton, that's pretty much it.

Else yield obviously counts, that's what stands in the way of this CPU having more cache or 160 cores, for what it's worth, so it has to count for something obviously. The multiple tiers in every cpu manufacturer line up is also a consequence of yield, so it's very much not a minor element of the equation

I disagree.

More chips per wafer results in more yield, less chips with potential flaws.

> Dr. Hansch’s research at Universitat Munchen for example, shows how as die size increases manufacturers realize an accelerating yield loss and thus accelerating manufacturing cost. Using their model, assuming best-case defect densities, AMD’s small chiplet approach achieves 90% yields vs. Intel’s 30%-40% yields from its large, monolithic die approach. [1]

[1] https://www.barrons.com/articles/amd-stock-can-gain-87-fund-...

Since you actually did some research and posted a link I will go along with those numbers.

>We estimate Intel’s total server die cost at $162 per good server chip while AMD costs about $108 per good server package.

EPYC is 8 Die + an IOD, assuming the massive IOD of ~420mm2 only cost $10 ( That is suggesting GF are selling 14nm / 12nm Wafer at ~$1.2K, even under the AMD WSA with GF would likely not be feasible ), that number suggest the cost per Compute die would be ($106 - $10)/8 = $12, which is again off by quite a bit. Compared to equivalent die size cost of Intel, which is not even accurate because intel do not require the 65%+ Gross Profit Margin from TSMC and it is on an older mature node. And its yield are too pessimistic, we do not have any numbers from Intel on defect per mm2, but taking a guess from Nvidia's massive ~800mm2 die isn't too far off.

So again, let's assume both of those numbers are "relatively" correct. Do you think $62 would matter for an Intel® Xeon® Platinum 8280 Processor with Recommended Customer Price of $10K? Or the same die they are selling at the lower end for $3K?

While it would definitely be good to have those $62 as profits, the reality is on the server market its advantage is relatively minimal.

The bulk of the benefits of Chiplet approach is that you can reuse one or two designs and have it deployed across the whole range of market from Server to Desktop. As design cost increases with Pure Play Foundry such as TSMC this is extremely important for Fabless Design company like AMD, it cost them hundreds of million per design variation. Intel would have that problem down the road but it is mostly migrated for now because all of their design and fabs are in house, and would not cost them as much.

And since the original post was specific to ARM and Server, which has a different market dynamics in cost, you have less R&D as compared to x86 market. In ARM you are paying for IP price on the N1 core and some Interconnect, and those cost of Spread among all ARM players. Hence the conclusion of Chiplet is everything isn't as clear cut and why I said it is too narrowly focused.

ARM cores are tens of times smaller than X86, plus very likely they fab it on a more mature node

No, no way the Neoverse N1 is tens of times smaller than Zen 2, maybe a little bit smaller. And both are on TSMC's latest process.

How long until they shut it down? ARM vendors are infamous for quitting before releasing their products.

The category is here to stay, regardless of which company is the first to make it stick. Probably better to give them the benefit of the doubt.

I'm curious how this will perform vs AMD's Epyc line in terms of performance per Watt on different workloads.

It depends on the workload. We tried the ampere emag, and what killed it for us was that TLS performance was nowhere near modern x86-64 CPUs (Intel or AMD)

Was that heavily cipher dependent? I wouldn't be surprised if Chacha20 performed much better than AES w/o any hardware acceleration (other than SIMD instructions)

Ah, that's interesting. We don't use chacha20. This was AES-GCM

The situation is probably better now that ARMv8 has some crypto-specific instructions, but AES-GCM on older ARMs performed awfully without the instructions specifically for doing AES and Galois field multiplication

As a n00b, is that down to poor or lacking encryption hardware support ala AES-NI? Or something else?

Yes.

You did make sure the AES instructions were used, right? I wouldn't be surprised the AES unit on the eMAG is relatively slow — other units seem to be as well, e.g. in my silly CRC32 benchmark, the Arm Cortex-A72 did 1kb in 79 ns at just 2.0 GHz while the eMAG did it in 103 ns at much faster clocks (3.0 or 3.3 GHz).

I suspect they might have reused these HW blocks from the old Applied Micro X-Gene :D

But now on the new product, it's all Arm Neoverse cores, it's gonna be great.

did you use them on Packet?

It would be neater if it were the Core Ultra 80-amp CPU

What’s the point of these wall of text without some hardware-porn?

;)

Looks like a company by a bunch of ex-Intel people. How are they doing on Spectre/Meltdown and other bugs caused by the culture of cutting corners?

The N1 core was designed by Arm Austin. It includes "The traps for EL1 and EL0 cache controls, PSTATE SSBS (Speculative Store Bypass Safe) bit that supports software mitigation for Spectre Variant 4, and the speculation barriers (CSDB, SSBB, PSSBB) instructions..."

It's run by the same lady that made Intel buy McAffee in 2010 for several billion. Years after it was already a dumpster fire. Yeah, I'm staying away from their products.

Growing sick of the trend of naming companies after famous scientists...

Just as soon as my Kardashian is charged up, I'll swing by your place to drop off the new samples of the 128-core Bieber X.

You know that's a unit of electricity as well, right?

A unit of electricity named after a famous scientist.

And?

and he/she is growing sick of that, apparently

A "he" apparently... https://en.wikipedia.org/wiki/Andr%C3%A9-Marie_Amp%C3%A8re

He would be spinning in his grave. Which would generate an AC current.

He would be well grounded though having no effective voltage. Bad joke, although, it has potential .

Just as good as using famous authors I suppose

http://dresdencodak.com/2010/06/03/dark-science-01/

Why? What should they name it after instead?

innovation, not copying anyone?

There's billions of products in existence. I don't think each one having an "innovative" name provides any value at all. And copying is the highest form of flattery. If I had spent my life researching electricity and found out the most innovative company in the electric vehicle and battery industry was named after me I would feel quite proud

That sounds like a recipe for names like Innotek and Infobang.

I've said this before on HN, but no ARM platform is going to catch on for server use, chicken or egg problem, until people can buy a reasonably priced ATX motherboard and CPU by themselves and build a PC with it. The motherboard needs to have the same complement of I/O and bus ports that you can find on a $90 to $120 category x86-64 motherboard.

There is nothing anywhere near the performance of what I can get right now by buying a $110 motherboard from one of the top six Taiwanese motherboard manufacturers, and a $150 Ryzen 3000 series to socket into it.

Linux and *BSD developers are not going to be shelling out $6000 for a 2U rackmount noisy system that's impossible to operate nicely in their home offices.

ARM servers already happened; they're in production at AWS and probably MS. Most of the software development is already done; since developers wouldn't buy $6000 machines they just got access to them for free.

Is there a consensus pick for the best ARM system around $1,000? I'm not looking for my main workstation, just something usable for building and running ARM software, and maybe acting as a host for ARM containers. I've seen a few options:

Jetson AGX Xavier developer kit - 8 cores, 32 GB, for $700

HoneyComb LX2K mini-ITX motherboard - 16 cores, up to 64 GB, $750

96Boards Developerbox (Socionext) - 24 cores, 32+ GB, $1,200

I'd like a little more than the 4 cores and 4 GB you can get with a Jetson Nano or Raspberry Pi 4.

This was probably the case back when home assembled assembled desktop PCs were a big part of the software developer user base, but nowadays the important dev platforms are laptops and Digitalocean/GCP/EC2.

I remember when Linux on Arm was the new hotness. That was 2005.

Reply on news.ycombinator.com