Цікаво, які вузькі місця створює проект AOSP? Ден ділиться своїми висновками, які можуть здивувати читачів щодо того, що є причиною вузьких місць, а що ні.
Оновлення 19 квітня о 12:00 за київським часом: Уточнений час збирання є часом збирання ccache.Оновлення 20 квітня 9:17 ранку CT: Збірка 3 точно не була RAID 1. Виправив цю помилку.
У 2012 році я почав створювати ядра — і покладався на мій вірний Core 2 Quad Q9550 для його створення. Якщо це не заслуговує жаху, то той факт, що я зробив це у віртуальній машині всередині Windows, ймовірно, забезпечить це для більшості людей, які створюють Android із початкового коду.
Віртуалізоване середовище Ubuntu працює не так добре, як рідне середовище, і, ох, як боляче це стало очевидним, коли на створення ядра знадобилося більше 2 годин. Оскільки наступного року я хотів почати розробляти Android із початкового коду, я знав, що моє поточне обладнання цього не зробить скоротити це - і так почалася довга і все ще триваюча подорож, щоб знайти спосіб зменшити те, що постійно зростає час.
За минулі роки мені пощастило тестувати на багатьох форм-факторах і платформах. Це важливо, оскільки конфігурації збірки не є однозначною ситуацією для Android. Розробнику програми може не знадобитися така сама конфігурація, як розробнику ігор. І комусь, хто створює лише ядра, може не знадобитися витрачати стільки, скільки комусь, кому потрібно створити повну ПЗУ Android із джерела за дуже короткий проміжок часу. А як щодо вибору ОС -- що можна (а що ні) використовувати прямо зараз? Я також сподіваюся вивчити це більше, особливо з Windows і Canonical працюють над впровадженням повноцінного Bash у Windows 10.
Щоб правильно розпочати цю серію, ми маємо знайти найбільші потенційні вузькі місця у створенні проектів AOSP із джерела. Ми не часто ходимо в магазин за ПК або оновленнями, не знаючи, куди подіти гроші. Отже, базуючись на 3 роках досліджень і кількісно виміряних результатах, я готовий поділитися тим, що знайшов. Тепер очікувана відмова від відповідальності: ці висновки ґрунтуються на особистому досвіді та не можуть врахувати всі комбінації. Ті з вас, хто має власну конфігурацію збірки, вимкніть звук і повідомте нам, як справи з вашими збірками! Часи також стосуються збірок із увімкненим і заповненим кеш-пам’яттю — зазвичай подвоюється, коли кеш-пам’ять ще не заповнено.
Дисковий ввід/вивід: Я маю відзначити Тома Маршалла з Cyanogen – також a член команди Кан - за те, що вказали мене в цьому напрямку минулого року. Я, чесно кажучи, не повірив йому, коли він сказав мені, що це буде в вузьке місце над ЦП. Але за останні 6 місяців я зміг підтвердити це даними, які можна визначити. У процесорах вищого класу (таких як більшість настільних моделей Intel Core i7) це головне вузьке місце, з яким зіткнеться ваша система.
Давайте візьмемо 4 конфігурації збірки, на яких я це перевірив. Я виділю тут процесор,
- Першою збіркою, моїм «неоновленим» ПК, був Intel i7-4790K з 32 ГБ оперативної пам’яті DDR3-2400, Samsung 840 Evo 250 ГБ для мого основного накопичувача та старіший Micron P400E 100 ГБ.
- Build 2, яка була оновленою версією Build 1. Тепер оснащений Intel i7-5960X, розігнаним до 4,0 ГГц, 32 ГБ оперативної пам’яті DDR4-3200, SSD Samsung SM951 512 ГБ AHCI m.2 разом із двома попередніми SSD. Повні характеристики збірки для цього знаходяться на PCPartPicker.
- Збірка 3, нещодавня користувальницька збірка, містила Intel i7-5820K, розігнаний до 4,2 ГГц, 16 ГБ DDR4-2400 і 2 Samsung 840 EVO 120 ГБ у конфігурації RAID0 (смугаста).
- Збірка 4, нещодавня збірка сервера, що включає Intel Xeon E3-1270 v5 на нормальній швидкості, 32 ГБ DDR4-2133, Samsung 950 Pro 512 ГБ NVMe m.2 разом із 4 корпоративними SSD-накопичувачами SATA Samsung у масиві RAID5.
Якби ви просто подивилися на них, який би, на вашу думку, досяг найменшого часу створення? Як щодо другого? На мій шок, це була не друга конфігурація, яка потребувала найменшого часу для створення, а третя конфігурація, at трохи менше 14 хвилин для створення CyanogenMod 13.0. Тож, безперечно, домінуючий процесор займе друге місце, правильно? Знову помилка. Збірка 4, яку я щойно закінчив тестувати, зайняла трохи більше 25 хвилин! Ось тільки моя поточна збірка на 2 хвилини повільніша за систему з половиною ядер і потоків, але з масивом SSD із 3 SSD, тоді як мої SSD були автономними. Також відомо, що SM951 має проблеми з троттлінгом, якщо він стає занадто гарячим, що може бути дуже реальним фактором у цьому випадку. Перша і найповільніша збірка зайняла близько 30 хвилин, єдиний раз, коли я збирав CM 13.0; Я чув про подібні конфігурації збірки, які роблять це в 27.
SSD також раніше було важко дістати, тому на цю тему було дуже мало дискусій. Однак за останній рік ціни різко впали як у роздрібній торгівлі, так і на ринках секонд-хенду. Оскільки твердотільні накопичувачі на 120 ГБ зараз коштують менше 50 доларів, це не є перешкодою, як колись, додати його до системи. Традиційні жорсткі диски також виконають цю роботу, але користувачі, швидше за все, досягнуть цього вузького місця раніше за інших, якщо не використовують SSD.
ЦП: Коли я згадую вище, що головним вузьким місцем є дисковий ввід-вивід, це дійсно залежить від припущення, яке не завжди так: кожна з цих збірок, які я використовував, мала процесор Intel Core i7. Але, як я виявив із сервером Xeon, диск не відстає, але потім підтримує високу завантаженість усіх 8 потоків ЦП під час найважчих процесів збірки. І як би я не намагався, без масиву RAID, який ми знайшли вище, я не вважаю, що мій Haswell-E навіть майже повністю використовується протягом більшої частини процесу збирання. Тож якщо ви шукаєте найкращий варіант для своїх витрат, розгляньте Intel i7-5820K.
Правда, це X99, тому материнська плата може бути дорожчою, ніж материнська плата Z97; але ми також все ще в першому році циклу X99. Очікується, що ціни на Broadwell-E залишаться такими ж, як і на Haswell-E після випуску, тобто це означає ви повинні мати можливість купити в сегменті ентузіастів майже за таку ж ціну, як i7-4790K або i7-6700K.
У Intel на даний момент немає особливих причин виходити за межі 5820K, оскільки ви можете отримати вражаючий час збірки з ним. Здебільшого, чим більша кількість ядер/потоків нижче, а також швидкість процесора, забезпечать вам швидший час створення. Минулого року i7-4770R у GIGABYTE Brix складав у середньому 42 хвилини. Хоча він не був найшвидшим, він задовольнив мої потреби та дозволив мені мати спеціальну конфігурацію з низьким енергоспоживанням. Ви побачите те ж саме з процесорами AMD APU – хоча зараз вони можуть не працювати так добре, як їхні аналоги Intel, вони легко виконають роботу та зазвичай за нижчою ціною, ніж покупка Intel. Це ситуація, на яку я уважно стежу, тому що якщо чутки правдиві, то APU на базі Zen можуть суттєво закрити цю прогалину.
Для тих із вас, хто хоче усунути ці вузькі місця, є результат, який більше стосується домашніх користувачів, ніж офісних. Загальна продуктивність системи збільшиться, якщо усунути ці вузькі місця. Особливо геймери побачать, що оновлення для усунення цих вузьких місць майже у всіх випадках також підвищить продуктивність гри. Хоча він, можливо, не виграв найшвидший час збірки, ця друга збірка принесла несподіваний сюрприз – час завантаження 30 секунд на Just Cause 3 коли багато інших скаржилися на час завантаження в хвилинах. Зрештою, цей час створення дійсно високий і може бути надмірним для багатьох... але принаймні зараз аргумент про те, що більше ядер означатиме швидші збірки, нарешті спростовано.
Оскільки це лише початок, ми сподіваємося, що читачі підключаться та поділяться своїм досвідом створення різних конфігурацій. Ви як читач хочете бачити більше дискусій на такі теми? Вимкніть звук у коментарях нижче!