3 ms·

> So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common. Ar

> So much of my work is dependent on running linux executables in Docker for later deployment on a server running Intel. That is certainly extremely common. Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Because unless you are, I don't see what the issue would be with multiarch, assuming you don't manually compile the binaries for your containers. Also AArch64 cloud servers are a commodity available from at least Amazon right now, and the hardware is available on the open market. Not to mention, if you're running Docker right now, it's not running natively on macOS anyway. If you're just looking to test basic correctness, then surely you can run your dockers in QEMU or whatever AMD64 DBT/emulator is made available. Apple has a history of shipping good emulators (namely Rosetta and the 68k emulator) for their previous architectures when they change ISA.

tatersolid 7y ago
> Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything. You really need to develop and QA on the expected deployment platform
- microcolonel 7y ago
  > "Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything." Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others. It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.
  - tatersolid 7y ago
    There are so many different flavors of AMD64 that it’s not even a single target from my perspective. Check out the quantity of compiler flags and ifdef statements you see in just about everything. I’ve seen binaries in production run at 30% of the speed seen DEV/QA. These would also segfault every few hours. But debug builds ran fine in production. Root cause in that case was the Intel server had some hardware instructions available that the Intel developer and QA systems didn’t. The runtime chose to use these fancy new instructions, which turned out to be a buggy and slow code path. Again, if you’re not doing DEV/QA on hardware (and OS, dependency, and firmware versions) that differ from production you will eventually be bitten. Everything is so complex and there are so many layers involved it is impossible to have confidence. Containers make this worse in my opinion by adding another complex (and buggy) abstraction layer.

tatersolid 7y ago

> Are you writing code that is hand-tuned for codegen on one architecture, or which relies on custom assembly to meet basic performance requirements? Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything. You really need to develop and QA on the expected deployment platform

microcolonel 7y ago
> "Actually, most modern dev stacks do exactly this. You typically have some core libraries or runtime that includes heavily optimized or even hand-assembled crypto primitives. Even bog-standard “mainstream” Java or .NET code calls into system libraries which use AES, GCM, or SHA-256-specific instructions for accelerating TLS. TLS is in just about everything." Sure, but when it comes to platform enablement, that only really needs to be done once per vertical/native dependency. AArch64 has all of those things you listed. Don't know about .NET (though there's not that much .NET development on Linux, at least not when compared with the amount of Node and Java), but OpenJDK, Node, C/C++/Rust/Go toolchains all have mature support for AArch64, among others. It's obviously less mature than the 40-year-old x86 ecosystem, but it's basically all there. Furthermore, the ease with which new ISAs can be adopted by toolchains and libraries is accelerating, so POWER and RISC-V are also getting there in terms of software availability.
- tatersolid 7y ago
  There are so many different flavors of AMD64 that it’s not even a single target from my perspective. Check out the quantity of compiler flags and ifdef statements you see in just about everything. I’ve seen binaries in production run at 30% of the speed seen DEV/QA. These would also segfault every few hours. But debug builds ran fine in production. Root cause in that case was the Intel server had some hardware instructions available that the Intel developer and QA systems didn’t. The runtime chose to use these fancy new instructions, which turned out to be a buggy and slow code path. Again, if you’re not doing DEV/QA on hardware (and OS, dependency, and firmware versions) that differ from production you will eventually be bitten. Everything is so complex and there are so many layers involved it is impossible to have confidence. Containers make this worse in my opinion by adding another complex (and buggy) abstraction layer.