4 ms·

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

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

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.