3 ms·

The hilarious thing about companies like this and Reddit that justified productivity for buying these machines (I love my MacBook Pro m1 max by the way) is that

The hilarious thing about companies like this and Reddit that justified productivity for buying these machines (I love my MacBook Pro m1 max by the way) is that they think there's going to be a difference in productivity if build times are shorter. I'm sure there are a couple of you out there that have building software as a bottleneck to your productivity but I reckon that's not the case for pretty much the entire industry.

BoorishBears 5y ago
Build times can affect morale and productivity in a very stepped manner. A 30 second build might be fast enough that you don't lose context, don't feel the need to work around it, etc. But suddenly 40 seconds is just long enough that now you go and browse another site while it builds, and that always takes your focus for say 60 seconds. And so for 40-60 seconds the productivity hit is the same, but then maybe at 60 seconds you now need an extra minute to get back "in the zone" And so on
fingerlocks 5y ago
It's a huge bottleneck for iOS/MacOS devs. I work on a fairly large app. Clean builds are 45 minutes on my 2019 Intel i7, and incrementals can be 5 - 10 min (which is still insane to test small changes). The M1 guys are seeing 33% - 50% reductions in build time. We have a lot of tooling that only exists to try to stay productive while running builds. Anything to speed up the build times is instant productivity gained.
- rixed 5y ago
  Weren't compile farms a thing decades ago? What happened to them?
  - bagacrap 5y ago
    that works if your machines are on the same network but less well if you are WFH
  - fingerlocks 5y ago
    We do this. But with 25 devs making dozens of builds of a day each, plus daily develop branch builds, PR builds, RC builds, et al., the queue is backed up. And attaching lldb to an iOS device with debug symbols means copying the 500mb build output back to your local machine. Really only useful when your multi-tasking back and forth between a couple of different bugs/features.
    - rixed 5y ago
      Oftentimes build farms that I've came across were implemented by leveraging the local dev machines so it would naturally scale with number of devs. Copying back the debug build is indeed more of an issue as it depends on network gears that rarely scale linearly with headcount. Yet I would expect network transfers to take only a fraction of the build time, if those 500mb of output are associated with the 10mins builds referred to in the OP, possibly even in a WFH environment these days. I'd rather believe that build farms work better in a more homogeneous environment and require more work to maintain, whereas every individual dev can manage his own machine, especially in our post-distro world (old grumpy man wanted to add: I remember a time when I was a new hire in a company and my manager asked me to attach my desktop to the build farm; I must have had a face like "Huho, sounds complicated" so he added: "I mean, just apt-get install distcc")
inkyoto 5y ago
To their credit, the build time reduction they are reporting is substantial, which is a measurable productive increase regardless of the hardware architecture. They compare (quoting verbatim): > Test: 2020 M1 (8 Core — 4 ice & 4 fire) 13 inch model with 16Gb of RAM > Control: 2019 Intel Core i7 (12 core) MacBook 16 inch Pro 64Gb RAM² and build times: > Intel 16:10 min > M1 07:41 min (that’s a 52% improvement! ) and > Intel 10:58 min > M1 6:28 min (that’s a 41% improvement! ) What is hilarious, though, is the language and statements the author uses to, ostensibly, substantiate the rationale, from a software engineer perspective: > To put this into perspective, x86 arch (Complex Instruction Set Computing) has around 981 instructions compared to around 50 for arm64. The author quotes a blog article that quotes a Quora reply that, in turn, suggests approximately 50 instructions for the armv6 / armv7 (Cortex-5) architecture. arm64 (which is armv8 and later) is a complete revamp of the 32-bit armv6/7 architectures and has more than 50 instructions. > At the “core” of it, however, and what’s contributing the most to this latest performance boost, is the smaller length of arm64 instructions coupled with an array of super-fast instruction buffers. For comparison, x86 instructions are variable in length, and anywhere between 1 and 15 bytes long. For arm64 this is fixed at 4 bytes. MIPS CPU's – that also have fixed length, 4 byte long instructions – are some of the slowest RISC CPU's out there. So, super-fast instruction buffers they are. > it’s blazing fast to fill instruction buffers up because of their size, it’s a win-win for these workloads! Hilarity has ensued, indeed. > Just like an optimised M1 Pro SoC with its specialised hardware accelerators, at Picnic, we’re striving to build a tech foundation comprising of specialised platform teams that can be accelerators of the self-service approach for the various DevOps workloads and challenges that product teams face. I am somewhat at a loss as to where and how exactly the hardware video encoders and decoders of M1 laptops fit in in a DevOps workflow and into maven builds. > For the Java Gurus amongst us, a word to the wise: Suddenly, I felt small and insignificant. After checking the blog out and noticing the ironic beard, I have concluded it was just another hipster software shop that, after purchasing a batch of M1 Pro's won't have any money left for disposable razors. Vitriole aside, I have learned something from the article, anyway. Namely, that mvnd is now supported and works on arm64 which was not the case a few months ago. I will pass the knowledge around my colleagues.

