3 ms·

I've got a coworker who still has an Intel MacBook Pro, 8-core i9 and all that, and I've been on M chips since they launched. The other day he was building some

I've got a coworker who still has an Intel MacBook Pro, 8-core i9 and all that, and I've been on M chips since they launched. The other day he was building some Docker images while we were screensharing and I was dumbfounded at how long it took. I don't think I can even remember a recent time when building images, even ones pushed to CDK etc., takes more than a minute or so. We waited and waited and finally after 8 minutes it was done. He told me his fans were going crazy and his entire desk was hot after that. Apple silicon is just a game changer.

grahamj 2y ago
For sure. I had one of those for work when I got my personal M1 Air and I couldn't believe how much faster it was. A fanless ultraportable faster than an 8-core i9! I was so happy when I finally got an M1 MBP for work because as you say Docker is so much faster on it. I feel like I don't wait for anything anymore. Can't even imagine these new chips.
- MBCook 2y ago
  Same situation for me. I’m going to be very happy when it’s time to replace my Intel MBP at work. It’s rarely loud, but boy it likes to be warm/toasty at the stupidest things.
rahkiin 2y ago
Oh I know the feeling… when using ict-managed windows laptops at work
moondev 2y ago
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?
JohnBooty 2y ago
That was what finally got me to spend the cash and go with Apple Silicon - we switched to a Docker workflow and it was just doooooog slow on the Intel Macs. But this M1 Max MBP is just insane. I'm nearly 50 and it's the best machine I've ever owned; nothing is even close.

grahamj 2y ago

For sure. I had one of those for work when I got my personal M1 Air and I couldn't believe how much faster it was. A fanless ultraportable faster than an 8-core i9! I was so happy when I finally got an M1 MBP for work because as you say Docker is so much faster on it. I feel like I don't wait for anything anymore. Can't even imagine these new chips.

MBCook 2y ago
Same situation for me. I’m going to be very happy when it’s time to replace my Intel MBP at work. It’s rarely loud, but boy it likes to be warm/toasty at the stupidest things.

rahkiin 2y ago

Oh I know the feeling… when using ict-managed windows laptops at work

moondev 2y ago

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?

JohnBooty 2y ago

That was what finally got me to spend the cash and go with Apple Silicon - we switched to a Docker workflow and it was just doooooog slow on the Intel Macs. But this M1 Max MBP is just insane. I'm nearly 50 and it's the best machine I've ever owned; nothing is even close.