Hacker News new | ask | show | jobs
by BenoitP 2394 days ago
> as I don't believe most companies would bother to port their software to another architecture

For a Java/Node/Python application, this means changing one line in a docker file, and running preprod/integration tests.

5 comments

> For a Java/Node/Python application, this means changing one line in a docker file, and running preprod/integration tests.

Ironically, the theory contradicts the practice and native code is often the easiest to port on new archs.

I have ported to ppc64be, POWER, armv7 and aarch64 several HPC stacks, it is often the native app made in C/C++/Fortran which is the easiest to port/recompile/cross-compile simply because:

- Their build system has been made from the beginning to handle multiple architectures.

- The compilers for C/C++ are the first thing to be ported and tested on a new arch.

At the opposite, python / node / java embed pretty often native modules hidden somewhere, with hand rolled compile scripts in pip / npm / maven and which are everything excepted robust and portable.

This hasn't been the case for most Java projects I deal with, native dependencies are fairly rare. Can't comment on Python or Node.
Python libraries frequently aren't only in Python, and use native bindings. Node packages less so, but it still happens.

Java might surprise you, too, especially on EMR. I've found math, compression, and machine learning libraries that reach out to native code using JNI.

All of the major distribution families support Arm archs and the heavy lifting for most of the things that reach out to native code have already been ported.

Native libraries are most often used to make boring things faster, use popular C libraries, and are already ported.

Unless your in-house library is using native bindings for custom code, it very likely will be a drop-in replacement.

ARM isn't so esoteric these days like it might have been 5-10 years ago.

Definitely exciting news! For some reason I was picturing that you might have difficulty building things like xgboost or getting an optimized version of BLAS, but that doesn't seem to be the case. (the former is supported and the latter is important enough that ARM ships their own version)
That's probably why EMR doesn't support ARM-based instances [1].

[1]: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-s...

Disclosure: I work at AWS

Stay tuned!

Assuming you have no native dependencies, which most bigger applications have somewhere in their dependency graph.
This is why writing 100% Pure Java is so important.
Heh, and useless. I was about 20 lines into small example. I needed the stat() command... not in java.... sigh.
I rented a cheap ARM-based machine last year, just for running off-site monitoring from.

My monitoring application was written in golang, and that made cross-compilation trivial - although I guess I'd made a little extra-effort to keep it all native and avoid CGO.

The performance won't be the same though, as things might be much more optimised for x86-64.