There are a bunch of things which can differ between architectures which can't be reliably abstracted away by the standard library. Memory coherency is one. Ch

There are a bunch of things which can differ between architectures which can't be reliably abstracted away by the standard library. Memory coherency is one. Check out the table of what reorderings processors are allowed to do: https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_multiprocessing_(SMP)_microprocessor_systems https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_m... x86(-64) is very conservative, doing very little reordering. ARM is much more liberal, doing lots of reordering. The standard library may give you tools to write code which is correct across all architectures, by defining some portable memory model and then implementing that model on each architecture (in C++, std::atomic does that). But it's easy not to use those tools properly: you can write code which is incorrect according to the standard library, which works on x86 because it is conservative, but which fails on ARM because it is liberal. Detecting bugs like that statically is an open research problem, and cross-platform concurrency bugs are among the hardest there are to debug. There's more than just reorderings, too. A local wizard tells me "On ARM, you can have cores where there is no implicit "propagation"... i.e. if you write to some memory location from core "A", core "B" may never see those changes. You have to use synchronization primitives to make changes visible. This also means that the old dirty trick of volatile instead of proper synchronization can definitely fail here.". My guess would be that cores like that won't turn up on Apple laptops, but who knows. Another example is vector operations. If you want to make use of explicit vector operations, rather than relying on compiler autovectorisation, you need to write code around the shapes and operations supported by the processor. Those are different on ARM and x86 - although i think the instruction set on ARM is better-designed than that on x86, so at least it might be easier to port from x86 to ARM than vice versa. Still, here's a taste of the sort of work it takes to make vector code work properly even on different ARM chips: https://www.cnx-software.com/2017/08/07/how-arm-nerfed-neon-permute-instructions-in-armv8/ https://www.cnx-software.com/2017/08/07/how-arm-nerfed-neon-...