3 ms·

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 underlyi

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?

chrisseaton 6y ago
Java compilers with missing intrinsics is what surprises me in my case.
- MaxBarraclough 6y ago
  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?
  - chrisseaton 6y ago
    I mean the compiler calls a runtime routine instead of being able to insert specialised code for it.
- aseipp 6y ago
  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.
xioxox 6y ago
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 https://en.wikipedia.org/wiki/Memory_ordering

chrisseaton 6y ago

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

MaxBarraclough 6y ago
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?
- chrisseaton 6y ago
  I mean the compiler calls a runtime routine instead of being able to insert specialised code for it.
aseipp 6y ago
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.

xioxox 6y ago

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 https://en.wikipedia.org/wiki/Memory_ordering