Does anyone have any anecdoctal evidence around the snappiness of VsCode with Apple Silicon? I very begrudgingly switched over from SublimeText this year (after using it as my daily driver for ~10yrs). I have a beefy 2018 MBP but VScode just drags. This is the only thing pushing me to upgrade my machine right now but I'd be bummed if there's still not a significant improvement with an m3 pro.
Tracking developer build times to decide if the M3 MacBook is worth upgrading
11–20 of 432 posts
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#12Does anyone have any anecdoctal evidence around the snappiness of VsCode with Apple Silicon? I very begrudgingly switched over from SublimeText this year (after using it as my daily driver for ~10yrs). I have a beefy 2018 MBP but VScode just drags. This is the only thing pushing me to upgrade my machine right now but I'd be bummed if there's still not a significant improvement with an m3 pro.
I don't use VSCode but most of my team do and I frequently pair with them. Never noticed it to be anything other than very snappy. They all have M1s or up (I am the author of this post, so the detail about their hardware is in the link).
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#13We've found that distributed building has pretty much eliminated the need to upgrading developer workstations. Super easy to set up, too.
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#14Importing a couple thousand RAW pictures into a Capture One library would take 2 h on my 2017 iMac. 5 min on my m3 mbp pro. Geekbench score differences were quite remarkable. I am still wondering if I should return it, though
Go on, I’ll bite: why?
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#15Does anyone have any anecdoctal evidence around the snappiness of VsCode with Apple Silicon? I very begrudgingly switched over from SublimeText this year (after using it as my daily driver for ~10yrs). I have a beefy 2018 MBP but VScode just drags. This is the only thing pushing me to upgrade my machine right now but I'd be bummed if there's still not a significant improvement with an m3 pro.
It's a bummer because one of them is also a 2018 fully loaded and I would have a hard time even selling it to someone because of how much better the M2/M3 is. It's wild when I see people building hackintoshes on like a Thinkpad T480 ... its like riding a pennyfarthing bicycle versus a ducati.
My M2 Air is my favorite laptop of all time. Keyboard is finally back to being epic (esp compared to 2018 era, which I had to replace myself and that was NOT fun). It has no fan so it never makes noise. I rarely plug it in for AC power. I can hack almost all day on it (using remote SSH vscode to my beefy workstation) without plugging in. The other night I worked for 4 hours straight refactoring a ton of vue components and it went from 100% battery to 91% battery.
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#16We've found that distributed building has pretty much eliminated the need to upgrading developer workstations. Super easy to set up, too.
I’m not sure this would work well for our use case. The distributed build systems only really benefit from aggressively caching the modules that are built, right? But the majority of the builds we do are almost fully cached, having changed just one module that needs recompiling then the linker sticks everything back together, which the machines would then need to download from the distributed builder and at 300MB a b…
Not really, you have more cores to build on. Significant difference for slow to compile languages like C++.
> I may have this totally wrong though. Would distributed builds actually get us a new binary faster to the local machine?
Yes, again, for C++.
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#17Moreover, if your whole stack (plus your test suite) doesn't fit in memory, what's the point of buying an extremely expensive laptop? Not to mention constantly replacing them just because a newer, shinier model is released? If you're just going to test one small service, that shouldn't require the fastest MacBook.
To test an entire product suite - especially one that has high demands on CPU and RAM, and a large test suite - it's much more efficient and cost effective to have a small set of remote servers to run everything on. It's also great for keeping dev and prod in parity.
Businesses buy MacBooks not because they're necessary, but because developers just want shiny toys. They're status symbols.
Re: Tracking developer build times to decide if the M3 MacBook is worth upgrading
#18The upshot: M3 Pro is slightly better than M2 and significantly better than M1 Pro is what I've experienced with running local LLMs on my Macs; currently M3 memory bandwidth options are lower than for M2, and that may be hampering the total performance. Performance per watt and rendering performance are both better in the M3, but I ultimately decided to wait for an M3 Ultra with more memory bandwidth before upgrading…
This is pretty much aligned with our findings (am the author of this post). I came away feeling that: - M1 is a solid baseline - M2 improves performance by about 60% - M3 Pro is marginal on the M2, more like 10% - M3 Max (for our use case) didn’t seem that much different on the M3 Pro, though we had less data on this than other models I suspect Apple saw the M3 Pro as “maintain performance and improve efficiency” whi…
On LLMs, the issue is largely that memory bandwidth: M2 Ultra is 800GB/s, M3 Max is 400GB/s. Inference on larger models are simple math on what's in memory, so the performance is roughly double. Probably perf / watt suffers a little, but when you're trying to chew through 128GB of RAM and do math on all of it, you're generally maxing your thermal budget.
Also, note that it's absolutely incredible how cheap it is to run a model on an M2 Ultra vs an H100 -- Apple's integrated system memory makes a lot possible at much lower price points.