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.
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
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.
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.
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)
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.
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)
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
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.
>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
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]
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.
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.
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.
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..."
"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?
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.
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.
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.
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.
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.
"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.
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:
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.
70 comments
[ 2.9 ms ] story [ 139 ms ] threadHe would be spinning in his grave. Which would generate an AC current.
http://dresdencodak.com/2010/06/03/dark-science-01/
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.
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.
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...
I sort of record Applied Micro were doing POWER as well, is that still the case with Ampere?
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.
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 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.
;)
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.
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.
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
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-...
>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.
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.
https://www.anandtech.com/show/15575/amperes-altra-80-core-n...
If I read this right, they reduce their competitors' benchmarks because they have better compilers? Can anyone justify this?
Oh, and don't miss the 3.0 vs. 3.3 GHz.
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.
When could we expect a review on Altra?
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.
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.
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.
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.
Using Intel's compiler or AOCC to compile binaries for normal server use is pretty rare.
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.
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.