エピソード0。ハック対Mac。 Xcodeのビルド時間

次のエピソード ハックコスト



この記事は、Hackintoshを日常業務で、特にXcode 9 IDEで使用することに関する一連のいくつかの記事から始まり、objc / swift開発者にとってより興味深いものになります。 一方、私の最初のハックは、これらの言語に精通していないときに構築されたものであり、開発者ではなく、何らかの理由でMac OSを試してみたい人にとっても役立ちます。 当時、私はかなり強力なSony作業用ラップトップを持っていて、iOSのプログラミングを開始したいという強い希望を持っていました。 しかし、私がMacに最終的に役立つかどうかを知らずに、特定の金額をMacに使う準備はできていませんでした。



したがって、Hackintoshを構築することが決定され、最終的にAppleデバイス用のアプリケーション開発の世界に入ることができました。 最初の記事では、Xcode環境でのプロジェクトのビルド時間に注意を払いたいと思います。 開発者は、このIDEのバージョン9のリリースにより、特にswiftまたはobjc / swiftからのミックスで、プロジェクトの速度がどれだけ低下し、ビルド時間が増加したかをよく認識しています。 コンパイル時間を短縮するには、まずさまざまなフラグとスクリプトを設定し、次にコードベースを直接リファクタリングします。



しかし、このエピソードでは、開発ツールの3番目のコンポーネント、つまりハードウェアに注意が払われます。



プロジェクトのビルド時間に関する情報があまりないか、非常に狭く、1つの言語/プロジェクトのみに影響し、客観性がないため、さまざまなコンピューターの統計を収集して分析を行うという考えがありました。 この情報は、次回プロジェクトマネージャーまたは技術専門家に尋ねるときに役立つと確信しています。「なぜそんなに強力なコンピューターが必要なのか、すべてがうまくいくのか！」 または、あなたがフリーランスのデベロッパーで、いつかこのMacにお金をかけるだけの価値があるかどうかを考え、最終的には1日を通して一定のビルドに時間をかけることができます。



ほとんどの人は、より高価なAppleコンピューターが雇用主によって設定されたタスクをより快適に、そして最も重要なことに迅速に遂行できることを理解しています。 しかし、どの注文が関係しているのか理解できません。 iOSコミュニティ全体の利益のために、マシンで一連のテストを実施し、結果を提供した開発者を見つけました。



テストでは、Coffee Lake世代の新しいi7-8700KプロセッサーとSkylake世代のフラッグシップ18核プロセッサーXeon W-2191Bを搭載したiMac Proを使用してhackintoshのパフォーマンスを調べました。 私はいつも、ハックとネイティブのAppleマシンでのコンパイル時間を比較することに興味がありました。 iMac Proのコストが高いことを考えると、購入が推奨されているのか、それが本当にプロジェクト開発の速度を大幅に向上させるのかを知りたいと思う人が多いと思います。



入門編の最後で、収集したテストデータのリポジトリ （プロジェクトもテストに参加している）のAsh Furrowに感謝します 。



使用される略語：



ハック/ハック -hackintosh / hackintosh

SBS （ 標準ビルドシステム ）- 標準ビルドシステムでの 「クリーン」ビルド

SBS-ret -SBSで再構築

NBS （ 新しいビルドシステム ）- 新しいビルドシステムでの 「クリーン」ビルド

NBS-ret -NBSでの再組み立て



テストに直接進みます。

テスト中

次のデバイスがテストに参加しました。

• iMac Pro（ 18コア ）Xeon W-2191B 2.3 / 4.3GHz / 64Gb
• Hackintosh i7-8700K（ 6コア ）3.7 / 4.7GHz（ HFS + ）/ 32Gb
• iMac 4K 2017年半ばi7-7700K（ 4コア ）4.2 / 4.5GHz / 16Gb
• Macbook Pro 2017 i7-7820HQ（ 4 cor e）2.9 / 3.9GHz（ HFS + ）/ 16Gb

記事の後、各開発者が独自の結果を追加し、トップエンドハードウェアと比較する機会を得られるように、オープンソースプロジェクトのみを使用することが決定されました（これまではXcode 9.2のみ）。 これらのプロジェクトのほとんどは現在活発に開発されており、「クリーン」テストを実行し、将来の結果を新しい鉄のリリースと比較できるようにするために、私はプロジェクトを自分のアカウントの下に引っ張りました。 次に、それらのフレームワーク/ライブラリを更新し、ダウンロードする機能をチェックし、（ほとんど）不要なアクションなしでテストを開始しました。 テスト手順。

使用済みプロジェクト

合計で、 6つのプロジェクトが使用されました（そのうち5つは店舗で利用可能です）。



1. Eidolon -iOS / swift 3 /ココアポッド



2. Firefox -iOS / swift 3 /カルタゴ-



3. Kickstarter -iOS / swift 3 / carthage-



4. ウィキペディア -iOS / objc＆swift / carthage-



5. テレグラム -Mac OS / swift 4-



6. ワイヤー -iOS /オブジェクト/ココアポッド＆カルタゴ-

試験手順

1. SBSおよびNBSの「クリーン」ビルドを使用して、Xcode 9で測定を行いました



2.そして、1行のコードを追加した後：

アプリケーションの印刷（「Hello、Ash Furrow 」） （：didFinishLaunchingWithOptions :) swiftの AppDelegate

NSLog（@ "Hello、Ash Furrow"）; -objcの場合



追加のフラグは設定されず、ビルド時間を短縮するプロジェクト設定は行われませんでした。



プロジェクトのビルド時間の決定に加えて、 AJA System Test Liteのディスクの速度とGeekbench 4の 「オウム」の数が測定されました。



