Чи є вагомі причини запустити 32-бітове програмне забезпечення замість 64-бітного на 64-бітних машинах?

Чи є якісь вагомі підстави поставляти 32-бітну версію разом із 64-бітною версією будь-якого програмного забезпечення, орієнтованого на сучасні настільні машини, під керуванням сучасних 64-бітних операційних систем на 64-бітному обладнанні?

Здається, що 64-розрядне програмне забезпечення було б більш ефективним, дозволяло б використовувати більше пам'яті при необхідності і т. Д. Apple навіть використовує 64-бітні процесори для своїх телефонів, хоча вони мають лише 1-2 ГБ оперативної пам’яті, значно нижче 4 Гб ліміт для 32-бітних процесорів.

Переваги 32-бітного програмного забезпечення в 64-бітних середовищах

• Нижчий обсяг пам’яті, особливо у важких додатках, 64-розрядні та 32-бітні можуть легко подвоїти потреби в пам’яті.
• Об'єктні файли також менші.
• Сумісність з 32-бітовим середовищем.
• Витоки пам'яті важко обмежені до 2 ГБ, 3 ГБ або 4 ГБ і не зможуть заповнити всю систему.

Недоліки 32-бітного програмного забезпечення в 64-бітних середовищах

• Обмеження пам’яті 2 ГБ, 3 ГБ або 4 ГБ на процес. (Просто за один процес, у сукупності багато 32-бітні процеси можуть використовувати всю наявну системну пам'ять.)
• Не використовувати додаткові регістри та розширення набору інструкцій залежно від x64. Це дуже компілятор і CPU.
• Може знадобитися 32-розрядні версії всіх (більшість дистрибутивів Linux) або нечасті (більшість версій Windows) бібліотек та запущені часові середовища. Якщо 32-розрядна версія спільної бібліотеки завантажується виключно для вашої програми, і вона зараховується до вашого сліду. Немає різниці, якщо ти зв’язуєшся статично.

Інші аспекти

• Водії, як правило, не є проблемою. Тільки бібліотеки простору користувача повинні відрізнятися між 32-бітними та 64-бітовими, а не API модулів ядра.
• Остерігайтеся різної ширини за замовчуванням для цілих типів даних, необхідне додаткове тестування.
• 64-розрядна архітектура процесора може взагалі не підтримувати 32-бітну.
• Деякі методи, такі як ASLR та інші, залежно від набагато більшого адресного простору, ніж фізична пам'ять, не працюватимуть добре (або зовсім) в 32-бітному режимі виконання.

Якщо не порівню тут дуже специфічну архітектуру процесора, операційну систему та бібліотечну інфраструктуру, я не зможу вдаватися до деталей.

Різниця між 32-бітним і 64-бітним програмним забезпеченням - це розмір покажчиків, а може бути і розмір цілочисельних регістрів. Це воно.

Це означає, що всі вказівники у вашій програмі вдвічі перевищують. І (принаймні, в архітектурі ILP32 / LP64) ваші longs також вдвічі більше. Зазвичай це дозволяє збільшити розмір об'єктного коду приблизно на 30%. Це означає що …

• ваш об'єктний код займе ~ 30% більше, щоб завантажити з диска в оперативну пам’ять
• ваш об'єктний код займе ~ 30% більше місця в пам'яті
• ви ефективно знизили пропускну здатність пам'яті (для об'єктного коду) на ~ 20%
• ви ефективно зменшили розмір кешу інструкцій на ~ 20%

Це негативно впливає на продуктивність.

Робити це має сенс лише в тому випадку, якщо ви зможете якось «викупити» ці продуктивність. В основному це можна зробити двома способами: ви робите багато 64-бітової цілочисельної математики, або вам потрібно більше 4 карт пам'яті GiByte. Якщо одне або те й інше вірно, має сенс використовувати 64-бітове програмне забезпечення, інакше це не так.

Примітка. Є деякі архітектури, де немає відповідних 32 або 64 бітних варіантів. У цьому випадку питання, очевидно, не має сенсу. Найвідомішими є IA64, який є лише 64 бітним і не має 32-бітового варіанту, і x86 / AMD64, які є, хоча і тісно пов'язаними, різними архітектурами, x86 має лише 32 біт, AMD64 - лише 64 біт.

Власне, це останнє твердження вже не є 100% правдивим. Нещодавно Linux додав x32 ABI, який дозволяє запускати код AMD64 з 32-бітовими покажчиками, тому, хоча це не "правильна" архітектура процесора, це спосіб використання архітектури AMD64 таким чином, як якщо б у неї була рідна 32-бітний варіант. Це було зроблено саме тому, що ефективність роботи, про яку я згадував вище, спричиняла реальні вимірювані, кількісно вимірювані проблеми для користувачів реального користування, які використовують реальний код у реальних системах.

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

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

Сігналы абмеркавання

Якщо ваше програмне забезпечення - це DLL, ви ОБОВ'ЯЗКОВО надаватимете 32-бітну та 64-бітну версії. Ви не маєте поняття, чи буде клієнт використовувати 32-бітне або 64-бітове програмне забезпечення для спілкування з DLL, і DLL повинен використовувати ту саму біт-довжину, що і додаток. Це необоротно.

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

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

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