"Perversely, developers, who by nature of their profession best understand exactly what an architecture transition like this entails, might be among the few professions who can’t yet move their primary computing to an Apple Silicon device by nature of the software tools they depend upon. (Some developers can move now, and — because Xcode running on the M1 compiles code so much faster than any Intel MacBook — are rejoicing.)"
I know that HN has many more active/vocal webdevs than native software developers, and so the point may be lost on some. I suspect that Gruber doesn't understand why his point is actually so completely accurate.
Developers (native ones at least) need to compile, a lot. Compilation is an embarrassingly parallel task: if you've got N cores, you can use N cores and get a linear speedup for every expansion in N you are offered.
The M1 seems like an awfully nice system for people concerned about CPU/Watt, and an awfully nice system who want a very powerful bit of hardware to run macOS on.
What it remains is a less-than-top-of-the-line system for people who care about CPU/$ or just maxCPU. No doubt if you're used to building native code on existing MacBook Pro or even a Mini, the M1 systems will seem incredible.
But I'm building my software on a 12 core, 32GBM VM running on a threadripper, while still able to read Hacker News and listening to Soma FM in the Linux/Debian host environment, and for people like me (especially the even tinier set who also are net-zero for electrical supply thanks to solar PV), the M1 systems are just not interesting so far.
But then, as Gruber said, I'm a developer, and this mismatch is caused by the set of tools I use.
I compile a lot. Every day. Almost daily in Java, Objective C, and C++ (Yes, I work actively on all three languages these months).
90% of the time I compile one file (the one I just changed) and then I link. Linking is not parallel and it takes about 4-15 seconds (dep. on the project/lang.).
I use an i9 with 8 cores, but I suspect that a CPU with fewer cores, that go really fast for seconds before throttling would be quite good for most of what I do during the day. Including testing+debugging the executable.
Recompiling everything takes minutes. It happens maybe once per hour, and I often combine the recompile with a coffee-break. So since it happens rarely it doesn't matter if that takes 0.5-5 minutes (dep. on project).
I don't mind waiting for the recompile, but I hate changing a few lines, compiling, waiting for 20 seconds, and then testing. I find that hose medium length waits destroy flow and creativity during the day.
I would definitely prefer fast single-file compilation + linking + testing, over fast full project recompiles.
In summary, I think these M1 devices will actually be great for developers using compiled languages.
It does depend on project scale, and what you're doing with it.
A full compile of my project on my 2950X (16 core threadripper gen 1) takes 4m20s.
If I'm messing around with a new GUI-visible feature, then yes, often it's 1 or 2 files to compile, then a link step (thank you, llc, for parallel linking). Anything can handle that, even if it is C++ :)
But if I'm doing a change to the core headers, it typically means multi-minute wait even on the threadripper. And that's something I've been doing for a couple of months now, working on basic architectural changes. The idea of doing such work on machine that took 50-100% longer to do a full build would be a serious problem.
I don't see anything on the horizon (yet) that uses Apple silicon that helps that kind of development process.
Yes. Agreed. Header files really kill productivity in C++ projects as they grow beyond 1-500.000 lines.
I admit, sometimes I work around or postpone a fix in a vital header file, because I know it will initiate a recompile and undesired wait.
I simply don't understand this isn't properly fixed after 30 or so years. It is so inefficient for developer time, cpu resources, and overall energy usage that it becomes ridiculous sometimes.
I remember moving from Turbo Pascal in the mid 90s over to C and C++ and wondering what the hell was going on...
Yeah, it's like the transition to ssds. Everyone who didn't had one thought "whats the point" and anyone who made the switch never could go back. These m1 are so fast you can't believe it until you really threw your own workflow against it.
I do frontend stuff and most of the node.js ecosystem is single threaded. Webpack and npm installs are more than 2x as fast on this m1 as on any machine I ever owned. And all this while not even getting warm and battery lasting forever.
> Compilation is an embarrassingly parallel task: if you've got N cores, you can use N cores and get a linear speedup for every expansion in N you are offered.
Somebody should let the Javascript world know that. Both Webpack and TypeScript are single threaded by default and it's a pain in the ass to get them to use more threads. So my 12 core CPU mostly sits around twiddling it's thumbs while I compile code for work.
The M1 is their entry level CPU and it's compiling software as fast as a fast i7 or i9. They don't have very far to go to catch ThreadRippers, 24 Firestorm cores should more than do it.
The current M1 has 4 firestorms. Geekbench gives a score of ~7400 for the M1s. Assuming the firestorms represent some 80% of the CPU power and multiplying by 6 (6x4=24), we would get a Geekbench score around 35000.
That would place it between a 32- and 64-core threadripper.
I know, that's a lot of handwaving!
I must admit, while I have a lot of doubts that Apple can simply scale up to 24+ core M1s while having acceptable yield, what they have going for them is low amount of heat with current core count and clock speed. So I think, they might also be able to increase the clock speed significantly from here.
But, I have been wondering if their plan is instead to create an m1x (4+8 core), and then combine up-to 3-4 m1xs in the Mac Pro and iMac Pro machines to get up-to 24-32 total cores. That way they might still have high yield and only a few lines of chips (keeping the supply chain tight, which seems like Apple / Tim Cook's MO).
I'm interested to see what Apple comes out with for the higher-end MacBook Pros, iMac Pro, and Mac Pro. I expect to see the M1 used in the iMacs, although ...
That could be a single higher-end chip, with possible multi-socket support for the Mac Pro? Or it could be two chips: one for the iMac and laptops, and a beefier one for the Pro desktops?
Either way, they absolutely need to compete with Zen3 on highly parallel loads. The co-processors (GPU, NPU, etc) are an advantage for general usage, but for many devs, basic CPU core counts and high I/O speeds are the winner.
I hope they come up with something that's equivalently good as the M1 is as a low-end laptop chip.
Laptops are almost always going to weight CPU/Watt fairly strongly.
As a developer, I don't give a damn about CPU/Watt, I care only about maxCPU, for a given budget.
I don't know why any company would build a laptop that focused on maxCPU. Gaming laptops are perhaps the exception, but Apple has historically not really participated in this subset.
>for many devs, basic CPU core counts and high I/O speeds are the winner.
I have a Lenovo Y700, which is a CPU beast of a laptop (built mostly for gamers, I believe). It's powerful enough to make working on my project feasible, and indeed when travelling, it is what I use, reasonably happily.
But most laptops just can't compile 800k lines of C++ fast enough to make them practical as a development system for that type of software, so the "type of dev" I am really does have something to do with it.
And yes, the new Apple laptops are not for me, which was my whole precise point, and (I believe) Gruber's point in that quoted text, however unintentional.
I'd take one of the Minis though, just to see how fast it really is :)
Fair enough, but it's probably better to compare the M1 to the CPU in your laptop then, no? Not the threadripper in your desktop. And in that case maybe the M1 IS for you, since I'd be willing to bet it outperforms your existing laptop. Assuming I've found the right computer, my existing (non-M1) Macbook Pro is beefier than your Lenovo, and it gets outperformed by the M1 too[1].
Just seems pretty disingenuous tbh. The argument that you need a seriously beefy threadripper machine to compile your code because you're an 800k LOC C++ developer falls a bit flat when you tell us later that you also compile code on your Lenovo Y700.
> Fair enough, but it's probably better to compare the M1 to the CPU in your laptop then, no? Not the threadripper in your desktop.
Although I appreciate the ability as a software developer to "work anywhere", if I was restricted to working only the Y700 I can guarantee you that certain development avenues would happen very differently, if at all. The laptop works fine as a machine to use "when I have to", but if I'm doing "deep" development, it's a PITA and makes me lose focus too much because of the delays in the edit-compile-test cycle.
I have absolutely no doubt that the M1 macbooks will easily outperform the Y700, along with most other computers I've ever owned.
It remains true, for now, that if you actually care about maxCPU (with a linearly parallelizable workload) (which I do for at least half of my development work), the current M1 machines are not the top of the line. I would tend to agree with anyone who suggests that this will likely change in the near future.
Ok, but again, this has really nothing to do with what kind of developer you are, it has to do with the fact that you are apparently not in the market for a new laptop.
Because if you were, the M1 laptops are the best in the market for the linearly parallelizable workloads you are talking about.
As a developer, I find long battery life, while still being able to work, to be quite nice. Power per watt is how this want is accomplished by laptop and OEM parts manufacturers.
"Perversely, developers, who by nature of their profession best understand exactly what an architecture transition like this entails, might be among the few professions who can’t yet move their primary computing to an Apple Silicon device by nature of the software tools they depend upon. (Some developers can move now, and — because Xcode running on the M1 compiles code so much faster than any Intel MacBook — are rejoicing.)"
I know that HN has many more active/vocal webdevs than native software developers, and so the point may be lost on some. I suspect that Gruber doesn't understand why his point is actually so completely accurate.
Developers (native ones at least) need to compile, a lot. Compilation is an embarrassingly parallel task: if you've got N cores, you can use N cores and get a linear speedup for every expansion in N you are offered.
The M1 seems like an awfully nice system for people concerned about CPU/Watt, and an awfully nice system who want a very powerful bit of hardware to run macOS on.
What it remains is a less-than-top-of-the-line system for people who care about CPU/$ or just maxCPU. No doubt if you're used to building native code on existing MacBook Pro or even a Mini, the M1 systems will seem incredible.
But I'm building my software on a 12 core, 32GBM VM running on a threadripper, while still able to read Hacker News and listening to Soma FM in the Linux/Debian host environment, and for people like me (especially the even tinier set who also are net-zero for electrical supply thanks to solar PV), the M1 systems are just not interesting so far.
But then, as Gruber said, I'm a developer, and this mismatch is caused by the set of tools I use.