Епізод 0. Hack vs Mac. Xcode build time

Ця стаття починає собою цикл з декількох про використання Hackintosh в повсякденній роботі і особливо з Xcode IDE 9 і буде більше цікава розробникам під мови objc/swift. З іншого боку, мій перший хак був зібраний, коли я не був знайомий з цими мовами і може стати в нагоді навіть тим, хто не є розробником, але з тих чи інших причин хоче спробувати Mac OS. В той час у мене був досить потужний робочий ноутбук Sony і велике бажання почати програмувати під iOS. Але я не був готовий витратити певну суму грошей на Mac не знаючи прийде в нагоді він мені зрештою, чи ні.

Тому було прийнято рішення зібрати Hackintosh, який у підсумку дозволив мені увійти у світ розробки додатків під пристрої компанії Apple. У першій статті я хочу приділити увагу часу складання проектів в середовищі Xcode. Розробники прекрасно знають на скільки зменшилася швидкість і збільшився час складання проектів з виходом 9 версії цього IDE, особливо на мові swift або міксу з objc/swift. Прискорити час компіляції можна, по-перше, налаштувавши різні прапори і скрипти, по-друге, з допомогою рефакторінгу безпосередньо кодової бази.

Але в цьому епізоді буде приділено увагу третє складової інструментів розробки, а саме «залозу».

Так як інформації з часу складання проектів не так багато, або вона досить вузька і зачіпає тільки одну мову/проект і немає об’єктивності, у мене з’явилася ідея зібрати статистику під різні комп’ютери і провести деякий аналіз. Я впевнений, що ця інформація стане вам у нагоді в наступний раз, коли вам менеджер проекту або техлід запитають: «Навіщо тобі такий потужний комп’ютер, все і так чудово працює?!». Або якщо ви фріланс розробник і одного разу задумаєтеся вартий витрачених грошей цей Mac і скільки в підсумку ви виграєте часу на постійні білди протягом дня.

У більшості є розуміння, що більш дорогі комп’ютери компанії Apple забезпечують більш комфортне і найголовніше швидке виконання поставлених роботодавцем завдань. Але немає розуміння про які порядки йде мова. Мною були знайдені розробники, які в інтересах всього ios-ком’юніті провели ряд тестів на своїх машинах і надали для вас результати.

Читайте також  П'ятничний JS: гра в 0 рядків JS і CSS

У тестах була вивчена продуктивність хакінтоша з новим процесором i7-8700K покоління Coffee Lake і iMac Pro c флагманським 18 ядерним процесором Xeon W-2191B покоління Skylake. Мені завжди було цікаво порівняти час компіляції на хаках і нативних машинах Apple. Враховуючи велику вартість iMac Pro, думаю, багатьом буде цікаво дізнатися рекомендується він до купівлі чи й справді це принесе значний приріст в швидкості розробки проектів.

Наприкінці вступної частини хотілося б подякувати Ash Furrow за репозиторій (його проект так само бере участь в тесті) з уже зібраними даними тестування, який в тому числі надихнув мене на написання цієї статті.

Використані скорочення:

Хак/hack – хакінтоша/hackintosh
SBS (Standard Build System) – «чиста» збірка на стандартній системі складання
SBS-ret – повторна збірка на SBS
NBS (New Build System) – «чиста» збірка на новій системі складання
NBS-ret – повторна збірка на NBS

Перейдемо безпосередньо до тестування.

Тестування

У тестуванні брали участь наступні пристрої:

  • iMac Pro (18 core) Xeon W-2191B 2,3/4,3 GHz / 64Gb
  • Hackintosh i7-8700K (6 core) 3,7/4,7 GHz (HFS+) / 32Gb
  • iMac 4K mid 2017 i7-7700K (4 core) 4,2/4,5 GHz / 16Gb
  • Macbook Pro 2017 i7-7820HQ (4 core) 2,9/3,9 GHz (HFS+) / 16Gb

Було прийнято рішення використовувати лише open source проекти, щоб після статті у кожного розробника була можливість додати свої результати і порівняти з топовим залізом (поки тільки на Xcode 9.2). Більшість з цих проектів в даний час активно розвиваються і, щоб була можливість у подальшому з виходом нового заліза виробляти «чисті» тести і порівняти результати, я підтягнув проекти під свій аккаунт. Потім поновив на них фреймворки/бібліотеки, перевірив можливість просто завантажити і без зайвих дій (майже) почати тестування. Інструкція по тестуванню.

Використовувані проекти

Всього використовувалося 6 проектів (5 з них доступні в сторах):

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 —

Порядок проведення тестів

1. Виміри проводилися в Xcode 9 при «чистої» збірці SBS і NBS

Читайте також  Огляд безкоштовних 2D САПР

