Episode 0. Hack vs Mac. Xcode build time

Next episode The cost of hack

This article begins a series of several on the use of Hackintosh in everyday work, and especially with the Xcode 9 IDE, and will be more interesting to objc / swift developers. On the other hand, my first hack was built when I was not familiar with these languages ​​and can be useful even to those who are not a developer, but for one reason or another want to try Mac OS. At that time, I had a fairly powerful Sony working laptop and a great desire to start programming for iOS. But I was not ready to spend a certain amount of money on a Mac without knowing whether it would be useful to me in the end or not.

Therefore, it was decided to build Hackintosh, which eventually allowed me to enter the world of developing applications for Apple devices. In the first article, I want to pay attention to the build time of projects in the Xcode environment. Developers are well aware of how much speed has decreased and the build time of projects has increased with the release of version 9 of this IDE, especially in swift or a mix from objc / swift. You can speed up compilation time, firstly, by setting up various flags and scripts, and secondly, by refactoring the code base directly.

But in this episode, attention will be paid to the third component of development tools, namely the hardware.

Since there is not much information on the build time of projects or it is rather narrow and affects only one language / project and there is no objectivity, I had the idea to collect statistics for different computers and conduct some analysis. I am sure that this information will come in handy the next time you ask a project manager or technical expert: "Why do you need such a powerful computer, everything works so well ?!" Or if you are a freelance developer and one day think about whether this Mac is worth the money spent and how much, in the end, you will gain time on constant builds throughout the day.

Most people have the understanding that the more expensive Apple computers provide a more comfortable and most importantly fast fulfillment of the tasks set by the employer. But there is no understanding of what orders are involved. I found developers who, in the interests of the entire ios community, conducted a series of tests on their machines and provided results for you.


The tests examined the performance of the hackintosh with the new i7-8700K processor of the Coffee Lake generation and the iMac Pro with the flagship 18 nuclear processor Xeon W-2191B of the Skylake generation. I was always interested in comparing compilation times on hacks and native Apple machines. Given the high cost of the iMac Pro, I think many will be interested to know whether it is recommended for purchase and whether it really will bring a significant increase in the speed of project development.


At the end of the introductory part, I would like to thank Ash Furrow for the repository (his project also participates in the test) with the collected test data, which also inspired me to write this article.

Abbreviations used:

Hack / hack - hackintosh / hackintosh
SBS ( Standard Build System ) - "clean" build on a standard build system
SBS-ret - reassembly on SBS
NBS ( New Build System ) - "clean" build on a new build system
NBS- ret - reassembly on NBS

Let's pass directly to testing.


Testing

The following devices participated in the testing:

• iMac Pro ( 18 core ) Xeon W-2191B 2.3 / 4.3GHz / 64Gb
• Hackintosh i7-8700K ( 6 core ) 3.7 / 4.7GHz ( HFS + ) / 32Gb
• iMac 4K mid 2017 i7-7700K ( 4 core ) 4.2 / 4.5GHz / 16Gb
• Macbook Pro 2017 i7-7820HQ ( 4 cor e) 2.9 / 3.9GHz ( HFS + ) / 16Gb

It was decided to use only open source projects, so that after the article each developer had the opportunity to add their own results and compare with top-end hardware (so far only on Xcode 9.2). Most of these projects are currently being actively developed, and in order to be able to perform “clean” tests and compare the results in the future with the release of new iron, I pulled the projects under my account. Then I updated the frameworks / libraries on them, checked the ability to just download and (almost) start testing without unnecessary actions. Testing Instructions.

Used projects

A total of 6 projects were used ( 5 of them are available in stores):


1. Eidolon - iOS / swift 3 / cocoapods

2. Firefox - iOS / swift 3 / carthage - 3. Kickstarter - iOS / swift 3 / carthage - 4. Wikipedia - iOS / objc & swift / carthage - 5. Telegram - Mac OS / swift 4 - 6. Wire - iOS / objc / cocoapods & carthage -

Test Procedure

1. Measurements were made in Xcode 9 with a “clean” build for SBS and NBS

2. And after adding one line of code:

