Hacker News Reader

Comment by nicoburns | Hacker News Reader

> I am quite impressed with it so far. Installation was a breeze, it compiles the kernel on 32 cores from spinning rust in 4m15s

Does anyone know how this compares to a recent x86 machine? This seems quite fast for the entire kernel, but I have no idea what typical build times are like.

View on HN

Incidentally, I'm pretty sure that Sir_Cmpwn meant 32 threads, not 32 cores. Raptor sells an 8-core CPU bundle, and those cores are SMT4 capable, meaning 4 threads per core. So it will appear as 32 CPUs if you run `htop` or `cat /proc/cpuinfo` in Linux.

Raptor does sell a 22-core SMT4 capable CPU, which, Yikes! that's a lot of computing power.

That Blackbird bundle seems like a beast. The Phoronix benchmarks show it outperformed by high end x86 chips though. I wonder if some of that comes down to gcc optimizations because x86 has been around longer.

It's competitive with x86_64. Here are some more comprehensive benchmarks:

https://www.phoronix.com/scan.php?page=article&item=blackbir...

This one is a little more relevant for a server: https://www.phoronix.com/scan.php?page=article&item=rome-pow...

The trick is far fewer modules and compile time options.

A fun benchmark would be a Power9 Vs a X86_64 cross compiling the same ARM64 kernel. I wouldn't bet heavily on the Power9...

I agree, but I’m really curious if this is just because the commonly used compilers & libraries aren’t particularly optimised for ppc64le (which is a guess) or whether the hardware itself cannot match the equivalent Xeon and Ryzen offerings

Not that this matters to the end user, but it is still interesting IMO

I might take that bet core for core, matched node size (i.e. 14nm), run out of tmpfs or NVMe storage, and with both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications)...

Slightly OT, but if you limit the playing field to open ISA / fully owner controlled systems, POWER9 is so far out front in terms of performance that it looks like an outlier. ;)

A race of one is easily won :)

Well, to be fair I was thinking of the SiFive RISC-V board as one of the competitors, since my understanding was they did finally open the rest of their firmware a while back.

However, yes, by far most of the remaining owner controlled systems are even smaller -- some of the smaller (older) ARM Chromebooks (sans GPU, of course), the BeagleBone black, those kinds of systems.

Yeah, I also have a HiFive Unleashed which is totally open, but it doesn't really aim to compete with Raptor iiuc. Until recently it also won out on open ISA, too, and the Blackbird has to be bootstrapped by the ARM BMC - which is a nonfree ISA. Power consumption is another story as well. Raptor systems is definitely the only realistic competitor to x86_64, though, for desktop and server use-cases.

Yep, definitely agreed. FWIW we're not happy with the ARM baseboard controller either and are making progress toward fixing that particular concern. All I'll say on that is that the POWER ISA opening had to happen before we could start work in earnest on getting rid of the ASpeed... ;)

> both systems protected against Spectre, Meltdown etc. (i.e. no cheating by ignoring the ISA specifications)

Does the x86 specification say "speculation will have no observable side effects on the memory subsytem"? I wasn't aware of that. In other words, Spectre/Meltdown are bad security flaws, but I don't think they're the result of cheating.

Meltdown is absolutely cheating as it speculates through permission boundaries. I don't see how anyone could argue otherwise in good faith, especially considering that it was only Intel and IBM effected. AMD and SPARC were immune, and the extent of ARM's vulnerability was a single register, which seems like a bug, not reflective of an architectural design decision.

You can't design your software to protect against Meltdown, which makes the ISA guarantees useless. Whereas Spectre-type side channels can be mitigated through software, which is what cryptographic algorithm implementations have been doing for years.

There's far more room for debate regarding culpability for Spectre class attacks, though it's pretty clear that Intel deliberately pushed the envelope in ways that AMD and ARM weren't prepared to do.

Again, I don't see that as cheating or violating a spec (or at least any guarantee made by Intel about x86(-64) behavior that I know of). I would assume that speculation can do just about anything (access protected memory, run illegal/protected instructions, etc), as long as any effects aren't committed to architectural state until the speculated path retires. The existence of side channels (timing information of subsequent memory accesses) for retrieving information from speculative execution paths is a different issue. Perhaps it was naive of the architects to assume this wouldn't have any consequences beyond improving performance, but I don't know what spec it is supposed to violate.

What's the point of protected memory, especially when using VM extensions, and particularly with regards to SGX, if the architecture is implemented in such a way that unprivileged software can read the entire contents of memory and there's no way for software, either the kernel or the processing software, to prevent it? You can make a tortured, pedantic argument defending Intel if we disregard VM-x and SGX, that memory protection was originally intended only to prevent data corruption, not confidentiality, but at the end of the day all such an argument does is emphasize the deliberate choices Intel made to sacrifice confidentiality for performance. And those choices are all the more unforgivable considering Intel's primary motivation for taking these performance short cuts were to expand into and secure their dominance of the VM and cloud hosting market; a market predicated on the ability of their architecture having the nominal capability to ensure data confidentiality.

It'll depend on the kernel configuration. I don't know about the Raptor, however I have some experience with IBM's POWER9 servers and they do have tremendous single thread performance and many cores, and are quite a bit faster than Intel Xeons (although at a considerably higher price, but the customers usually need the performance and aren't too sensitive about price).

2m3.673s; default config with loadable modules disabled; make -m 32. This is on a second-last generation 24C/48T Xeon (albeit a slower one) with all of the known speculative execution vulnerabilities mitigated except spec_store_bypass, and SMT still enabled (because htop is prettier with more pretend CPUs).

What's the I/O situation? I did my build from an HDD, WD Blue. Also, kernel config matters a lot - I used yesterday's master branch from Linus, with Alpine Linux 3.10's ppc64le config, plus olddefconfig to catch it up.

24 core ppc64le system, 5.4-rc2, defconfig, loadable modules on and built:

real 1m55.267s

Run from tmpfs, all protections from Spectre etc. on. Not too bad, really!

Spinning rust may well be the bottleneck here.

Reply on news.ycombinator.com