mattcomi6d ago
Roast my config. I’m probably gonna checkout this MacBook tomorrow. It’ll be a big step up from my M1 Pro I’m sure.
Show threadMatt Massicotte6d ago
@mattcomi why so much ram?
Show threadmattcomi6d ago
@mattiem future proof for the next 5-6 months.
Show threadMatt Massicotte6d ago
@mattcomi ram is so important if you are running virtual machines. When I used to do that, there was never enough…
Show threadmattcomi6d ago
@mattiem nah my honest answer is just I want to much much much more than I currently have on my M1. Xcode is horribly slow and I’m constantly playing janitor with running apps to free up RAM.
Show threadMatt Massicotte6d ago
@mattcomi ohh that’s interesting to hear! I’ve been trying to figure out if ram will help with the development experience there.
Show threadHelge Heß6d ago
@mattiem @mattcomi I know someone who is putting DerivedData into a RAM disk and claims that this is a great idea. I think it could be.
Show threadMatt Massicotte6d ago
@helge @mattcomi this would imply that disk speed is a major bottleneck here, which I find slightly surprising but maybe I should not…
Show threadHelge Heß
@mattiem @mattcomi The SSDs are *very* fast now, but RAM is still much, much faster.
Mar 15 at 5:52pmWeb
Show threadMatt Massicotte6d ago
@helge @mattcomi yes I am aware of this
Show threadHelge Heß6d ago
@mattiem @mattcomi My concern would be that the speed is eaten up by all the FS layers, but who knows. Sole reason I consider a 48+ machine tbh 😬
Show threadHelge Heß6d ago
@mattiem @mattcomi “this would imply that disk speed is a major bottleneck” I think it actually is for Swift targets, they are not multi core constrained but disk plus single core perf.
The only time I see my CPU exercised is when compiling swift-nio-ssl, ie BoringSSL, which sucks all cores available.
Show threadHelge Heß6d ago
@mattiem @mattcomi That’s separate to you building the compiler, which is C++ and should scale to the available cores.
Show threadMatt Massicotte6d ago
@helge I don’t know if the language matters here as much as the build system being used? The “compiler project” includes a huge amount of swift code, in the standard library for example.
Show threadHelge Heß6d ago
@mattiem It does because Swift compilation units are not self contained, unlike C units
Show threadAndrew Roan6d ago
@helge @mattiem @mattcomi At least with Xcode projects, I see all 16 cores max out whenever I build. It doesn’t have to be limited to single thread.
Show threadHelge Heß6d ago
@roanutil @mattiem @mattcomi You must be doing ObjC projects then. I'm mostly doing Swift and that usually is bound to a single CPU. It can scale out if you have a lot of independent modules, but that seems rare.
As mentioned the one occasion I see system load is if swift-nio-ssl is being built for the millionths time (it's C++, so it actually runs parallel). BTW that there is no binary support in SPM is just a ridiculous waste of time and resources.
Show threadAndrew Roan6d ago
@helge @mattiem @mattcomi There’s no ObjC, it’s all swift. The workspace is broken into a lot of targets which helps with compiler parallelism. The main reason for the many targets is that they’re easier to reason about. The compiler parallelism is a nice bonus though.
Show threadAndrew Roan6d ago
@helge @mattiem @mattcomi We have 105 framework targets that support the app targets for various environments and MAMs. It's not like all of those frameworks are independent either. But there's enough independence that there isn't a bottleneck while waiting for some particular framework to build.