コンパイル時間に最大の影響があることは秘密ではありません。

• プロセッサー、またはその周波数、キャッシュ、およびより少ない程度でコア数
• SSDドライブの読み取り/書き込み速度
• RAM（周波数とボリューム）

Xcode 9、Slack、HipChat、Telegram、SourceTree、Chrome、Zeplinなどを使用して製品を快適に開発するには、最低16 GBが推奨されます（多いほど良い）

ワークステーションのパフォーマンス

もちろん、新しいiMac Pro SSDは最速です

概して「オウム」は、プロジェクトを組み立てる速度や時間と明確な相関関係はありません。 次に、理由を確認します。 しかし、数字の収集と確認は依然として必要でした。

試験結果

最初のテストとすぐに異常な結果。 ハックのクリーンビルド時間は高速で、SBSとNBSのiMac Proのビルド時間にそれぞれ等しくなります。

最初は疑いが潜んでいましたが、6コアプロセッサが18核を追い抜く/どうしてそれが等しいのでしょうか？！ 制御測定が行われましたが、すべてが変更されていません（エラーレベルで1〜2秒の差）。

2番目のテストでは、すべてが適切に収まったように見えました。 しかし、2/4秒の差は、このような強力なアイアンにとってそれほど重要ではありません。

3番目のテスト、ここでは状況は「より良い」です。 iMac Proを支持するSBS / NBSの5/10秒の差。

ウィキペディアも驚きを投げました。 さて、ここでは非常に奇妙です。2017年半ばのiMac 4Kは、NBSの2017年末のiMac Proよりも8秒高速です。

また、ハッキングは12秒高速です！

別のiMac Proでコントロールメータリングが必要なようです。 もう1つあれば、それは素晴らしいでしょう。

UPD ：見つかった、後で証明

Mac OSでの電報。 ビルド時間、もちろんスペース。 これは、プロジェクトが（他のタスクが実行されないコンパイル時に）生成されたAPIファイルを使用し、プロジェクト自体のコードベースが非常に大きいためです。 そして、それはすでにそれほど面白くなくなってきており、ハッキントッシュは再び高速になりました。 ちなみに、プロジェクトはNBSに移行するのではなく、多くの追加作業が必要です。 したがって、このオプションはここでは破棄されます。

さて、Wireの最後のテスト。 行く、SBSでのみテレグラムのように。 iMacが先です。

テストに関するコメントからわかるように、（少なくとも私にとって）最も興味深いのは、Appleコンピューターのハックとトップモデルの比較でした。 しかし、最初のテストでは、iMac 4K 2017でさえiMac Proにそれほど遅れをとっていませんでした-差はわずか8/10秒で、4番目のものを追い越しました（非常に奇妙なことを繰り返します）。



実験の結果によれば、hackintoshのパフォーマンスは、トップビルドのいずれかのネイティブMacのコストが10万ドル以下であるため、このハックを製品開発で使用できると結論付けることができます。 そのような結果の最後の場所が、古いHFS +ファイルシステムによって提供された可能性はないでしょう。 私の個人的な感情によると、APFSでMBP 17を開発し、HFS +にHigh Sierraを再インストールしてから1か月後、ビルド速度とラップトップ全体が高速になりました。 これは、さまざまなフォーラムでhackintoshのkexts（ドライバー）の開発者によっても確認されています。

結論

• プロジェクトのビルド時間はディスクの速度に依存します（書き込み速度が優先されます）。
• CPU周波数は、コアの数よりも優先されます。
• デフォルトでNOフラグを使用すると、com.apple.dt.Xcode BuildSystemScheduleInherentlyParallelCommandsSerially -bool NOコマンドを書くと、プロジェクトとMacに応じて、ビルド時間が9〜15％短縮されます（少なくともXcodeバージョン9.3では）。
• 迅速なプロジェクトでのNBSの最大増加率は67％です。
• objcプロジェクト（Wikipedia）のNBSは、あたかも新しいビルドシステムがobjc専用に作成されたかのように、生産性の大幅な向上（150％）を示しています。
• Fusion Driveでは、NBSは標準より低速またはほぼ同等です。おそらく、高速SSDから利益を得るために何らかの特別な方法が使用されます。
• Swiftとobjc / swiftの組み合わせを使用したプロジェクトのNBSでは、バックライトはほとんどすぐに低下します（ご存じのとおりです）。
• さらに、NBSを使用する場合、Fusion Driveを搭載したMacでは、バックライトが落ちません

記事の終わりに、質問が熟しました。検索、コンポーネントの購入、その後のアセンブリおよび構成に費やされる時間、お金、および労力はありますか？



この質問は次のエピソードで明らかにします。

PS：iMac Proでテストを実施する時間と機会を与えてくれたBadooとTelegramのスタッフに感謝します。 ユーリ、ユージーン、シリルは、自宅のコンピューターで「ライト」バージョンのテストに合格できたことに感謝します。

UPD ：

現在、Xcode 9.2でのみテストに合格できます。

Xcode 9.3のリリース後、一部のプロジェクトのアセンブリ中にエラーが発生しますが、近い将来、エラーが修正され、テスト結果とプロジェクトリポジトリが更新されます。

UPD 04/21/2018：

リポジトリを更新し、ハードウェアを比較できます。

誰かがmac mini、mac pro、または、たとえば2014 macbook proを渡すとすぐに、その結​​果をチャートに追加します。 より興味深いのはi7 / i5プロセッサーです。



次のエピソード ハックコスト



_{デザイン-リュドミラ・コトヴィッチ}