Hacker News Reader

Comment by slezyr | Hacker News Reader

Have you ever heard about Raspberry Pi?...

Linux has been there entire time

Lots of software works on ARM on Linux... but it doesn’t always work as well as on Intel. I think there’s quite a lot of work to be done to get various parts of a complete distribution working as well as we’d like for server and desktop usage, outside of the more limited embedded role it’s already widely deployed in.

What types of "doesn't work as well" are you thinking about? My understanding of where ARM "doesn't work as well" is something like these areas:

* The underlying code is relying on x86 features or is x86 ASM. In that case ya... this is going to be a bit rough - but is a super minority, especially for use cases where you'd want to use ARM

* The runtime or compiler hasn't been ported to ARM yet. For compilers, I don't think this is a problem - I think both clang and gcc are completely ready to go for armv7 and arm64. Go is good to go too. Runtimes is a bit more dodgy, but all the major (Java, C#, Python, Ruby, Perl, Javascript/Node) languages and runtimes are just fine. Maybe the only one out is rust, which doesn't have ARM as Tier 1 supported (but should just work) yet.

* Hardware support. There may not be good open source drivers for various ARM specific hardware blobs.

What else were you thinking of?

Java compilers with missing intrinsics is what surprises me in my case.

By missing intrinsics do you mean you get an error if you try to use the intrinsic, or do you mean the compiler fails to map the intrinsic to the fastest instruction/instruction sequence?

I mean the compiler calls a runtime routine instead of being able to insert specialised code for it.

There's a long tail of various issues to sort out and "language runtimes that have all the kinks ironed out" is definitely one of them. But I think that's just always going to be the case for any alternative trying to get up to speed with an incumbent player that has a decades-long head start. And most of it works fine today, anyway. Micro optimizations in HotSpot or whatever isn't what's holding people back from desktop ARM machines. (If any language could make a difference here, I'd actually argue it's JavaScript being optimized because it's vital to web browsing, but luckily that got sorted out years ago thanks to mobile handsets.)

Plenty of things work very well and I'd think most people would rate those working as far more important than small compiler tweaks. NVMe, GPU support etc is vastly more important to me than compiler micro-optimizations, for instance, because those actually make day to day developer usage viable. No amount of compiler optimizations will make SD cards fast. And today, you can boot generic Linux images for whatever distro, using UEFI, on high-speed ARM systems, with fully working desktops -- including working FOSS GPU drivers, full web browsers (with working javascript JITs), and high speed storage. So I think it's shaping up pretty nicely.

x86 has much stronger guarantees about memory ordering compared to ARM [1]. Maybe this comes under x86 features, but multithreaded software will not work if assumptions of memory ordering guarantees are made.

[1] https://en.wikipedia.org/wiki/Memory_ordering

It's selling the Raspberry Pi short to describe it as a "limited embed". You can run a full desktop OS on it (I do) and everything works great.

For example ARM compilers with fewer optimisations compared to Intel is something I’ve seen in practice.

well, Intel employs people to implement those optimisations in GCC, Clang, etc...

My naive understanding is ARM devices traditionally use a static, unchanging "device tree" specification to bring up hardware on boot. There's a project for implementing UEFI firmware for the Raspberry Pi - as one ARM device - so that you can take any unmodified (ARM-built) Linux that would boot off of EFI and it will Just Work (tm).

I've been using it:

https://github.com/pftf/RPi4 https://rpi4-uefi.dev/

Actually what I've been doing is using my wireless router (openwrt) to serve pxe images. So the rpi sits without an SD card. It's powered via Power over Ethernet (PoE), is advertised a pxe server, gets the initial uefi & ipxe binaries, then I can boot from an image off Github or one served locally. ipxe just adds another layer of indirection for expanded fun.

Reply on news.ycombinator.com