Live data from Hacker News

Cavium Is an Arm Server Contender

nextplatform.com

41–50 of 67 posts

Re: Cavium Is an Arm Server Contender

#41
post #3

Yesterday: ARM in your phones Today: ARM in your toys (RasPI, Nintendo Switch) Tomorrow: ARM in your servers Next week: ARM in your desktop/laptop? The iMac Pro will have an ARM co-processor: https://www.macrumors.com/2017/11/19/imac-pro-a10-chip-hey-s... - Arguably for "Hey Siri" and other mobile-inspired functionality, but wouldn't it be interesting if it were also an ARM-on-the-desktop beachhead? I, for one, welco…

Not just for Macs, but for full Windows 10 laptops, too (soon):

https://www.theverge.com/2017/10/18/16495010/microsoft-windo...

Re: Cavium Is an Arm Server Contender

#42
post #3

Yesterday: ARM in your phones Today: ARM in your toys (RasPI, Nintendo Switch) Tomorrow: ARM in your servers Next week: ARM in your desktop/laptop? The iMac Pro will have an ARM co-processor: https://www.macrumors.com/2017/11/19/imac-pro-a10-chip-hey-s... - Arguably for "Hey Siri" and other mobile-inspired functionality, but wouldn't it be interesting if it were also an ARM-on-the-desktop beachhead? I, for one, welco…

Unless the iMac Pro (unlike the current MacBookPro) has a generally addressable ARM core, it's not news that they're using ARM for the purpose of overall ARM dominance.

It's like when people were all excited they were testing LiquidMetal in their SIM ejection tool (not sure if that was apocryphal).

Re: Cavium Is an Arm Server Contender

#43

ARM on desktop or server will be tightly controlled closed SOCs with zero driver support. These will be nothing like the relatively open systems in the PC world, so there is nothing to look forward to. This is ARM's model and they have shown no interest in improving things beyond kicking open source developers between the ARM and SOC vendors each blaming the other for years on end. Intel, even with something as nasty…

That’s not true at all.

That has been true only for the embedded and mobile space.

The server space is exactly being made open and compatible between SoCs (in the same way AMD and Intel machines are). Platform crud (i2c, gpio, i2c, clock trees and pinnmuxes) is hidden in firmware behind ACPI, PSCI and UEFI just like on x86. SBSA and SBBR specs mandate stringent compatibility requirements. Machine error handling is firmware-first. IO is basically PCIe now.

For an OS vendor or an IT guy these machines look almost exactly like an x86 box. And then they look the same between the Arm vendors too.

Re: Cavium Is an Arm Server Contender

#44
post #27
post #3

Yesterday: ARM in your phones Today: ARM in your toys (RasPI, Nintendo Switch) Tomorrow: ARM in your servers Next week: ARM in your desktop/laptop? The iMac Pro will have an ARM co-processor: https://www.macrumors.com/2017/11/19/imac-pro-a10-chip-hey-s... - Arguably for "Hey Siri" and other mobile-inspired functionality, but wouldn't it be interesting if it were also an ARM-on-the-desktop beachhead? I, for one, welco…

Next week + 1 day: your laptop is no longer supported Which ARM SoC has mainlined drivers in Linux kernel? I fear that the ARM trend will only help to make the the e-waste mountain higher.

That’s exactly why the Arm servers adopt the same specs or functional equivs to x86. A single binary distribution of an OS will boot on any SBSA compatible machine - because all the weird bits are hidden through ACPI, UEFI and PSCI. No BSPs.

I’d go as far as saying Arm servers are compatible to x86 designs at a platform level (eg. how PCIe and config space are wired up, how caches and DMA work, NUMA, SMP, MSI(X), and so on....

Re: Cavium Is an Arm Server Contender

#45
post #6

Earlier quoted context omitted.

To be fair, ARM has been in Mobile Nintendos since 2001. And laptops have had ARM coprocessors for quite a while. Power management controllers, disk controllers, NICs, etc.

Hey yeah, I remember my first ARM programming was on the NDS' two 66/33MHz processors. I think it basically dedicated one to each screen, fun stuff. Are the laptop co-processors you're talking about the 'R' lines? I know 'M' is for low-power mobile stuff and 'A' is for "Real Computer" stuff, but I was never too clear on the 'Realtime' lines.

I've seen all three in that use case (and ARM11 cores and earlier where they didn't really make the distinction as overtly). Mainly R and M though.

But the distinction is something like:

M - Thumb2 only, simple two or three stage pipelines typically. Optional everything like selectable (at chip design time) multiply unit that's either 1 or 32 cycles of latency. MPU (if present) only adds protection information, but doesn't remap memory like a full MMU. An ascetic M has something like 12k gates which is insanely low for a 32 bit processor. It mainly competes with AVRs, 8051s, and maybe really low end MIPS if anyone is still using R3000s. In a laptop, I've seen them in power management controllers, bluetooth, and sometimes in WiFi.

