Чому телефони Android мають більше ядер, ніж комп'ютери?

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

З іншого боку, на мобільних телефонах, здається, часто зустрічаються квадрати, шестикутники та октакори. Чому? Які завдання можуть їх виконувати?

Я розумію, що big.LITTLE може бути частиною відповіді. Тобто, головна перевага такої кількості ядер - це не можливість використовувати їх усі одночасно, а скоріше використання сердечника з енергоспоживанням, відповідним поточному навантаженню. Однак, наприклад, Snapdragon 625 має вісім ядер Cortex-A53, що, здається, не є справою для великих.LITTLE.

Можливо, архітектура ARM має нижчу точку оптимальної продуктивності на ват. Тобто, налаштування єдиного ядра для оптимальної продуктивності на ватт призводить до зниження продуктивності на ARM, ніж в Intel. Отже, для досягнення продуктивності використовується більше ядер. Це лише гіпотеза.

Але навіть у цьому випадку я не бачу, який навантаження може ефективно використовувати, скажімо, вісім ядер на мобільному телефоні. На ноутбуках я можу уявити собі декілька на кшталт повної (неінкрементальної) компіляції проекту. Але на телефони?

• Ігри можуть спричинити ефективність роботи, але зазвичай вони вимагають продуктивності GPU, а не процесора, чи не так?
• Теоретично, декілька ядер можуть пришвидшити компіляцію AOT Android Lollipop / Marshmallow AOT під час встановлення або при модернізації (тобто фаза "Оптимізація додатків 3/121"). Я, однак, не впевнений, чи може це використовувати кілька ядер. Наскільки я пам’ятаю код, за один раз збирається лише одна програма, але, можливо, є якийсь паралелізм у самому процесі компіляції.
• Також Android 7+ може використовувати кілька ядер при компілюванні. Але оскільки, як повідомляється, він збирається під час роботи в режимі очікування та зарядки, вигода здається досить мінімальною. Принаймні, коли хтось заряджає телефон протягом ночі - мені дуже не байдуже, чи потрібно 30 хвилин або дві години за такого сценарію.

Як ви вже зазначали, стратегія комбінування big.LITTLE (технічно, HMP , гетерогенні кластери з багатообробною обробкою ) є основною причиною для багатьох (і іноді переважно багатьох) ядер. Мобільний пристрій часто працює в декількох сценаріях, включаючи великі та легкі навантаження.

Приклад надзвичайного споживчого класу - Helio X20 MediaTek, який має 2 ядра A72, орієнтовані на продуктивність, 4 врівноважені ядра A53, плюс 4 енергоефективні ядра A35. Це дуже гнучко в різних випадках використання. Однак я думаю, що 8 ядер 2 кластерів зазвичай достатньо.

Також є ще один настільний приклад, серія Snapdragon 800 Qualcomm (S 800, S 801 і S 805). У кожному SoC є лише 4 ядра однієї мікроархітектури, причому 2 тактовані вище і 2 тактовані нижче. Qualcomm зробив ці SoC, тому що вони були дуже впевнені у власній мікроархітектурі (Krait 400 та Krait 450).

Для ігор, навіть якщо вони, здавалося б, вимагають продуктивності графічного процесора, а не процесора, вони все ще накладають велике навантаження на процесор. Графічний процесор не може працювати один, без чогось іншого, надаючи їм дані, що підлягають обробці, і це одна з головних робіт, яку CPU виконує під час гри. У більшості ігрових випадків GPU робить лише графіку, тоді як усі інші завдання, такі як завантаження даних, ресурсів та активів, а також обчислення ігрової механіки, як система, середовище та фізика, виконуються процесором. Ви не будете спостерігати більш високу частоту кадрів, якщо оновите GPU, дотримуючись низького рівня процесора.

Другою причиною є те, як Android використовує ресурси процесора . Android в значній мірі створює власне середовище додатків. Він не використовує нічого, окрім кодів (та API) від Java, але має власну віртуальну машину на ім'я Dalvik, яку згодом замінили на ART (API Level 21). APK мають свої виконувані коди у "нейтральному" форматі, як і .classфайли на Java. Перед тим, як їх запустити, коди ще раз збираються в початкові інструкції машини ^[1] . Процес компіляції є багатопотоковим і може використовувати декілька ядер для підвищення продуктивності.
І коли програма працює, існує кілька інших процесів і механіки (наприклад, збирач сміття), які працюють поруч із програмою або паралельно їй. Більше ядер може дозволяти підтримуючим процесам працювати більш ефективно, як і основний додаток.
_{1. Якщо ви використовуєте ідентифікатор типу файлу, ви побачите, що "оптимізовані" файли dex у форматі ELF, тоді як "нейтральні" файли dex просто у власному форматі.}

Іншою меншою причиною є те, що ядра ARM не можуть працювати так швидко, як чіп Intel x86 . Мікроархітектура Intel x86 може бути датована 1976 р., Коли почав проектуватися чіп Intel 8086 , а це означає, що x86 розвивався протягом тривалого часу. Єдине сучасне високоякісне ядро ​​ARM Cortex-A73 настільки ж потужне, як ядро ​​Intel Clarkdale, беручи за приклад Core i5-660 (GeekBench, одноядерний). Це тому, що x86 є мікроархітектурою CISC, тоді як ARM - це RISCмікроархітектура. Ви, звичайно, не хочете, щоб телефон затягнувся лише з двома або настільки активними додатками. Більше ядер допоможе зняти тиск. Ось чому двоядерні SoC є досить популярними лише на смарт-годинниках. Кому потрібна робота на смарт-годиннику?

Цікаво, що більше ядер призведе до меншої потужності, ніж одне ядро ​​при однаковому навантаженні . Взаємозв'язок між частотою процесора та енергоспоживанням є більш ніж лінійним, тому вдвічі більше частоти завжди буде вимагати більше, ніж удвічі, або навіть у 3 рази або в 4 рази більше енергії, забезпечуючи при цьому меншу вдвічі більшу продуктивність (через інші обмеження ресурсів, такі як кеш ). Так 4 ядра можуть легко перемогти одне ядро ​​при однаковому навантаженні, забезпечуючи кращі показники роботи і одночасно вимагаючи меншої потужності.

Подальше читання:

• Чому 8 і 10 процесорних ядер у смартфонах - хороша ідея - урок з кухні
• Чому в деяких телефонах є два чотирьохядерні процесори, а в деяких схожий октановий ядро. Що з точки зору продуктивності краще?

Причина настільки ж проста, як і складна.

Коротка відповідь - "тому, що ринок мобільних телефонів ніколи не був і не керується Intel".

Довга відповідь є занадто довгим для відновлення тут, але основна концепція полягає в тому, що Intel протягом багатьох років домінує на ринку ПК всіма можливими способами, до того, щоб платити і псувати (і за це штрафувати), щоб його процесори були перший і єдиний вибір для виробників ПК.

Тотальний контроль над ринком дозволив Intel завищувати ціни на процесор, штучно вирішуючи, які функції та скільки процесорної потужності бажали б користувачі, і якщо проаналізувати трохи історії Intel, ви помітите, що її основна сила в основному полягає в збільшення частоти процесорів, тому в основному він ніколи не намагався зробити щось дійсно розумне або інноваційне; і це йому не потрібно, тому що він може просто сказати людям "вам не потрібно більше ядер, але у мене є цей соковитий новий процесор, який працює на 100 МГц швидше". У той же час він міг продавати багатоядерні процесори на ринку серверів за абсурдно високими цінами _{(адже сервери завжди потрібнітонн паралельної потужності, до того, що існує поточна тенденція намагатися реалізувати сервери, які використовують ... здогадуйтесь, що? Сотня ваших дешевих телефонних процесорів працює паралельно)}

Це, у свою чергу, відбилося на спільноті розробників, яка ніколи не наздоганяла важливості паралельного програмування, так що багато хто, якщо не більшість із них ніколи не заважав використовувати більше ніж одну нитку в той час, або виразити це не технічним способом, маючи своє програмне забезпечення робити одночасно більше ніж одне завдання. Що, до речі, має сенс, коли 99% клієнтів мають максимум два ядра. На жаль, це призвело до легенди про те, що паралельні алгоритми реально важко реалізувати і стосуються лише невеликого набору проблем.

Натомість, нарешті, ринок мобільних телефонів ніколи не бачив успіху Intel; навпаки, насправді, як це відбувається в більшості випадків, коли Intel намагається зробити щось інше, ніж звичайна архітектура X86. Отже, не вистачає впливу та контролю ринку, інші виробники процесорів пішли у напрямку, що було нормальністю для віків поза ринком ПК: паралельні обчислення.

Тривають два фактори: один дуже практичний, а другий історичний.

Практична причина - використання змішаної архітектури в телефонах. Споживання енергії є критично важливим для телефонів, і телефони проводять багато часу в режимах, де вони вимагають дуже низької продуктивності. Має сенс оптимізувати деякі сердечники для мінімального енергоспоживання, коли потрібна невелика продуктивність, а деякі ядра оптимізовані для забезпечення максимальної продуктивності, коли це потрібно.

Інша причина багато в чому історична. До 2005 року або близько того, настільні процесори були єдиними ядрами. Підвищення продуктивності настільного процесора полягало майже в створенні ядра, яке може виконувати якомога більше інструкцій в секунду. Навіть сьогодні стільки програмного забезпечення для настільних ПК не може повною мірою скористатись декількома ядрами, що багато хто віддасть перевагу процесору з 4 ядрами над 8-ядерним процесором з ядрами на 20% повільніше.

Для отримання якомога більшої продуктивності з одного ядра потрібно величезна кількість нерухомості процесора. Це нерухомість, яку в іншому випадку можна використовувати для забезпечення більшої кількості ядер. Ось чому новітні процесори Kaby Lake від Intel мають максимум 4 ядра, і люди купують їх, оскільки кожне ядро ​​швидше, ніж ядра попередника. Для багатьох вони є оновленням навіть від центральних процесорів з більшою кількістю ядер.

З часом очікуйте побачити набагато більше програмного забезпечення для настільних ПК, повністю оптимізованого для підтримки більшої кількості ядер. Як це станеться, технічні компроміси почнуть віддавати перевагу більшій кількості ядер над швидшими ядрами на настільних ПК. Хоча ядра майже напевно все-таки стануть швидшими, ви почнете бачити людей, які віддають перевагу 8-ядерному процесору над 4-ядерним процесором, навіть якщо кожне ядро ​​на 20% повільніше. Дизайнери чіпів будуть стежити за ринком.

Для телефону важливо, щоб він міг забезпечити обчислювальну потужність у короткий час (потрібні певні програми, щоб бути швидкими), але також уникати перегріву (відведення тепла набагато складніше для телефонів, ніж для ноутбуків чи ПК). Щоб досягти цього, архітектори проектують телефони для використання єдиного ядра, коли навантаження легке, і надають додаткові ядра для підвищення продуктивності, коли це потрібно. Якби телефони мали використовувати менші великі сердечники, перегрів стане проблемою навіть тоді, коли навантаження досить невелика.

Джерело: Курс комп'ютерної архітектури випускника.

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

По-друге, на вашому телефоні відбувається багато іншого: автоматичні оновлення, завантаження оголошень, антивірусне програмне забезпечення, управління GSM-модулем і т. Д. На ноутбуці всі ці завдання ледь не зайняли б одне ядро ​​зайнятим, але ядра ARM - це набагато менш потужні, тому, можливо, вам захочеться мати принаймні пару присвячених фоновим завданням, якщо ви хочете чуйну систему.

Нарешті, є маркетинг. Не багато користувачів можуть оцінити, чи отримали б вони користь від 8 ядер, але 8-ядерний смартфон, безумовно, звучить дорожче, ніж 2 або 4-ядерний.

Поки що відповіді пояснюють деякі аспекти проблеми, що призводять до цієї величезної кількості ядер процесора на телефонах Android. Прочитайте ще раз; Телефони Android. IPhone встиг прижитися лише до декількох ядер на віки і все ще працює набагато плавніше, ніж будь-який флагман Android.

Дизайнери Android зробили величезну проблему, вирішивши вибрати програмування Java, і як наслідок, JVM як час виконання програм. Java, завдяки своїм принципам дизайну, вирішує проблему необхідності компілювати та створювати код для кожної архітектури процесора, перш ніж можна було запустити на ньому жертвуючи продуктивністю. Java представляє важку і об'ємну віртуальну машину, яку зазвичай називають JVM. JVM фактично імітує процесор на рівні програмного забезпечення, щоб уникнути необхідності компілювати код окремо для кожного пристрою. Подумайте про JVM як віртуальний процесор, який має однакові властивості незалежно від пристрою, на якому він працює, тому код потрібно скомпілювати лише один раз для JVM і потім можна запустити на кожному пристрої. Це дозволяє виробникам кидати будь-яке обладнання, яке вони хочуть, перш ніж потурбуватися про сумісність програми.

Сам JVM - це лише специфікація, і люди вільні розвивати свій власний JVM до тих пір, поки він дотримується цієї специфікації. Оригінальний андроїд JVM називався Dalvik. Зараз Google замінив це на ART.

Тепер у чому проблема з JVM? Це важке програмне забезпечення, яке споживає чимало обчислювальних ресурсів. Додайте до цього деякі інші властивості мови Java, такі як збирання сміття та споживання ресурсів JVM, просто стає занадто великим для пристрою зі скромною апаратною потужністю. Кожен додаток та системний сервіс, відкриті на вашому пристрої, є самим примірником ART JVM, і вже на даний момент ви могли зробити висновок, що для керування ними все потрібне дійсно здатне обладнання. Все стане ще гірше, коли виникне необхідність малювати інтерфейси користувача.

Кожна програма працює на декількох потоках. Кожне ядро ​​процесора може одночасно запускати лише один потік. Кожен додаток має один основний потік, на якому він робить речі, пов'язані з користувальницьким інтерфейсом. На додаток може бути набагато більше потоків для доступу до файлів, мережі тощо. Зазвичай відкрито більше програм (і системних служб), ніж ядер CPU, і як результат, зазвичай є набагато більше потоків, ніж ядер CPU. Тому кожне ядро ​​має постійно перемикатися між обробкою різних потоків, роблячи трохи кожної з них і переходити до наступної. Ця комутація займає багато часу для процесора, і якщо додатки є по суті JVM, це завдання стає ще більш вичерпним.

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

З іншого боку, додаток для iOS компілюється у власний машинний код і, отже, не потребує віртуалізації. Використовувана мова та операційна система також є більш ефективними, а отже, дозволяють цим пристроям залишатися гладкими, не потребуючи якихось наборів із зайвим набором.

Поновлюючи все вище, я можу сказати, що випадки використання ПК та телефону є зовсім різними. ПК найчастіше використовується в одній або декількох програмах (звичайно, браузер із купою вкладок потребує багатьох процесорних ядер, може відставати навіть на верхньому i-3), телефони, які використовуються для багатозадачності. Принаймні мережне підключення, малюнок інтерфейсу користувача, активація системи, повідомлення. Якщо ви відкриєте диспетчер завдань на ПК, теж багато процесів, але вони використовують менше ніж кілька відсотків процесорної потужності навіть у старому дуоті Core 2. 4 ядра досить дешеві (MTK 65x2 коштував 1 $ на старті для OEM). Це також РИЗИК проти CISC, коли останній не вистачає продуктивності на одне ядро. Енергоефективні! = Потужні, як ми бачимо тут . Багатоядерний ідеально підходить для мобільних пристроїв, оскільки немає серйозного важкого навантаження на один протектор і багатоцільового досвіду (але ми можемо бачити, що iPhone має потребу в меншій кількості ядер і оперативної пам’яті завдяки хорошому програмному забезпеченнюяк у цьому відео чи інших )

Я думаю, що одним з головних рушійних факторів, що перевищує 4 або 8 (для великих: мало конфігурацій), є лише маркетинг на даний момент.

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

Цього не відбувається, оскільки оперативна пам’ять дуже дорога (особливо в кризовій ситуації з оперативною пам’яттю 2017/2018). Маркетинг хоче високих цифр, але контроль хоче знизити ціни на компоненти. Якщо ви бачите баланс, менший за 1 гігабайт оперативної пам’яті на ядро, то ви бачите невдалий компроміс.