Certainly scripted languages run fine on ARM Linux, however there are some caveats worth mentioning. ARM JIT compilers for some platforms and languages may be not as mature or performant as their x86 counterparts since they haven't been battletested as much in the server landscape. Also, if you are using C extensions that don't compile to ARM, obviously that is going to affect you. And finally, if any part of your CI is building images containing native code (even if all of your code is say, Python,) you are going to need to duplicate that process for ARM, possibly requiring some retooling of your build system.
I am very curious to see how it plays out. I've been waiting for a cloud ARM offering from a major provider for a while now (there have been some smaller but notable players like Scaleway, but demand seemed to always outrun supply, and I couldn't get VMs running near me in America.)
I use an ARM laptop for travel. I've had a lot of problems with running Python code. Mostly data-science related. A lot of recompilation is required, which is a hassle. Also, sometimes you'll be constrained in what libraries you can use, because some of them simply don't work on ARM, due to ARM specific bugs. NUMBA is one that caused a lot of headache, but I think they got it fixed since.
Asus C201P. ~180 euros. Very durable, battery lasts for 10 hours easy, more if only programming. It's preinstalled with ChromeOS. Installing Linux took some tinkering; there are some blog posts around that were very helpful.
Yes, that’s exactly what the linked article mentions
> If your application is written in a scripting language,
> odds are that you can simply move it over to an A1 instance
> and run it as-is. If your application compiles down to
> native code, you will need to rebuild it on an A1 instance.
I don’t think it is a moat, just stating the simple case.
I’ve spent a lot of time making cross-compile work for complicated builds. It can be tedious and frustrating fighting compilers and build systems to get it right.
Sometimes it is necessary because the target didn’t have a complete native toolchain, but other times because the target was just so incredibly slow for large builds.
I haven’t built anything with them, but these Arm servers appear to be neither of those two cases.
I doubt it's that hard if you're using a language with a reasonable cross-compile toolchain. That will probably influence choice of technology for new things aimed at this kind of performance envelope.
No doubt a lot of existing software will be left out by cross-compilation being too much of a pain.
If you use a modern gitops CI/CD type workflow building containers automatically then you don't need to worry about the manual building part either - this can be done cleanly with automation
They acquired Annapurna Labs back in 2015 - I'm sure this is based on their work, they (Annapurna) were already building chips for Synology prior to the acquisition.
Depending on how you define "properly written." It was easy to write seemingly proper code that assumed TSO and worked for x86 but does not work on architectures with weak memory consistency.
Code that assumes TSO is likely broken on x86 as well. The use of the volatile keyword doesn't really change that in any meaningful way either, given that part of the language is a bit under-specified. Basically, C compilers are free to do a lot of non-obvious optimizations which can reorder around volatile accesses.
Put another way, there isn't anything in the base C spec which can provide a guaranteed memory ordering barrier, which is why you absolutely have to depend on 3rd party specifications to get those guarantees. For example, if a program is using pthreads or openMP, their synchronization primitives must be used as well to assure portability.
That isn't to say that given a particular piece of code and compiler/switches/version the resulting program is wrong, just that its quite possible changing compilers/flags may result in "incorrect" code generation.
True, but outside of memory ordering, x86_64 and ARM64 are probably among the easiest to port between. Endianness, alignment and type sizes are the same, for example. Plus a lot of code already has been ported to both.
