Эта статья начинает собой цикл из нескольких об использовании Hackintosh в повседневной работе и особенно с IDE Xcode 9 и будет больше интересна разработчикам под языки objc/swift. ?С другой стороны, мой первый хак был собран, когда я не был знаком с этими языками и может пригодиться даже тем, кто не является разработчиком, но по тем или иным причинам хочет попробовать Mac OS.?В то время у меня был достаточно мощный рабочий ноутбук Sony и большое желание начать программировать под iOS. Но я не был готов потратить определенную сумму денег на Mac не зная пригодиться он мне в конечном итоге или нет.
Поэтому было принято решение собрать Hackintosh, который в итоге позволил мне войти в мир разработки приложений под устройства компании Apple. В первой статье я хочу уделить внимание времени сборки проектов в среде Xcode. Разработчики прекрасно знают на сколько уменьшилась скорость и увеличилось время сборки проектов с выходом 9 версии этого IDE, особенно на языке swift или микса из objc/swift. Ускорить время компиляции можно, во-первых, настроив различные флаги и скрипты, во-вторых, с помощью рефакторинга непосредственно кодовой базы.
Но в этом эпизоде будет уделено внимание третье составляющей инструментов разработки, а именно «железу».
Так как информации по времени сборки проектов не так много или она достаточно узкая и затрагивает только один язык/проект и нет объективности, у меня появилась идея собрать статистику под разные компьютеры и провести некоторый анализ. Я уверен, что эта информация вам пригодится в следующий раз, когда вам менеджер проекта или техлид спросят: «Зачем тебе такое мощный компьютер, все и так прекрасно работает?!». Или если вы фриланс разработчик и однажды задумаетесь стоит ли потраченных денег этот Mac и сколько в итоге вы выиграете времени на постоянные билды в течении дня.
У большинства есть понимание, что более дорогие компьютеры компании Apple обеспечивают более комфортное и самое главное быстрое выполнение поставленных работодателем задач. Но нет понимание о каких порядках идет речь.?Мной были найдены разработчики, которые в интересах всего ios-комьюнити провели ряд тестов на своих машинах и предоставили для вас результаты.?
В тестах была изучена производительность хакинтош c новым процессором 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
?Перейдем непосредственно к тестированию.?
В тестировании участвовали следующие устройства:
Было принято решение использовать только 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 / carthage —
5. Telegram — Mac OS / swift 4 —
6. Wire — iOS / objc / cocoapods —
1. Замеры производились в Xcode 9 при «чистой» сборке для SBS и NBS
2. И после добавления одной строчки кода:?
print(«Hello, Ash Furrow») в application(: didFinishLaunchingWithOptions:) AppDelegate для swift
NSLog(@«Hello, Ash Furrow»); — для objc
Никакие дополнительные флаги не выставлялись, настройки проектов для ускорения времени сборки не производились.
Кроме определения времени сборки проектов, замерялась скорость работы диска в AJA System Test Lite и количество «попугаев» в Geekbench 4.
Ни для кого не секрет, что наибольшее влияние на время компиляции оказывает:
UPD: нашелся, пруфы позже
По результатам проведенных экспериментов можно сделать вывод, что производительность hackintosh вполне сопоставима с нативным Mac одной из топовой сборки стоимостью ~10k$ и соответственно хак может быть успешно использован в продуктовой разработке. Вероятно, что не последнее место в таких результатах могла оказать старая файловая система HFS+. По моим личным ощущениям после месяца работы на MBP 17 с APFS и последующей переустановки High Sierra на HFS+ скорость сборки, да и работа ноутбука в целом стала быстрее. Это подтверждают и разработчики kexts (драйверов) под hackintosh на различных форумах.
В конце статьи назрел вопрос – стоит ли затраченные время, деньги и силы на поиск, покупку комплектующий, их последующие сборку и настройку?
Этот вопрос я раскрою в следующем эпизоде.
В настоящее время пройти тесты можно только на Xcode 9.2.
После выхода Xcode 9.3 при сборке некоторых проектов возникают ошибки. В ближайшее время ошибки будут исправлены, а результаты тестов и репозитории с проектами обновлены.
Поэтому было принято решение собрать Hackintosh, который в итоге позволил мне войти в мир разработки приложений под устройства компании Apple. В первой статье я хочу уделить внимание времени сборки проектов в среде Xcode. Разработчики прекрасно знают на сколько уменьшилась скорость и увеличилось время сборки проектов с выходом 9 версии этого IDE, особенно на языке swift или микса из objc/swift. Ускорить время компиляции можно, во-первых, настроив различные флаги и скрипты, во-вторых, с помощью рефакторинга непосредственно кодовой базы.
Но в этом эпизоде будет уделено внимание третье составляющей инструментов разработки, а именно «железу».
Так как информации по времени сборки проектов не так много или она достаточно узкая и затрагивает только один язык/проект и нет объективности, у меня появилась идея собрать статистику под разные компьютеры и провести некоторый анализ. Я уверен, что эта информация вам пригодится в следующий раз, когда вам менеджер проекта или техлид спросят: «Зачем тебе такое мощный компьютер, все и так прекрасно работает?!». Или если вы фриланс разработчик и однажды задумаетесь стоит ли потраченных денег этот Mac и сколько в итоге вы выиграете времени на постоянные билды в течении дня.
У большинства есть понимание, что более дорогие компьютеры компании Apple обеспечивают более комфортное и самое главное быстрое выполнение поставленных работодателем задач. Но нет понимание о каких порядках идет речь.?Мной были найдены разработчики, которые в интересах всего ios-комьюнити провели ряд тестов на своих машинах и предоставили для вас результаты.?
В тестах была изучена производительность хакинтош c новым процессором 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,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 core) 2,9/3,9GHz (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 / carthage —
5. Telegram — Mac OS / swift 4 —
6. Wire — iOS / objc / cocoapods —
Порядок проведения тестов
1. Замеры производились в Xcode 9 при «чистой» сборке для SBS и NBS
2. И после добавления одной строчки кода:?
print(«Hello, Ash Furrow») в application(: didFinishLaunchingWithOptions:) AppDelegate для swift
NSLog(@«Hello, Ash Furrow»); — для objc
Никакие дополнительные флаги не выставлялись, настройки проектов для ускорения времени сборки не производились.
Кроме определения времени сборки проектов, замерялась скорость работы диска в AJA System Test 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 сек.Видимо нужен контрольный замер на еще одном iMac Pro. Если еще один такой найдется, то будет замечательно.
А hack быстрее на целых 12 секунд!
UPD: нашелся, пруфы позже
Telegram под Mac OS. Время сборки, конечно, космическое. Это связано с тем, что в проекте используется сгенерированный файл API (на время компиляции которого не выполняются другие задачи) и кодовая база самого проекта достаточно большая. И уже становится не так интересно, хакинтош опять быстрее. Кстати, на NBS проект не собирается, требуется много лишних действий. Поэтому этот вариант здесь отброшен.
Ну и последний тест на Wire. Собирается, как и Telegram только на SBS. iMac впереди.Как видно из комментариев к тестам, наибольший интерес (по крайней мере для меня) представляло сравнение хака и топовой модели компьютера Apple. Но в первом тесте даже iMac 4K 2017 не так сильно отстал от iMac Pro – разница всего 8/10 секунд, а в 4-м обогнал (что повторюсь очень странно).
По результатам проведенных экспериментов можно сделать вывод, что производительность 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 подсветка не падает
В конце статьи назрел вопрос – стоит ли затраченные время, деньги и силы на поиск, покупку комплектующий, их последующие сборку и настройку?
Этот вопрос я раскрою в следующем эпизоде.
P.S.: Спасибо ребятам из Badoo и Telegram, за то что нашли время и возможность для проведения тестов на iMac Pro. Спасибо, Юрию, Евгению и Кириллу за то, что смогли пройти «лайт» версию тестов на своих домашних компьютерах.UPD:
В настоящее время пройти тесты можно только на Xcode 9.2.
После выхода Xcode 9.3 при сборке некоторых проектов возникают ошибки. В ближайшее время ошибки будут исправлены, а результаты тестов и репозитории с проектами обновлены.
Комментарии (21)
GDXRepo
10.04.2018 17:58Ох елки, дико полезное лично для меня сравнение. Прям перестал глядеть голодными глазами на новый iMac. Странно, что в компиляции больше сыграла роль частота, а не многоядерность, как при том же рендере, например, я думал, будет наоборот. SSD по скоростям просто бешеный на новом Pro, но одно это (+моник и «у меня больше ядер») не должно создавать многократную разницу в цене. По статье остался вопрос, какое точно железо присутствовало в Хаке? Можете перечислить все (вообще все, без исключения) комплектующие, чтобы конфигурация оказалась рабочей, а многострадальная Sierra запускалась и работала без вопросов? А то меня от Хаков всегда останавливал только сложный процесс подбора комплекта. Сам сижу на MacBook Pro 2015, и, похоже, нечего даже дергаться, особо быстрее на новых компах не станет.
MrGoliaf Автор
10.04.2018 18:44Материнская плата: Gigabyte Aorus Z370 Gaming 5
Процессор: i7-8700K
Видеокарты: CG-Alpine и RX580 Nitro+
Оперативная память: Crucial DDR4-2133 32 Gb
SSD: Samsung 950 pro 512Gb
Мониторы: LG UltraFine 5K, Asus VW248TLB
Во второй статье будет подробный гайд по сборке и настройке под это железо.
kwolfy
10.04.2018 20:12Не меньше интересует как ведет себя хакинтош в плане стабильности, насколько геморно обновляться? Лично я пользуюсь маком не столько из за хкода, сколько из за стабильности и удобства разработки
MrGoliaf Автор
10.04.2018 20:52Все достаточно стабильно.
Неожиданных перезагрузок нет.
Как на обычном маке — скачиваете обновление системы, устанавливаете и перезагружаетесь. Все.
В редких случаях перед обновлением требуется скачать и заменить свежие kext’ы и уже совсем в редких обновить настройки config.plistasmrnv777
11.04.2018 00:00Чтобы всё совсем нативно заработало, придётся немного поплясать. У меня похожий конфиг как в посте, только i7-7700K и Z1**, и для нормальной работы таких вещей, как сон, нужны были небольшие ритуальные пляски по гайду.
Ну и самое свежее железо лучше не брать, я год назад с этим процессором намучился.
asmrnv777
10.04.2018 23:58Главное карточки Nvidia не брать, и собирать из относительно дефолтного для маков железа.
Про карточки говорю не просто так: оф. дрова как бы есть и регулярно обновляются, но они настолько ужасны, что лучше бы их не было — в каждом новом релизе либо добавляются новые лаги/баги, либо возрождаются старые.
Про AMD в последнее время особо ничего плохого не слышал, думаю уже на RX580 перелезать.
// Дисклеймер: вышесказанное относится только к макоси, я не знаю, насколько хороши дрова этих вендоров на других ОС.
MMik
Насколько изменится ваше мнение о материале, если вместо
будет написано ?Мы — программисты. Мы ценим чужой труд, чужой код, уважаем и соблюдаем лицензии на чужой код. Мы зарабатываем достаточно, чтобы купить себе и софт и железо для нашей работы.
poxvuibr
Кстати, интересно, можно ли приобрести OSX отдельно от мака? Если нельзя, то позволяет ли законодательство использовать OSX, приобретённую с маком для сборки хакинтоша?
MMik
Уже было: в апреле 2008 года компания Psystar начала производить и продавать персональные компьютеры «OpenMac» (позже — «Open Computers»), и поставляла их с установленной на диск патченной Mac OS X под их хакинтош, в комплект докладывала нераспакованную, купленную отдельно, коробочную версию Mac OS X. Apple и Psystar обмениваются исками и аппеляциями, в итоге Psystar проигрывает по всем фронтам и сворачивает деятельность.
Хорошо описано, например, в книге Licensing Intellectual Property: Law and Applications, by Robert W. Gomulkiewicz (ссылка).
poxvuibr
Я думаю, что продавать их вот так это юридически одно, а купить макос и поставить самому это юридически другое.
MMik
Вроде как уже не продаётся:
poxvuibr
Это с одной стороны. Должна быть бирка эппл. Но с другой стороны, вопрос, какую силу это всё имеет с точки зрения законодательства РФ. Тут интересно юриста послушать.
Расскажу короткую байку. Я когда-то присутствовал на конференции по условно патентоведению и там был юрист, который уверенно говорил, что согласно нашему законодательству, можно спокойно ставить пиратскую копию Windows домой и никто тебе ничего не может сказать, потому что ты для личного использования это делаешь.
Мне до сих пор кажется, что это какая-то глупость, но говорил юрист, с юридической практикой и достаточно молодой. И я иногда думаю, а вдруг правда оно тогда так и было. В конце концов даже сейчас, сколько бы тебе не писали в лицензионном соглашении, что ты обязан отдать первенца богу-крокодилу — его можно не отдавать.
arozhankov
Мне кажется дело именно в опыте. Опытный юрист бы добавил «но я не рекомендую так делать, т.к. решение суда заранее не известно.»
Зачем испытывать нашу судебную систему, терять время и, возможно, деньги.
markoni
Вы, наверное, представляете какую-то группу «мы — программисты»? В противном случае было бы уместнее говорить от первого лица. Тогда все остальные «мы программисты» воспримут вашу точку зрения адекватно — именно как вашу точку зрения. А рассказывать в детсадовском стиле, что «мы моем руки перед едой», и «Волга впадает в Каспийское море», право, не стоит.