Swift Compiler Not Optimized for Lots of Cores
Jacek Suliga (via Peter Steinberger):
When LinkedIn embraced Swift and rebuilt its flagship iOS app using (mostly) Swift, I spent a good amount of time profiling the new compiler characteristics. At that time (mid 2015), it was clear that the compiler was CPU-bound (I/O and memory had no visible impact on build speed). However, the build times were determined primarily by the number of cores and threads available to the compiler, more so than by the CPU clock speed.
Based on this analysis, we decided to use 12-core MacPros for core development, and we saw a significant (2-3 times) speedup of our builds compared with quad-core laptops.
But now:
As you can see, 12-core MacPro is indeed the slowest machine to build our code with Swift, and going from the default 24 jobs setting down to only 5 threads improves compilation time by 23%. Due to this, even a 2-core MacMini ($1,399.00) builds faster than the 12-cores MacPro ($6,999.00).
[…]
For machines with more than 4 cores consider reducing number of concurrent jobs allowed for Xcode - until the concurrency issue described above has been resolved.
Be careful with disabling Spotlight indexing for ~/Library/Developer as it will also exclude dSYM symbol files of builds and archives.
Xcode uses Spotlight to search for matching dSYM files when symbolicating crash reports. Turning off Spotlight indexing for them might break crash symbolication completely.
Update (2017-03-16): Joe Groff:
This smells like a hardware or kernel issue.
Blaming any particular component is premature. “There Is A Bug Exposed By Swift 3 Running on Sierra” is all we know.
Core count doesn’t seem to matter either, we observed the same issue on 4-core Xeon setups. Seems to be Xeon-specific.
The bug report is here.
See also: Colin Cornaby.
Update (2017-12-13): Joe Groff:
The bug is fixed. Radar for closed but Jira wasn’t updated to match.
3 Comments RSS · Twitter
[…] something I notice when building PDFs of the book or building Xcode projects (with the caveat that building Swift on the Mac Pro is surprisingly slow). But that was always going to be the problem with buying this model in 2017 — it’s […]
[…] Pro, but I don’t have the patience to keep waiting. The speed-bump1 updates are welcome but not enticing. The new Mac Pro could be shipping in late 2018 or even 2019. It might be late or supply […]
[…] would like to see a comparison with a 2017 iMac. iMacs, and even Mac minis, have outperformed Mac Pros at compilation for a while […]