Arm fills in some gaps and details in server chip roadmaps | Hacker News Reader

Arm fills in some gaps and details in server chip roadmaps

nextplatform.com

70 pointsrbanffy24 comments

I cannot wait until I can buy a good simple ARM server for my home. Something like an RPi 4 but with more disk I/O and RAM. Or a slightly more baked version of a ROCKPro64 in a nice case.

I would love to see something akin to an M-based Mac as a dev board of sorts, but I’m fairly sure it would never happen. My home server has transitioned over time from various 4u rack mount options, to a 2u and an M1 Mac Mini, to a Mac Studio with a disk enclosure.

I even tried using a Snapdragon phone dev board for awhile for something more than an RPi

It's a bit annoying that (with the exception of Apple) ARM only exists in the low end and in the high-end cloud server space. There is no ARM equivalent to the Core i5 generally available.

My (non-professional) opinion is that Intel has invested a lot of money into making really good memory and I/O controllers. We need someone to do that in the ARM space as well, which is a really hard-sell. There are no manufacturers out there that want to pay the ARM licensing fee, period. Apple can eat the costs because they sell direct-to-consumer and like to control as much of their stack as possible. Other companies are probably groaning at the thought of fixing all of ARM's problems just so they can be treated as a second-class platform relative to Apple Silicon. Besides Nvidia or Qualcomm, I don't really think there are many companies poised to deliver this, much less an incentive to provide anything.

RISC-V on the other hand, seems like it could be ripe for rapid iteration. We're obviously still in the super-early days of the ISA, but the lack of oppressive licensing has already been a boon for the dozens of hobbyist boards we've seen released in the past few years. As long as Apple doesn't try to EEE the ISA like they're trying to do with ARM, I think the future is pretty bright for open architectures.

I'd say that there's one: Snapdragon 8cx Gen 3.

(See the ThinkPad X13s)

The 8cx Gen 3 is better than Qualcomm's other stuff but it's still generations behind a current Core i5. They're about 20% slower than a last-gen Core i5.

Can one install other OS on that Thinkpad or is it doomed to run Windows forever?

Linux support for the X13s is a work in progress. Booting and Wi-Fi connectivity work since a few months now for example.

This is great news. It's a good EUR 500 cheaper than a similarly outfitted M1 Macbook (although the performance is closer to Celeron than to M1)

>Something like an RPi 4 but with more disk I/O and RAM.

Have you seen the RISC-V based VisionFive2?

Uses 4x SiFive U74 cores, so it is actually between rpi3b and 4 in CPU performance, but using way less power (especially idle).

The SoC has an industrial operating range: It can go up to 125C, it doesn't use or need a heatsink; at full load in human room temperatures it won't even reach 70C.

GPU performance is supposedly 4x that of RPi4. As for I/O, it has 2x GbE and a M.2 slot, besides USB3 and a RPi-like GPIO header.

4GB and 8GB versions are available, but 8GB won't ship until February. Both versions are <$100.

Sounds like the Honeycomb.

Agreed!

We needed a Linux ARM server recently and bought an M1 mini and ran Asahi then ran the Linux we needed in a docker container.

This is a good solution, IMO, until better hardware comes along.

What about a Mac Mini? It is now available quite cheap in the basic configuration.

The V2 decision to go with 4 128 bit vector pipes instead of 2 236 bit ones is a bit odd, maybe due to sharing some of the design with the N2? Or maybe they want to keep things compatible so code can be migrated from a V2 to a smaller core.

It also means that code using smaller vectors from an older version just gets faster, as long as the new core can schedule/retire instructions fast enough to keep up. If it can't then going for 256 bit is the best choice although it seems like newer chips are going for wider execution (and that each 128 bit unit is in fact individually accessible).

It crossed my mind is that this only is valid as long as you can reasonable expect most of the uses themselves to have enough ILP, not just the hardware scheduler.

I'm thinking back to some linear algebra code I wrote which was bounded by min(loads-per-cycle, FMA per cycle). Adding more fma units there wouldn't help if you didn't increase load units equivalently, so for this sort of software wider vector units are better.

Can modern chips hold instructions from different processes in the reorder buffer tagging them by their context/PID? If so, up to four processes could be running 128-bit SIMD ops concurrently.

That's SMT but Neoverse cores don't use it.

SMT would be from “virtual” cores. Does the reorder buffer get emptied when a processor switches context or do the in-flight instructions continue there and instructions from a different process start coming in?

I assume the kernel code to perform the context switch is big enough to fill the ROB.

Good point, still, context switch code can enter the ROP before the previous instruction flow is retired. Is the ROB explicitly flushed or can instructions from different processes (or a user process and the kernel) coexist in the ROB?

Now that’s a relevant username ;)

V1 already had 4 128bit pipes, SVE just used two simultaneously. The only real gain in benchmarks on V1 with 256bit SVE over 128bit NEON was in load-heavy kernels that were bottlenecked by the 5-wide decode, and weren't saved by the MOP cache. Improving decode width is easier now that 32-bit is dead (or maybe V2's MOP cache was improved enough...), so 256bit wide isn't terribly useful unless they commit the transistors and power budget for an even wider backend than 512bit/cycle.

This is slightly disappointing as I was expecting N3 sooner. The roadmap from AMD starting with Zen4c is surprisingly competitive on the Server Market.

Reply on news.ycombinator.com