print (“Hello, Ash Furrow”) to application (: didFinishLaunchingWithOptions :) AppDelegate for swift
NSLog (@ “Hello, Ash Furrow "); - for objc

No additional flags were set, project settings to accelerate the build time were not made.

In addition to determining the build time of projects, the speed of the disk in AJA System Test Lite and the number of "parrots" in Geekbench 4 were measured .

It's no secret that the greatest impact on compilation time has:

• The processor, or rather its frequency, cache and to a lesser extent the number of cores
• Read / write speed of SSD drive
• RAM (frequency and volume)

For comfortable product development using Xcode 9, Slack, HipChat, Telegram, SourceTree, Chrome, Zeplin, etc., a minimum of 16 GB is recommended (more is better)

Workstation performance

The new iMac Pro SSD, of course, has the fastest

The "parrots" by and large do not have a clear correlation with the speed and time of assembly projects. Next, we will see why. But collecting the numbers and checking was still required.

Test results

The first test and immediately an unusual result. The clean build time on the hack is faster and equal to the build time on the iMac Pro on SBS and NBS, respectively.

At first the doubt crept in, how could it be that a 6-core processor overtakes / was equal to 18 nuclear ?! Control measurements were made, but everything remained unchanged (1-2 seconds of difference at the level of error).

The second test, everything seemed to fall into place. But the difference of 2/4 seconds is not so significant for such a powerful iron.

The third test, there is already a “better" situation. 5/10 second difference on SBS / NBS in favor of iMac Pro.

Wikipedia also threw a surprise. Well, here it’s very strange, the mid-2017 iMac 4K is 8 seconds faster than the iMac Pro of the end of 2017 on NBS.
And hack is 12 seconds faster!

Apparently you need control metering on another iMac Pro. If there is one more, then it will be wonderful.
UPD : found, proofs later

Telegram under Mac OS. Build time, of course, is cosmic. This is due to the fact that the project uses the generated API file (at the time of compilation of which other tasks are not performed) and the code base of the project itself is quite large. And it’s already becoming not so interesting, the hackintosh is faster again. By the way, the project is not going to NBS, it takes a lot of extra work. Therefore, this option is discarded here.

Well, the last test on Wire. Going, like Telegram only on SBS. iMac is ahead.

As can be seen from the comments on the tests, the most interesting (at least for me) was the comparison of the hack and the top model of the Apple computer. But in the first test, even the iMac 4K 2017 was not so far behind the iMac Pro - the difference was only 8/10 seconds, and overtook in the 4th one (which I repeat very strange).

According to the results of the experiments, we can conclude that the performance of hackintosh is quite comparable with the native Mac of one of the top builds costing ~ 10k $ and, accordingly, the hack can be successfully used in product development. It is likely that not the last place in such results could have been provided by the old HFS + file system. According to my personal feelings, after a month of working on MBP 17 with APFS and the subsequent reinstallation of High Sierra on HFS +, the build speed, and the laptop as a whole, became faster. This is also confirmed by the developers of kexts (drivers) for hackintosh in various forums.

conclusions

• The build time of projects depends on the speed of the disk (and the write speed has a higher priority).
• CPU frequency has a higher priority over the number of cores.
• Using the NO flag in the defaults write com.apple.dt.Xcode BuildSystemScheduleInherentlyParallelCommandsSerially -bool NO command, depending on the project and your mac, reduces build time by 9-15% (at least in Xcode version 9.3).
• NBS in swift projects gives a maximum increase of 67%.
• NBS in the objc project (Wikipedia) shows a significant increase in productivity (150%) - as if the new build system was written specifically for objc.
• On Fusion Drive, NBS is slower or approximately equal to the standard - in all likelihood some special way is used to get profit from fast SSD drives.
• On NBS in projects with swift and a mix from objc / swift, the backlight almost immediately drops (well, you know that).
• Moreover, on Macs with Fusion Drive when using NBS, the backlight does not fall

At the end of the article, the question has ripened: are the time, money and effort spent on the search, purchase of components, their subsequent assembly and configuration?

I will reveal this question in the next episode.

PS: Thanks to the guys from Badoo and Telegram for taking the time and opportunity to conduct tests on the iMac Pro. Thank you, Yuri, Eugene and Cyril for being able to pass the "light" version of the tests on their home computers.

UPD :
Currently, you can only pass tests on Xcode 9.2.
After the release of Xcode 9.3, errors arise during the assembly of some projects. In the near future, the errors will be fixed, and the test results and project repositories will be updated.
UPD 04/21/2018:
Updated repositories, you can compare your hardware.
As soon as someone passes on mac mini, mac pro or, for example, 2014 macbook pro, I add their results to the charts. More interesting are the i7 / i5 processors.

Next Episode Cost of the Hack

_{Design - Lyudmila Kotovich}