R - More powerful than M. Runs Thumb and A32. Clear, deterministic. In order pipeline, tightly coupled memory, and an MPU so that you can still run hard real time cycle counting kind of code twiddling GPIOs carefully, but then also running DSP on the results afterward. I've seen a lot of these in hard disk controllers. They're sort of spiritual successors to the ARM9/7 you know from the DS. Competes with most MIPS.

A - Sort of all over the place. Some are 32bit, some are both 32 and 64. Has a real, page table MMU. Typically run real, big boy kernels like Linux. Competes with Atoms, higher end MIPS (see a trend?) and POWER at the very high end if you squint enough. Typically they're complex enough that you can't cycle count and get deterministic results (longer pipelines, TLB that'll refill 'randomly', cache refills, more complex branch predictor), but give higher overall performance. I think I've seen an A8 as a sound processor? Typically though they're not really a coprocessor, the gate count is too high to make sense.

Re: Cavium Is an Arm Server Contender

#46
post #21

I've run experiments/developed on both Applied Micro's X-Gene 1 and Cavium's ThunderX (the original). Both of these have been touted as "ARM servers". The X-Gene was complete crap in terms of both performance and power consumption. The ThunderX was only really useful for highly-parallel applications that don't require a lot of horsepower, and even then it's a power hog. I'm cautiously optimistic with Qualcomm's Centr…

Not to mention the amount of hardware standardization that still needs to happen. Having a different image for each manufacturer's hardware is going to get real old, real fast.

5+ years on, ARM on anywhere but mobile seems like a dud.

Re: Cavium Is an Arm Server Contender

#47

Earlier quoted context omitted.

Hey yeah, I remember my first ARM programming was on the NDS' two 66/33MHz processors. I think it basically dedicated one to each screen, fun stuff. Are the laptop co-processors you're talking about the 'R' lines? I know 'M' is for low-power mobile stuff and 'A' is for "Real Computer" stuff, but I was never too clear on the 'Realtime' lines.

I've seen all three in that use case (and ARM11 cores and earlier where they didn't really make the distinction as overtly). Mainly R and M though. But the distinction is something like: M - Thumb2 only, simple two or three stage pipelines typically. Optional everything like selectable (at chip design time) multiply unit that's either 1 or 32 cycles of latency. MPU (if present) only adds protection information, but d…

Huh, cool. I've actually been playing with the STM32 Cortex-M processors, and I gotta say - some of those high-end M7 chips could easily run a game system and are way out of the range of 8-bit Arduino-y chips. 400MHz with a 24-bit parallel LCD peripheral? That could probably give the PSP a run for its money.

And they're moving to a ~40nm process on those performance lines soon.

Re: Cavium Is an Arm Server Contender

#48

I'd sort of been expecting that ARM would begin making HPC inroads when SVE[1] was ready to go. But I guess those two Neon units provide enough horsepower? [1] https://community.arm.com/processors/b/blog/posts/technology...

They don't for fp32 or int8 workloads until SVE IMO. High end Skylake as an example has 2 AVX-512-F ports (and not considering AVX-512-4FMAPS), which give you do 64 FLOP/cycle (512 / 32 * 2 * 2). Even 2 NEON units, assuming FMA's execute in 1 cycle/unit, gives only 16 FLOP/cycle. For ML inference workloads you can even get away with lower precision and even do away with floating point (which helps motivate AVX-512-4VNNIW).

Re: Cavium Is an Arm Server Contender

#49

Earlier quoted context omitted.

I've seen all three in that use case (and ARM11 cores and earlier where they didn't really make the distinction as overtly). Mainly R and M though. But the distinction is something like: M - Thumb2 only, simple two or three stage pipelines typically. Optional everything like selectable (at chip design time) multiply unit that's either 1 or 32 cycles of latency. MPU (if present) only adds protection information, but d…

Huh, cool. I've actually been playing with the STM32 Cortex-M processors, and I gotta say - some of those high-end M7 chips could easily run a game system and are way out of the range of 8-bit Arduino-y chips. 400MHz with a 24-bit parallel LCD peripheral? That could probably give the PSP a run for its money. And they're moving to a ~40nm process on those performance lines soon.

They're a lot more powerful once you start utilizing their hardware peripherals like DMA. With a STM32F4 it's possible to saturate a 100mbit PHY that pushes out that data to 100+ GPIOs while using all of the CPU just for bit interleaving and control signals. If your use case allows it, these microcontrollers can punch far above their weight with dedicated hardware when compared to general purpose CPUs

Re: Cavium Is an Arm Server Contender

#50
I would enjoy seeing a Cavium based system that I was allowed to actually run my own code on to see what was what. Over the years, in various roles, I've listened to them trying to sell me servers but they have never actually had hardware that they could just let me run code on.
Post reply on HN