6 ms·
If laptops are following phones and tablets into ARM it means x64 is most likely to survive on large workstations, servers, HPC, and in data centers. It makes a
by api 6y ago
If laptops are following phones and tablets into ARM it means x64 is most likely to survive on large workstations, servers, HPC, and in data centers. It makes a ton of sense for AMD and Intel to prioritize Linux and make sure their support is first class.
- bee_rider 6y agoIn HPC the situation seems a little weird. Fundamentally, lots of HPC workloads should scale pretty well to lots of little ARM cores. If anything the x86 advantage is more that it is just a conservative field full of scientists and engineers, who are happy with their old math libraries, which grew up on x86 and are heavily tuned for the environment. If I were AMD or Intel, I'd keep investing in HPC, but be terrified that my lead there was just one good ARM BLAS library away from evaporating.
- my123 6y agoFujitsu A64fx already exists, the threat is quite near. Arm on the server market is quite interesting too (Graviton2 and Ampere Altra today). And those are big cores. For a ton of little cores, looks less clear-cut for me because of the communication overhead. (could work out though, but won't be exactly easy).
- pimeys 6y agoDoes any of these ARM systems work with a mainline kernel, or do they need some old custom kernel with binary blobs?
- my123 6y agoAll server-class Arm hardware works with UEFI + ACPI, as such using regular OS images. (mandated by Arm ServerReady SR/SBSA, you are not allowed to ship Device Tree there)
- pimeys 6y agoCould it be possible we get this too in the workstation and laptop ecosystems?
- my123 6y agoWindows on Arm64 machines are all UEFI + ACPI too. :-) (even for 32-bit Windows on Arm, back in the Windows RT times, this was the case. It's a shame that Microsoft decided to lock those down back then) On more affordable Arm machines, Honeycomb LX2K has an official UEFI firmware (with ACPI) and NVIDIA's Jetson AGX Xavier has an official (but experimental) UEFI+ACPI option. Those aren't complete yet in mainline when using ACPI. For the LX2K, onboard networking currently doesn't work when using mainline kernels. And for the AGX Xavier, you lose PCIe (until the quirk to support it there is merged, or the ECAM through PSCI patchset) and integrated GPU support. When using a Windows on Arm laptop, most Qualcomm drivers only have device tree bindings, not ACPI at least at this point. As such, you might need to load a device tree at boot for a more complete experience. (you can look at repos on https://github.com/aarch64-laptops https://github.com/aarch64-laptops if you have one) For SBCs, forget about almost anything not named "Raspberry Pi", for which... a third-party UEFI + ACPI firmware is available at https://rpi4-uefi.dev https://rpi4-uefi.dev, which allowed the original RPi4 to be certified as SystemReady ES. A lot of the things that actually drive making people implement UEFI + ACPI is that Windows, RHEL and VMWare ESXi require UEFI + ACPI to boot on 64-bit Arm.
- linux4kix 6y agoDon't forget about our Marvell series of boards :) While HoneyComb is our flagship for SystemsReady ES certification, We will also have our Armada 8040 and CN913x based products that will also be fully supported UEFI + ACPI systems.
- fh973 6y agoWhich distro would you recommend for ARM servers?
- 6y ago
- qbasic_forever 6y agoYes, the kernel has great support for ARM. Distros that need to package up the kernel, tweak the bootloader, deal with peripherals, etc.... less so on great support. ARM is a bit of the wild west with SoCs defining all kinds of esoteric and exotic hardware configs managed by the kernel's device tree infrastructure instead of a typical BIOS. If you're dealing with server workloads it matters much less (and they probably support UEFI) so stick with a distro that has good support (Ubuntu, Fedora, etc.). If you're dealing with ARM hardware directly like little SBC boards, start getting comfortable rolling your own device tree, bootloader config, etc. as you're probably going to need it. In all cases though the stock mainline kernel is fine to use.
- bee_rider 6y agoI constantly forget how good Graviton2 is. E: A64FX seems like a really cool chip, but it sure is much easier to get time on AWS than Fugaku. :)
- jabl 6y agoIf anything, I would argue HPC is one of the more flexible markets. A lot of HPC software is distributed in source form, so recompiling for a different architecture is seldom a big deal. As long as the system provides BLAS and MPI libraries, and good bang/buck, you're good.
- alberth 6y agoJust like how x86 disrupted the mainframe market decades ago and ushered in: client/server, desktops, laptops ... I feel ARM is doing the same to x86. It can see a future where x86 is the modern equivalent of a “mainframe”
- pimeys 6y agoIt's kind of weird, but I don't really see so much gain from getting an ARM compared to x86. All I see is closed hardware, locked bootloaders and non-free operating systems in the future. I want to be wrong though...
- api 6y agoThere's nothing that requires closed boot loaders and locked OSes on ARM, nor is there anything preventing the same on X64. Most X64 chips have embedded security processors that can and sometimes are used to do just that, while the Raspberry Pi and countless other ARM boards are fairly open. The new M1 Mac is fairly open too in that you can boot non-MacOS OSes on it. It differs from the iPhone and iPad in this way as the Mac is made for a different market niche. The best way to fight closed devices is to not buy them regardless of their CPU ISA. ARM is just a different ISA with somewhat superior efficiency characteristics due to fixed length easier to decode instruction encoding. That's about it.
- marcodiego 6y agoRaspberry pi needs proprietary blob to boot. It is not "fairly open".
- api 6y agoARM will definitely need a BIOS interface standard before it sees big traction in servers, desktops, and cloud. There's apparently some work going on here. As it stands there just hasn't been a big motive to create such a standard because ARM has mostly been used on embedded and mobile devices that ship with canned images anyway.
- marcodiego 6y agoArent graviton and ampere promises that ARM can compete with x86 on servers too?
- qbasic_forever 6y agoYep, it's flying under everyone's radar right now too. In my experience Graviton 2 instances are ~20% faster and 30% _cheaper_ than the best x86 instances for typical web workloads (transform some templates, talk to a DB, do IO bound network work, etc.). It's an amazing way for nimble little SaaS startups to pluck away customers from giants by offering much cheaper prices. The little guys that build up ARM expertise are going to be great exits and pickups for the larger fish in the ecosystem too (because if your platform is an old thing with a lot of technical debt, moving it to ARM is not trivial and the expertise to do it is in wild demand). If you're working on online services and NOT looking at or using ARM servers right now--you are in big trouble and already too late to the game.
- CodesInChaos 6y agoWhat are the challenges with porting to ARM, besides third party code which doesn't support it? I only know about unaligned reads and the weaker memory model, but both of them are already undefined behaviour in C/C++/Rust.