BoorishBears 5y ago

Build times can affect morale and productivity in a very stepped manner. A 30 second build might be fast enough that you don't lose context, don't feel the need to work around it, etc. But suddenly 40 seconds is just long enough that now you go and browse another site while it builds, and that always takes your focus for say 60 seconds. And so for 40-60 seconds the productivity hit is the same, but then maybe at 60 seconds you now need an extra minute to get back "in the zone" And so on

fingerlocks 5y ago

It's a huge bottleneck for iOS/MacOS devs. I work on a fairly large app. Clean builds are 45 minutes on my 2019 Intel i7, and incrementals can be 5 - 10 min (which is still insane to test small changes). The M1 guys are seeing 33% - 50% reductions in build time. We have a lot of tooling that only exists to try to stay productive while running builds. Anything to speed up the build times is instant productivity gained.

rixed 5y ago
Weren't compile farms a thing decades ago? What happened to them?
- bagacrap 5y ago
  that works if your machines are on the same network but less well if you are WFH
- fingerlocks 5y ago
  We do this. But with 25 devs making dozens of builds of a day each, plus daily develop branch builds, PR builds, RC builds, et al., the queue is backed up. And attaching lldb to an iOS device with debug symbols means copying the 500mb build output back to your local machine. Really only useful when your multi-tasking back and forth between a couple of different bugs/features.
  - rixed 5y ago
    Oftentimes build farms that I've came across were implemented by leveraging the local dev machines so it would naturally scale with number of devs. Copying back the debug build is indeed more of an issue as it depends on network gears that rarely scale linearly with headcount. Yet I would expect network transfers to take only a fraction of the build time, if those 500mb of output are associated with the 10mins builds referred to in the OP, possibly even in a WFH environment these days. I'd rather believe that build farms work better in a more homogeneous environment and require more work to maintain, whereas every individual dev can manage his own machine, especially in our post-distro world (old grumpy man wanted to add: I remember a time when I was a new hire in a company and my manager asked me to attach my desktop to the build farm; I must have had a face like "Huho, sounds complicated" so he added: "I mean, just apt-get install distcc")

inkyoto 5y ago

To their credit, the build time reduction they are reporting is substantial, which is a measurable productive increase regardless of the hardware architecture. They compare (quoting verbatim): > Test: 2020 M1 (8 Core — 4 ice & 4 fire) 13 inch model with 16Gb of RAM > Control: 2019 Intel Core i7 (12 core) MacBook 16 inch Pro 64Gb RAM² and build times: > Intel 16:10 min > M1 07:41 min (that’s a 52% improvement! ) and > Intel 10:58 min > M1 6:28 min (that’s a 41% improvement! ) What is hilarious, though, is the language and statements the author uses to, ostensibly, substantiate the rationale, from a software engineer perspective: > To put this into perspective, x86 arch (Complex Instruction Set Computing) has around 981 instructions compared to around 50 for arm64. The author quotes a blog article that quotes a Quora reply that, in turn, suggests approximately 50 instructions for the armv6 / armv7 (Cortex-5) architecture. arm64 (which is armv8 and later) is a complete revamp of the 32-bit armv6/7 architectures and has more than 50 instructions. > At the “core” of it, however, and what’s contributing the most to this latest performance boost, is the smaller length of arm64 instructions coupled with an array of super-fast instruction buffers. For comparison, x86 instructions are variable in length, and anywhere between 1 and 15 bytes long. For arm64 this is fixed at 4 bytes. MIPS CPU's – that also have fixed length, 4 byte long instructions – are some of the slowest RISC CPU's out there. So, super-fast instruction buffers they are. > it’s blazing fast to fill instruction buffers up because of their size, it’s a win-win for these workloads! Hilarity has ensued, indeed. > Just like an optimised M1 Pro SoC with its specialised hardware accelerators, at Picnic, we’re striving to build a tech foundation comprising of specialised platform teams that can be accelerators of the self-service approach for the various DevOps workloads and challenges that product teams face. I am somewhat at a loss as to where and how exactly the hardware video encoders and decoders of M1 laptops fit in in a DevOps workflow and into maven builds. > For the Java Gurus amongst us, a word to the wise: Suddenly, I felt small and insignificant. After checking the blog out and noticing the ironic beard, I have concluded it was just another hipster software shop that, after purchasing a batch of M1 Pro's won't have any money left for disposable razors. Vitriole aside, I have learned something from the article, anyway. Namely, that mvnd is now supported and works on arm64 which was not the case a few months ago. I will pass the knowledge around my colleagues.