4 ms·

> 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 lin

> 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.

deleted 7y ago
[deleted]
Matthias247 7y ago
Assuming you have no native dependencies, which most bigger applications have somewhere in their dependency graph.
- sanxiyn 7y ago
  This is why writing 100% Pure Java is so important.
  - sliken 7y ago
    Heh, and useless. I was about 20 lines into small example. I needed the stat() command... not in java.... sigh.
enitihas 7y ago
The performance won't be the same though, as things might be much more optimised for x86-64.
zten 7y ago
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.
- colechristensen 7y ago
  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.
  - zten 7y 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)
- Dunedan 7y ago
  That's probably why EMR doesn't support ARM-based instances [1]. [1]: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-supported-instance-types.html https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-s...
  - _msw_ 7y ago
    Disclosure: I work at AWS Stay tuned!
adev_ 7y ago
> 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.
- matt2000 7y ago
  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.
stevekemp 7y ago
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.

deleted 7y ago

[deleted]

Matthias247 7y ago

Assuming you have no native dependencies, which most bigger applications have somewhere in their dependency graph.

sanxiyn 7y ago
This is why writing 100% Pure Java is so important.
- sliken 7y ago
  Heh, and useless. I was about 20 lines into small example. I needed the stat() command... not in java.... sigh.

enitihas 7y ago

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

zten 7y ago

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.

colechristensen 7y ago
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.
- zten 7y 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)
Dunedan 7y ago
That's probably why EMR doesn't support ARM-based instances [1]. [1]: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-supported-instance-types.html https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-s...
- _msw_ 7y ago
  Disclosure: I work at AWS Stay tuned!

adev_ 7y ago

> 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.

matt2000 7y ago
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.

stevekemp 7y ago

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.