Next episode Cost hack
This article begins a cycle of several about using Hackintosh in daily work, and especially with IDE Xcode 9, and will be of more interest to developers under objc / swift languages. On the other hand, my first hack was compiled when I was not familiar with these languages ​​and may 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 working Sony laptop and a great desire to start programming under 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 long run or not.
Therefore, it was decided to build Hackintosh, which eventually allowed me to enter the world of application development for Apple devices. In the first article I want to pay attention to the build time of projects in the Xcode environment. The developers know perfectly well how much the speed has decreased and the time for building projects has increased with the release of version 9 of this IDE, especially in the swift language or a mix of objc / swift. You can speed up the compilation time, firstly, by setting various flags and scripts, and secondly, by refactoring the codebase itself.
')
But in this episode, attention will be paid to the third component of development tools, namely “hardware”.
Since there is not much information on the time of project assembly or it is quite narrow and affects only one language / project and there is no objectivity, I had an idea to collect statistics for different computers and conduct some analysis. I am sure that this information will be useful to you the next time when a project manager or techlid will ask you: “Why do you need such a powerful computer, everything works so well!”. Or if you are a freelance developer and one day you will think about whether this Mac is worth the money spent and how much time you will end up in permanent builds during the day.
Most have an understanding that Apple’s more expensive computers provide for a more comfortable and most importantly, quick fulfillment of the tasks set by the employer. But there is no understanding of what order in question. I have found developers who, in the interests of the entire ios-community, conducted a series of tests on their machines and provided results for you.
In the tests, the performance of a hackintosh with the new i7-8700K generation of the Coffee Lake generation and iMac Pro with the flagship 18th Skylake Xeon W-2191B generation nuclear processor was studied. I was always interested to compare the compilation time for hacks and native Apple machines. Given the high cost of iMac Pro, I think many will be interested to find out whether it is recommended to buy 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 already collected test data, which also inspired me to write this article.
Abbreviations used:
Hack / hack - hakintosh / hackintosh
SBS (
Standard Build System ) - “clean” build on a standard build system
SBS ret - rebuild on SBS
NBS (
New Build System ) - “clean” build on a new build system
NBS ret - rebuild on NBS
We proceed directly to the 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 his own results and compare it with top-end hardware (so far only on Xcode 9.2). Most of these projects are currently being actively developed and, in order to have the opportunity to produce “pure” tests in the future with the release of new hardware and compare the results, I pulled projects under my account. Then I updated the frameworks / libraries on them, checked the ability to just download and (almost) start testing without undue actions.
Instructions for testing.
Used projects
A total of
6 projects were used (
5 of them are available in stock):
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 taken in Xcode 9 with a “clean” build for SBS and NBS
2. And after adding one line of code:
print ("Hello, Ash Furrow") in application (: didFinishLaunchingWithOptions :) AppDelegate for
swift
NSLog (@ "Hello, Ash Furrow"); - for
objc
No additional flags were set, the project settings to speed up the build time were not made.
In addition to determining the project build time, the speed of the disk in the
AJA System Test Lite and the number of “parrots” in
Geekbench 4 were measured.
It's no secret that the greatest impact on compile time has:
- The processor, or rather its frequency, cache, and to a lesser extent, the number of cores
- SSD read / write speed
- 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)
Workstations Productivity

The new iMac Pro SSD is of course the fastest

The “parrots” by and large do not have a clear correlation with the speed and time of project assembly. Further it will be seen why. But collect the numbers and check it was still required.
Test results

The first test and immediately unusual result. The “clean” build time on a hack is faster and equal to the build time on an iMac Pro on SBS and NBS, respectively.
At first, the doubt crept in, how can it be that the 6th nuclear processor overtook / was equal to the 18th nuclear ?! Control measurements were made, but everything remained unchanged (1-2 seconds 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, the situation is already "better." 5/10 seconds difference on SBS / NBS in favor of iMac Pro.

Wikipedia also threw a surprise. Well, it's completely strange, iMac 4K of mid-2017 is faster than iMac Pro of the end of 2017 on NBS for 8 seconds.
And hack faster by as much as 12 seconds!
Apparently you need a control measurement on another iMac Pro. If there is another such, it will be great.
UPD : found proof later

Telegram under Mac OS. Assembly time, of course, space. 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 becomes not so interesting, hakintosh again faster. By the way, the project is not going to NBS, it takes a lot of unnecessary actions. Therefore, this option is discarded here.

Well, the last test for Wire. Going like Telegram only on SBS. iMac in front.
As can be seen from the comments to the tests, the greatest interest (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 is not so far behind the iMac Pro - the difference is only 8/10 seconds, and in the 4th it overtook (which I repeat is very strange).
According to the results of the experiments, it can be concluded that the hackintosh performance is quite comparable with the native Mac of one of the top assemblies worth ~ 10k $ and, accordingly, the hack can be successfully used in product development. It is likely that the old HFS + file system could have played a significant role in such results. According to my personal feelings after a month of work on the MBP 17 with APFS and then reinstalling High Sierra on HFS + assembly speed, and the work of the laptop as a whole has become faster. This is confirmed by the developers of kexts (drivers) under hackintosh in various forums.
findings
- The build time of projects depends on the speed of the disk (and the recording speed has a higher priority).
- The frequency of the processor has a higher priority over the number of cores.
- Using the NO flag in the defaults write command com.apple.dt.Xcode BuildSystemScheduleInherentlyParallelCommandsSerially -bool NO, depending on the project and your mac, reduces the 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 performance (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 SSDs.
- On NBS, in projects with a swift and a mix of objc / swift, the backlight almost immediately falls (well, you know that).
- And on the Macs with Fusion Drive when using NBS, the backlight does not fall
At the end of the article, the question is whether the time, money and effort spent on searching, purchasing a component, and their subsequent assembly and configuration are worth it.
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 test on 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, tests can only be performed on Xcode 9.2.
After the release of Xcode 9.3, errors occur when building some projects. In the near future, errors will be corrected, and the test results and project repositories
will be updated.
UPD 04/21/2018:
Repositories updated, you can compare your hardware.
As soon as someone passes on mac mini, mac pro or, for example, macbook pro 2014, I’ll add their results to the charts. More interesting processors i7 / i5.
Next episode Cost hack
Design - Lyudmila Kotovich