4 ms·

Sounds like they were building an aarch64 image, building an x86_64 image on Apple Silicon will also be slow - unless you are saying the M* builds x86_64 faster

Sounds like they were building an aarch64 image, building an x86_64 image on Apple Silicon will also be slow - unless you are saying the M* builds x86_64 faster than an i9?

robotresearcher 2y ago
Are you saying it's faster to build a binary with native architecture? Why is that?
- 0x457 2y ago
  Because there two ways to get to the same result: - use native toolchain to produce artifacts for a different architecture - use emulation to run different arch toolchain to produce different arch artifacts First one is fast, second one is slow. In docker only second variant is possible.
  - PoignardAzur 2y ago
    That doesn't sound right. It's not like you need to run in WebAssembly to produce WebAssembly binary. Why would you need to emulate x86 to produce x86-shaped bytes?
    - kapoolo 2y ago
      Emulating the target architecture's SDK can be much easier and simpler to setup and avoid mistakes. You do not need to make any changes or configuration to make it compile. For exmaple, that is generally the way you cross compile Flatpaks in cli or ide. In, for example, GNOME Builder you can just select the device you want to build for, like your smartphone, and it uses QEMU to emulate the entire SDK in the target architecture, you can also seemlessly run the Flatpak on your host through QEMU user mode emulation too.
    - 0x457 2y ago
      Well, WASM runs in a VM, not on a hardware? There isn't hardware that runs WASM directly (at least nothing serious, maybe some hobby FPGA or POC). So when you compiled to WASM you're going with route #1. WASM was designed with this this in mind.
      - robotresearcher 2y ago
        A compiler doesn’t need to run the instructions it generates. Why should cross-compilation be slower than native compilation?
        0x457 2y ago
        It doesn't need (unless it does in some cases), but entire build process needs to be aware of what needs to be native and what doesn't. Mainly a lot of issue would come from linker. Yes, it's not part of the compilation technically, but aside from hellworld.c everything you build would probably require linker at one point or another. Then there are some gcc quirks: - for gcc compilation target is defined when gcc is compiled, so only way to cross-compile with gcc that I know of is emulation of target arch and runing gcc for target arch However, we're talking about docker containers here, emulation would be the default way and path of least resistance. Again, I will reiterate: every cross-compilation strategy falls into one of these two buckets. In some cases what I've describe in #1 is possible (WASM, java bytecode or really (almost) anything that targets a VM), in some cases it isn't and then you gotta go with #2 (docker, gcc)
        robotresearcher 2y ago
        How about Xcode's LLVM on an Intel Mac building for ARM iOS?
        0x457 2y ago
        Two things here: - clang and LLVM don't have that GCC quirk (LLVM support less platforms, so give gcc some credit) - it was in apple's financial interest make sure their things are easy to cross-compile. - linker job is extremely straighforward in case of iOS - everything is provided by either apple or application developer

Sounds like they were building an aarch64 image, building an x86_64 image on Apple Silicon will also be slow - unless you are saying the M* builds x86_64 faster than an i9?

robotresearcher 2y ago

Are you saying it's faster to build a binary with native architecture? Why is that?

0x457 2y ago
Because there two ways to get to the same result: - use native toolchain to produce artifacts for a different architecture - use emulation to run different arch toolchain to produce different arch artifacts First one is fast, second one is slow. In docker only second variant is possible.
- PoignardAzur 2y ago
  That doesn't sound right. It's not like you need to run in WebAssembly to produce WebAssembly binary. Why would you need to emulate x86 to produce x86-shaped bytes?
  - kapoolo 2y ago
    Emulating the target architecture's SDK can be much easier and simpler to setup and avoid mistakes. You do not need to make any changes or configuration to make it compile. For exmaple, that is generally the way you cross compile Flatpaks in cli or ide. In, for example, GNOME Builder you can just select the device you want to build for, like your smartphone, and it uses QEMU to emulate the entire SDK in the target architecture, you can also seemlessly run the Flatpak on your host through QEMU user mode emulation too.
  - 0x457 2y ago
    Well, WASM runs in a VM, not on a hardware? There isn't hardware that runs WASM directly (at least nothing serious, maybe some hobby FPGA or POC). So when you compiled to WASM you're going with route #1. WASM was designed with this this in mind.
    - robotresearcher 2y ago
      A compiler doesn’t need to run the instructions it generates. Why should cross-compilation be slower than native compilation?
      - 0x457 2y ago
        It doesn't need (unless it does in some cases), but entire build process needs to be aware of what needs to be native and what doesn't. Mainly a lot of issue would come from linker. Yes, it's not part of the compilation technically, but aside from hellworld.c everything you build would probably require linker at one point or another. Then there are some gcc quirks: - for gcc compilation target is defined when gcc is compiled, so only way to cross-compile with gcc that I know of is emulation of target arch and runing gcc for target arch However, we're talking about docker containers here, emulation would be the default way and path of least resistance. Again, I will reiterate: every cross-compilation strategy falls into one of these two buckets. In some cases what I've describe in #1 is possible (WASM, java bytecode or really (almost) anything that targets a VM), in some cases it isn't and then you gotta go with #2 (docker, gcc)
        robotresearcher 2y ago
        How about Xcode's LLVM on an Intel Mac building for ARM iOS?
        0x457 2y ago
        Two things here: - clang and LLVM don't have that GCC quirk (LLVM support less platforms, so give gcc some credit) - it was in apple's financial interest make sure their things are easy to cross-compile. - linker job is extremely straighforward in case of iOS - everything is provided by either apple or application developer