Avantek's Arm Workstation: Ampere eMAG 8180 32-core Arm64 Review
by Andrei Frumusanu on May 22, 2020 8:00 AM EST
Arm desktop systems are quite a rarity. In fact, it’s quite an issue for the general Arm software ecosystem in terms of having appropriate hardware for developers to actually start working in earnest on more optimised Arm software.
To date, the solution to this has mostly been using cloud instances of various Arm server hardware – it can be a legitimate option and new powerful cloud instances such as Amazon’s Graviton2 certainly offer the flexibility and performance you’d need to get things rolling.
However, if you actually wanted a private local and physical system, you’d mostly be relegated to small low-performing single-board computers which most of the time had patchy software support. It’s only been in the last year or two where Arm-based laptops with Qualcomm Snapdragon chips have suddenly become a viable developer platform thanks to WSL on Windows.
For somebody who wants a bit more power and in particular is looking to make use of peripherals – actively using large amounts of storage or PCIe connectivity, then there’s options such as Avantek’s eMag Workstation system.
The system is an interesting mish-mash of desktop and server hardware, and at the centre of it all enabling is Ampere’s “Raptor” motherboard containing the eMAG 8180 32-core chip. This is a server development board that doesn’t really adhere to any standard form-factor standard, but Avantek was able to make it fit into BeQuiet tower chassis with some modifications.
Ian had published a more in-depth visual inspection of the machine a few weeks ago, so I recommend reading that in terms of the analysis of what’s physically present in the machine and its quirks.
Read: Arm Development For The Office: Unboxing an Ampere eMag Workstation
The notable characteristics of the system is that in fact it’s a setup that was designed by a vendor that’s usually server oriented – this is Avantek’s first foray into a desktop system.
As noted, because the motherboard isn’t adhering to an ATX standard, the biggest incompatibility lies on the part of the PCIe slots which don’t match up with the slots of the chassis. Avantek here had to resort to using a riser card and a custom backplate in order to fit the graphics card.
The graphics card provided in our sample was a Radeon Pro WX5100 – a lower-end unit meant for workstations.
The biggest advantage of the system which we’ll address in more detail in a bit, is the fact that this is an SBSA (Server Base System Architecture) compliant system, which means it’ll be compatible with “most” PCIe hardware out there. For example, I had no issues replacing the graphics card with an older Radeon HD 7950 I had lying around and the system booted with display output without any issues. This might sound extremely boring, and it is – but for the Arm ecosystem it’s been a decade long journey to reach this point.
In terms of general form-factor, Avantek’s choice here to go with a desktop chassis works well. It’s a big motherboard so it does require a bigger case, allowing it for plenty of additional hardware inside.
I think one negative on the system from a practical hardware perspective is Avantek’s server pedigree. The CPU cooler in particular is the type you’d find in a server system, and the fan choice isn’t something you’d see in any traditional desktop system as it's a more robust 90mm fan. Although the company has said that it tried to minimise the noise of the system by adjusting the fan curves as well as opting for a low acoustics chassis – it’s still subjectively loud for a desktop system. I measured around 42dBA at idle which is still a bit much - but that also depends on your typical expectations of a silent system. I hope Avantek would change in the future is employ a more consumer grade CPU cooler system and reduce the acoustics of the machine.
Facebook
Twitter
RSS
35 Comments
View All Comments
lmcd - Friday, May 22, 2020 - link
You can't just reference the RPi 3 and 4 interchangeably. RPi 4 ranges from 2x to 10x faster than the RPi 3 depending on workload. Most SBCs surpassed the RPi 3 merely by choosing an SoC without its terrible I/O constraints. A few have 2xA72. The RPi 4 has 4xA72 at a better process node -> better clockspeed for the same thermal constraints, and no FSB limitations. Its CPU performance is ahead of all but the top-end hardware development kit boards.lmcd - Friday, May 22, 2020 - link
Apparently I'm a moron that didn't see the ODROID-N2 release. That CPU is noticeably better.SarahKerrigan - Friday, May 22, 2020 - link
It would likely win by a small to moderate amount against the Pi4 on ST, and obviously by a factor of several times on MT.Altra will increase those numbers considerably, since it should be doing 2-3x the ST eMag and a much larger factor for MT due to the core count increase.
Dodozoid - Saturday, May 23, 2020 - link
Would have been interesting if AMDs planned K12 worked out. Any idea if any part of that architecture is still alive?AnarchoPrimitiv - Sunday, May 24, 2020 - link
There's a decent amount of spelling errors and wrong word errors in this article, for example:"... having an Arm system like this is the fact that it enables YOUR (I think you mean "you") native software development, without having to worry about cross-compiling code and all of the kerfuffle that that ENTRAILS (I think you mean "entails")"
There's a few of those on every page, did anyone even proof read this once before publishing?
LordConrad - Sunday, May 24, 2020 - link
"...without having to worry about cross-compiling code and all of the kerfuffle that that entrails."Wow, who did you have to disembowel to get the cross-compiling done?
abufrejoval - Sunday, May 24, 2020 - link
He quite exaggerated the effort, because it makes little difference if you compile GCC for the host architecture or a different one: Just a matter of configuration and that's it.You have to understand that pretty much every compiler has to compile itsself, because nobody wants to code it in machine binary or assembly. The code for all supported target architectures comes with the compiler source tree and you just need to pick the proper parts to use.
It's just a tad more involved than simply running cc off the shelf.
Fataliity - Sunday, May 24, 2020 - link
"You must first compile the compiler, to then compile your code"
Sounds pretty crazy. Isn't the compilers also written in c++, which are compiling c++?
My brain hurts.
GreenReaper - Sunday, May 24, 2020 - link
It involves a frequently non-trivial, multi-step process called bootstrapping:https://en.wikipedia.org/wiki/Bootstrapping_(compi...
abufrejoval - Sunday, May 24, 2020 - link
Well, recursion really grows on you after a bit of use :-)While I am pretty sure gcc is written in C++ these days, obviously the first C++ compiler still had to be written in C, because otherwise there was nothing to compile it with. Only after the C++ compiler had been compiled and was ready to run, the compiler could be refactored in C++, which I am pretty sure was done rather gradually, perhaps never fully.
These days I doubt that the GNU Fortran, Objective-C, Go or plain old C-compiler are written in anything but C++, because there would be no benefit in doing so. But of course, it could be done (I wouldn't want to write a compiler in Fortran, but I guess some of the early ones were, perhaps with lots of assembly sprinkled in).
The GNU bootstrapping was done a long time ago, perhaps with a K&R compiler and you don't typically have to go through the full process described in the article GreenReaper linked to. Pretty sure LLVM was bootstrapped in GCC and now you could do the same the other way around, if you didn't know what else to do with your day.
I hear the Rust guys want to do a full bootstrap now, but so far their compiler was probably just done in C++. Not that they really have to, probably just because "eat your own dogfood" gets on their nerves.
The process Andrei had to use is pretty much whatever the guy who put 'cc/c++' on the shelf of your Unix/Linux had to do, except that Andrei had to explicitly configure an ARM64 v8 target during the compile, while by default the Makefile or script will pick the host architecture.
Really a pretty minor effort, trivial if you are used to build Unix/Linux applications or even a kernel or distribution from source.
And if you are developing for Android, that's what's happening all the time under the hood, there: So far nobody will want to build Android on an Android device, because it's rather slow already, even on a big server with dozens of cores.