2. І після додавання одного рядка коду:
print(«Hello, Ash Furrow») у application(: didFinishLaunchingWithOptions:) AppDelegate для swift
NSLog(@«Hello, Ash Furrow»); — для objc

Ніякі додаткові прапори не виставлялися, налаштування проектів для прискорення часу складання не проводилися.

Крім визначення часу складання проектів, вимірювалася швидкість роботи диска в AJA Test System Lite і кількість «папуг» в Geekbench 4.

Ні для кого не секрет, що найбільший вплив на час компіляції надає:

  • Процесор, а точніше його частота, кеш і, меншою мірою, кількість ядер
  • Швидкість читання/запису SSD диска
  • Оперативна пам’ять (частота і обсяг)

Для комфортної продуктової розробки з використанням Xcode 9, Slack, HipChat, Telegram, SourceTree, Chrome, Zeplin та ін. рекомендується мінімум 16 Гб (краще більше)

Продуктивність робочих станцій

У нового iMac Pro SSD, звичайно, найшвидший У «папуг» за великим рахунком немає чіткої кореляції зі швидкістю і часом складання проектів. Далі буде видно чому. Але зібрати цифри і перевірити все ж потрібно.

Результати тестів

Перший тест і відразу ж незвичайний результат. Час «чистого» складання на хаці швидше і дорівнює часу складання на iMac Pro на SBS і NBS, відповідно.Спочатку закрався сумнів, як таке може бути, щоб 6 ядерний процесор обганяв/був рівним 18 ядерного?! Були проведені контрольні заміри, але все залишилося без змін (1-2 секунди різниці на рівні похибки).

Другий тест, все ніби стало на свої місця. Але різниця 2/4 секунди не настільки істотна для такого потужного заліза. Третій тест, тут вже ситуація «краще». Різниця в 5/10 секунд на SBS/NBS на користь iMac Pro. Wikipedia так само підкинула сюрприз. Ну тут зовсім дивно, iMac 4K середини 2017 року швидше iMac Pro кінця 2017 року на NBS на 8 сек.
А hack швидше на цілих 12 секунд! Мабуть потрібен контрольний замір на ще одному iMac Pro. Якщо ще один такий знайдеться, то буде чудово.
UPD: знайшов, пруфи пізніше

Telegram під Mac OS. Час збірки, звичайно, космічний. Це пов’язано з тим, що в проекті використовується згенерований файл API (на час компіляції якого не виконуються інші завдання) і кодова база самого проекту досить велика. І вже стає не так цікаво, хакінтош знову швидше. До речі, на NBS проект не збирається, потрібно багато зайвих дій. Тому цей варіант тут відкинутий. Ну і останній тест на Wire. Збирається, як і Telegram тільки на SBS. iMac попереду. Як видно з коментарів до тестів, найбільший інтерес (принаймні для мене) являло порівняння хака і топової моделі комп’ютера Apple. Але в першому тесті навіть iMac 4K 2017 не так сильно відстав від iMac Pro – різниця всього 8/10 секунд, а в 4-му обігнав (що повторюся дуже дивно).

Читайте також  Функціональне програмування на Java з Vavr

За результатами проведених експериментів можна зробити висновок, що продуктивність hackintosh цілком порівнянна з нативним Mac однією з топової складання вартістю ~10k$ і відповідно хак може бути успішно використаний в розробці продуктової. Ймовірно, що не останнє місце в таких результатах могла надати стара файлову систему HFS+. За моїми особистими відчуттями після місяця роботи на MBP 17 з APFS і повторної High Sierra на HFS+ швидкість збірки, так і робота ноутбука в цілому стала швидше. Це підтверджують і розробники kexts (драйверів) під hackintosh на різних форумах.

Висновки

 

  • Час складання проектів залежить від швидкості диска (причому швидкість запису має більший пріоритет).
  • Частота процесора має більший пріоритет над кількістю ядер.
  • Використання прапора NO в команді defaults write com.apple.dt.Xcode BuildSystemScheduleInherentlyParallelcommandsserially -bool NO в залежності від проекту і вашого mac зменшує час складання на 9-15% (принаймні в Xcode версії 9.3).
  • NBS в swift проектах дає максимальний приріст 67%.
  • NBS в objc проекті (Wikipedia) показує значний приріст в продуктивності (150%) – як ніби нову систему складання писали спеціально під objc.
  • На Fusion Drive NBS повільніше або приблизно дорівнює стандартній – по всій ймовірності, використовується якийсь особливий спосіб отримати профіт від швидких дисків SSD.
  • На NBS в проектах зі swift і міксом з objc/swift майже відразу падає підсвічування (ну ви знаєте).
  • Причому на маках з Fusion Drive при використанні NBS підсвічування не падає

В кінці статті назріло питання – чи варті витраченого часу, грошей і сил на пошук, купівлю комплектуючих, їх подальші складання і налаштування?

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *