Raspbian переходить в 64-бітний режим

На цій сторінці в офіційному оголошенні RPi3 зазначено:

Вам знадобиться недавнє зображення NOOBS або Raspbian на нашій сторінці завантажень. При запуску ми використовуємо ту саму 32-розрядну програму Raspbian, яку ми використовуємо на інших пристроях Raspberry Pi; протягом наступних кількох місяців ми будемо досліджувати, чи є цінність для переходу в 64-бітний режим.

Моє запитання, враховуючи, що процесор має 64 біти, чи не очевидно, що запуск ОС у 64 бітах буде краще всіляко? Що я пропускаю?

враховуючи, що процесор має 64 біти, чи не очевидно, що запуск ОС у 64 бітах буде краще всіляко?

Ні, насправді, це не так. Деяким чином, запуск 64-бітної операційної системи може погіршити продуктивність Raspberry Pi.

Переваги 64 біт :

Двома основними перевагами використання 64-бітового процесора / операційної системи є те, що пристрій може обробляти більше 4 ГБ оперативної пам’яті та 2^32в основному обробляти цілі числа, більші, ніж без потреби в бібліотеці bignum.

Raspberry Pi не має більше 4 ГБ оперативної пам’яті. При 1 ГБ оперативної пам’яті ви повністю втратили перше з двох основних переваг. Що стосується другої вигоди, то який відсоток людей насправді використовує досить гігантські номери, що має сенс для фонду підтримувати цілу другу операційну систему? Так, RPI може використовувати величезну кількість за допомогою програмних методів, але, схоже, якщо ви будете послідовно знаходитись у цій царині, то в будь-якому випадку вам потрібно використовувати краще обладнання.

Проблеми з 64 бітом :

Можливість зберігання більшої кількості не надається магією. Швидше, розмір об'єктів пам'яті потрібно збільшувати. У C (і C ++) це означає зміну intна int64_t. Це не робиться автоматично, отже коментарі щодо фонду не хочуть підтримувати дві гілки.

Крім того, багато програм просто не надають переваги (для більшості користувачів) під час роботи в 64-бітовому режимі. Зауважте, що більшість веб-браузерів, MS Office та ціла низка іншого популярного програмного забезпечення все ще постачаються та підтримуються 32-бітним способом. Звичайно, ви можете отримати свої руки на 64-бітній версії MS Office, але вона використовується рідко.

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

Також зверніть увагу :

Тільки тому, що ви працюєте на 64-бітній машині, не означає, що програма не працює як 32-бітна. Windows робить це дуже зрозумілим, маючи два різні шляхи встановлення C:\Program Filesта C:\Program Files (x86).

Отже, чи зможе фонд забезпечити підтримку 64 біт? :

Ми знову в тому ж пункті: "Деякі люди можуть побачити користь, але більшість не буде". Ви, звичайно, побачите інші проекти, що пропонують 64-бітні збірки, але якщо фундамент не отримає багато незаслужених (imo) провалів, вони, ймовірно, не будуть і не повинні (imo). Створення та підтримка окремої 64-бітової гілки не є малим починанням, і, чесно кажучи, просто не здається цього вартим.

Варто зазначити, що ситуація в ARM та Intel / AMD різна. Це тому, що перехід на x86_64 був також використаний як можливість оновити архітектуру, яка погано старіє, в основному покалічивши лише 8 реєстрів загального призначення - і подвоївшись у 64-бітному режимі. Таким чином, перехід системи Intel / AMD в 64-бітний режим також означає реалізацію реальних функцій, які суттєво різняться у продуктивності.

ARM не має цієї проблеми для початку (хоча AArch64 додає регістри, 32-розрядні архітектури не голодували за них), тому переваги в основному є більш безпосередньо адресованою пам'яттю та підтримкою великого цілого числа - набагато менше великої угоду, і, можливо, протидіяти її зворотній стороні (більше пам'яті використовується для всього).

(Окрім цього, з цієї причини було проведено певну роботу зі створення "x32" abi для Intel / AMD Linux , збереження покращення процесора, але використання 32-бітних покажчиків.)

Я впевнений, що на Pi 3 вже є люди, які працюють Debian Aarch64 (ARMv8); Для багатьох людей це, звичайно, не буде таким важким ( дивіться тут деякі підказки про те, що це може спрацювати) ^1, хоча для більшості користувачів це, мабуть, трохи розтягує.

Однак якщо Raspbian та / або Фонд не вийдуть із 64-розрядною версією, ви все частіше побачите людей, що мають блоги тощо, пояснюючи, як запустити та все-таки отримати потрібні смаколики.

Зараз для Pi 3 випущено Fedora aarch64 .

^{1. З 32-розрядними /opt/vcречами будуть деякі ускладнення , я не впевнений, наскільки це переможливо; там раніше були 32-бітні компактні лісти для x86-64, але Aarch64 ... можливо, ні.}

У рамках рекламного розголосу про запуск я зазначив, що однією проблемою є зусилля, необхідні для підтримки двох окремих баз коду (32 та 64 біт). У відеозаписі Adafruit PI3 Launch також згадувалося, що перехід на 64-бітовий процесор був скоріше пов'язаний із збільшенням частоти тактової швидкості нового мікросхеми, ніж із використанням режиму 64 біт.

64-розрядна адресація може бути корисною, навіть якщо у вас немає більше 1 ГБ пам'яті.

Це дозволяє проводити карту пам'яті великих файлів, тому у вас є вказівник і дозволяйте ОС робити введення / виведення прозоро. Просто ще один спосіб здійснення вводу-виводу. Вам потрібно 64-бітну адресацію для великих файлів.

Інший приклад, де я бачу, що це може бути корисним, - це дозволити процесам мати більше 2 Гб адресного простору, використовуючи простір підкачки. Нещодавно у мене виникла проблема з 32-розрядним NAS з великою кількістю пам’яті та пошкодженою файловою системою. Процес fsck закінчився пам'яттю, навіть із включеними параметрами кешування. Додавання простору swap не могло вирішити проблему, 32-бітний адресний простір був жорстким обмеженням там. Тож просто не було можливості запустити fsck на цій великій пошкодженій файловій системі з 32-розрядним двійковим файлом. З 64-бітним двійковим та деяким місцем обміну, він би запустився.

Звертаючись до твердження про те, що 64-бітні вбудовані програми є більшими (більше пам’яті для даних та покажчиків) і що у 64-бітної ОС на ARMv8 немає помітних переваг з меншим 4 Гб оперативної пам’яті, я хочу піднести кілька бали.

Існують деякі суттєві відмінності в тому, як це робиться в ARMv7 (і раніше) та ARMv8 в архітектурному відношенні, які роблять виконання ARMv8 більш ефективним. Частина цього відбувається з більш широких внутрішніх шляхів передачі даних, частина - це усунення спеціальних випадків і набагато глибший конвеєр). Ці самі зміни покращують ARMv8 у виконанні коду ARMv7 (32 біт).

Рідні 64-бітні програми використовують 64-бітні покажчики, а 'size_t' - 64 біти, тому елементів, які використовують ці програми, стає більше. Решта даних, як правило, залишатиметься однаковими. Однак, значення цього значення є незначним щодо розміру виконуваних зображень.

Там, де насправді світить 64-бітний натур (якщо вам не байдуже велике ціле число та речі з плаваючою точкою) є більший віртуальний адресний простір:

• ОС здатна розділити віртуальний адресний простір на все більші та більші розділи, що дозволяє простіше керувати спільними ресурсами, більш обтічні контекстні перемикання між різними рівнями привілеїв тощо.
• Якщо ви ввімкнули заміну, ви можете запускати все більші та більші процеси, що перевищують обмеження фізичної пам'яті (це насправді справедливо і в 32 бітах, але ви менше обмежені в 64 бітах)

Незалежно від того, використовує це ОС ОС чи ні, це зміниться, оскільки основний потік відходить від 32-бітного.

Я думаю, що найкращим аргументом для переміщення до рідного 64-бітного ядра AArch64 є портативність: основний робочий стіл перемістився в основному до 64-бітових процесорів, і я бачу більше пакетів, які передбачають 64 біт, і перенести такий код назад до 32 біт важче. ніж перенесення з 32 до 64 біт. У користувальницькому просторі ви можете запускати 32-бітні програми та 64-бітні програми поруч, якщо припустити, що ви встановили багатоархівні бібліотеки, тому не потрібно переносити 32 до 64 біт там, де його немає матерія. 64-бітна ОС просто збирається розширити вибір програмного забезпечення.

Я не кажу, що створити 64-бітове ядро ​​для Raspberry PI 3 досить просто - є суттєві відмінності, які потребують змін на низькому рівні, не всі драйвери пристроїв 64-бітні чисті (особливо драйвери для специфічних графічних процесорів ARM). Можливо, Raspberian залишиться 32-бітовою ОС, але я вважаю, що (у довгостроковій перспективі) це недалекоглядний.

Один завантажувальний носій (наприклад, SD-карта) може містити як 64, так і 32-бітні версії ОС, а додаткове програмне забезпечення для завантаження (u-boot, arm-boot та інші) може визначати, яку з них завантажити. Більш жорстка частина - це userland - файлова система повинна бути багатохарактерною навіть у 32-бітних системах, де 64-бітний матеріал буде марний. Я би вирішив це за допомогою сценарію або утиліти, яку можна запустити після початкового завантаження для видалення непотрібних бібліотек та програмних виконуваних файлів у 32-бітних системах.

Існуючі відповіді дуже добре висвітлюють проблеми 64-бітної арки, але я не бачу багатьох заявлених переваг оновлення. Отже, ось я нещодавно відкрив два:

• Коли PHP обробляє часові позначки Unix, розмір цілого числа в 32-бітовій арці встановлює верхню межу для дат, так що вони не можуть перевищувати конкретного дня 2038 року . Я думаю, це проблема для всіх мов, які обробляють часові позначки. (На щастя, більшість підсистем обробки дат, які не використовують часові позначки Unix, такі як DateTime PHP, розроблені спеціально, щоб не обмежуватись цією проблемою навіть на старих процесорах).

• Mongo обмежений розміром баз даних розміром 2G на цій арці, і 32-бітні збірки незабаром будуть застарілі. З посібника :

  Починаючи з MongoDB 3.2, 32-розрядні двійкові файли застаріли, і вони не будуть доступні в майбутніх випусках.

  Хоча 32-бітні версії існують для Linux та Windows, вони непридатні для виробничих розгортань. 32-бітні збірки також не підтримують двигун зберігання даних WiredTiger.

Мої думки з цього приводу: Хоча я не знаю точно, як процесор ARM адреси пам'яті, я можу вам сказати це з попередніх декількох архітектур процесора, які я запрограмував (SPARC / Alpha / i386 / AMD64 / X86_64): під час використання спільної пам'яті та адреси за своїм "реальним" вказівником віртуальної адреси переміщення на 64-бітний не є тривіальним. Хоча memcpy робить те, що має робити, потрібно враховувати, що в 64 бітах дані зберігаються так (біт назад):

HGFEDCBA
HGFEDCBA
HGFEDCBA

але в 32 бітах це виглядає приблизно так:

ABCD
ABCD
ABCD

Так, у 32 бітах, коли ви зберігаєте скажімо jpeg в оперативній пам’яті, ви можете читати його байти заголовка або виконувати виявлення ребер без проблем в лінійному режимі * скажімо, перейшовши байт на байт вперед. Але в 64-бітній архітектурі це змінюється:

32 біт:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64 біт:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}