Hacker News Reader

Comment by bluedino | Hacker News Reader

Today we deploy to the cloud and work on Arm/x86

Do most web developers do things that have issues being cross platform?

There are _so many_ deploy issues surfaced by eg developing on a mac and deploying to linux/aarch64 (or, in my case, developing on x86 linux). Anytime you add a dependency on a package with a native component you're likely to have something to fix.

This right here, it's just crazy. On one project we invested in a private cache of prebuilt/binary pip wheels, as much as it complicated the build and maintenance, it saved us so much time and effort in the long run, and was ultimately a productivity boost.

I really like it that the x86 monoculture is being disrupted, and enjoy the benefits of low-wattage high-performance systems, but we still have a long way to go.

For the vast, vast majority of cases a VM can solve the issue of developing for linux/arm on an arm Mac.

It doesn't help so much if your Mac is still Intel based, admittedly.

In the .NET world we're developing on Windows/x64 and deploying on Linux/ARM64 en masse at this point. I haven't personally seen an issue yet where I had to debug a Linux- or ARM64-specific issue. I think different language ecosystems have wildly differing levels of readiness for this.

The platform of course matters less and less as you move into higher-level stuff. The necessary abstractions have already been built for you.

Though even in .NET you can still get bitten by assumptions about endianness, for example.

x64 and ARM64 are both little endian on Linux and Windows; there are never endianness issues when moving from Windows/x64 to Linux/ARM64. You can freely assume little endian and that's fine in this combination. It's one of many benefits ARM64 has going for it that IBM POWER does not.

The commercial Linux world (see https://github.com/open-mpi/ompi/issues/4349) and other open source OSes (eg FreeBSD) seem to have lined up behind little-endian PowerPC. IBM still has a big-endian problem with AIX, IBM i, and Linux on Z.

Even modern C and C++ code generally ports just fine as long as you avoid things with unspecified behavior like exotic casts and weird pointer tricks. Have to watch endianness too but that doesn’t actually come up all that often. Also AFAIK there are no longer any big-endian architectures in common use.

Newer languages are even easier. Rust and Go almost always port with zero issues. Obviously the same goes for scripting and VM based languages like Java.

The architecture matters less than it used to.

If you’re higher up the stack, sure. If you want performance, you want to keep the dev/prod environment alike so that you can properly optimize

Sure if you are counting cache misses or optimizing for a specific compute unit. Few people do that outside of AI, crypto, AV codecs, simulation, etc. If you are doing that you may need to specialize per arch anyway because you’re probably using vector units.

I was speaking to whether the code will work. The answer is almost always yes. Optimizations at a higher level such as algorithm choice or where allocations are performed also are architecture neutral. This is most optimization.

s390x (IBM Z) is a big endian holdout, with IBM in the wings still quietly paying for s390x ports of various open source software.

Are you aware that x86 and ARM/POWER/RISCV memory consistency model are really different? You can encounter very sneaky multitreading bug when running on ARM/POWER/RISCV a program that you have only tested on x86.

Apple has actually put a lot of effort to make the x86 to ARM transition as smooth as possible regarding memory consistency model, this is a strong indication that it's not as trivial as you seem to think.

You have to be doing pretty strange things with threads, without using mutexes or atomic instructions, to have a problem with this.

RISC-V has a standardised (optional) TSO memory model mode, plus "fence.tso" instruction that works in normal mode, even on CPUs that predate it (it defaults to the stronger "fence rw,rw" in that case). Well, assuming the CPU core designer read the spec carefully and doesn't trap on unknown "fence" instructions (looking at you, THead...)

I've encountered a couple of NPM packages with native components which didn't work on a M series MacBook. Languages that uses native libs as part of their own packages are still a risk to do multi arch development/deployment.

Unfortunately so, native modules for Node are starting to be written more and more in rust rollup and parcel are two examples. Unlike previous modules written in C++ if there's no prebuilt binary for your platform, they won't even try to build locally, just flat-out wont install despite building fine if you do it all manually.

Reply on news.ycombinator.com