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

Припускаю, що я зосереджуюсь на x86, але мене, як правило, цікавить перехід з 32 на 64 біт.

Логічно, я бачу, що константи та вказівники, в деяких випадках, будуть більшими, тому програми, швидше за все, будуть більшими. І бажання розподілити пам'ять на межі слів для ефективності означало б більше пробілів між розподілами.

Я також чув, що 32-бітний режим на x86 повинен очистити кеш при перемиканні контексту через можливе перекриття адресних просторів 4G.

Отже, які реальні переваги 64 біт?

І як додаткове запитання, чи може бути 128 біт ще кращим?

Редагувати:

Я щойно написав свою першу 32/64-бітну програму. Він робить зв’язані списки / дерева з 16-байтними (32b-версія) або 32-байтовими (64b-версія) об’єктами і робить багато друку на stderr - не дуже корисна програма і не щось типове, але це мій перший.

Розмір: 81128 (32b) v 83672 (64b) - так не велика різниця

Швидкість: 17 с (32b) v 24s (64b) - працює в 32-розрядної ОС (OS-X 10.5.8)

Оновлення:

Зазначу, що розробляється новий гібридний x32 ABI (бінарний інтерфейс додатків), який має значення 64b, але використовує покажчики 32b. Для деяких тестів це призводить до зменшення коду та швидшого виконання, ніж 32b або 64b.

https://sites.google.com/site/x32abi/

Якщо вам не потрібно отримати доступ до більшої пам’яті, яку дозволить адресація 32b, вигоди будуть незначними, якщо такі є.

При роботі на процесорі 64b ви отримуєте той самий інтерфейс пам’яті, незалежно від того, використовуєте ви код 32b або 64b (ви використовуєте той самий кеш і ту саму шину).

Хоча архітектура x64 має ще кілька регістрів, що дозволяє полегшити оптимізацію, цьому часто протидіє той факт, що покажчики зараз більші, і використання будь-яких структур із покажчиками призводить до збільшення трафіку пам'яті. Я б оцінив збільшення загального використання пам'яті для програми 64b порівняно з 32b приблизно на 15-30%.

Я зазвичай бачу 30-процентне покращення швидкості для обчислювального коду на x86-64 порівняно з x86. Це, швидше за все, пов’язано з тим, що ми маємо 16 x 64 бітові регістри загального призначення та 16 x SSE регістри замість 8 x 32 бітних регістрів загального призначення та 8 x SSE регістри. Це стосується компілятора Intel ICC (11.1) на x86-64 Linux - результати з іншими компіляторами (наприклад, gcc) або з іншими операційними системами (наприклад, Windows), звичайно, можуть відрізнятися.

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

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

РЕДАГУВАТИ :
Будь ласка, проігноруйте мою заяву про паралельне додавання. Це не виконується звичайним оператором додавання ... Я плутав це з деякими векторизованими інструкціями / SSE. Більш точна перевага, крім більшого адресного простору, полягає в тому, що існує більше регістрів загального призначення, а це означає, що більше файлів локальних змінних може зберігатися у файлі реєстру ЦП, до якого набагато швидше отримати доступ, ніж якщо розмістити змінні в стек програм (що зазвичай означає вихід у кеш L1).

На додаток до того, що має більше регістрів, 64-розрядна версія має SSE2 за замовчуванням. Це означає, що ви дійсно можете паралельно виконувати деякі обчислення. Розширення SSE мали і інші ласощі. Але я думаю, що основною перевагою є відсутність необхідності перевіряти наявність розширень. Якщо це x64, у нього доступний SSE2. ... Якщо мене пам’ять не слугує.

Я кодую шахову машину на ім'я foolsmate . Найкраще вилучення ходу за допомогою пошуку дерева на основі мінімаксу на глибину 9 (з певного положення) взяли:

щодо Win32конфігурації: ~ 17.0s;

після переходу на x64конфігурацію: ~ 10.3s;

Це 41% прискорення!

Єдиним виправданням для переміщення вашої програми на 64 біт є потреба в більшій кількості пам’яті в таких додатках, як великі бази даних або ERP-програми, що мають принаймні 100 секунд одночасних користувачів, де обмеження 2 ГБ буде перевищено досить швидко, коли програми кешують для кращої продуктивності. Це особливо стосується ОС Windows, де ціле і довге все ще є 32-бітним (вони мають нову змінну _int64. Тільки вказівники мають 64-бітну версію. Насправді WOW64 високо оптимізований для Windows x64, так що 32-розрядні програми працюють із низьким показником у 64-бітовій Windows ОС. Мій досвід роботи з Windows x64 - це 32-розрядна версія програми, яка працює на 10-15% швидше, ніж 64-бітна, оскільки в колишньому випадку, принаймні для власних баз даних пам'яті, ви можете використовувати арифметичний покажчик для ведення b-дерева (найбільш інтенсивна процесорна частина систем баз даних) . Інтенсивні обчислювальні програми, які вимагають великих десяткових знаків для найвищої точності, не передбачені подвійними в 32-64-бітовій операційній системі. Ці програми можуть використовувати _int64 вбудовано замість емуляції програмного забезпечення. Звичайно, великі бази даних на диску також матимуть покращення за 32 біти просто завдяки можливості використовувати велику пам’ять для кешування планів запитів тощо.

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

У конкретному випадку від x68 до x68_64 64-розрядна програма буде приблизно однакового розміру, якщо не трохи менша, використовуватиме трохи більше пам'яті та працюватиме швидше. Здебільшого це тому, що x86_64 має не просто 64-бітові регістри, він також має вдвічі більше. x86 не має достатньо регістрів, щоб зробити скомпільовані мови настільки ефективними, наскільки вони можуть бути, тому код x86 витрачає багато інструкцій та пропускну здатність пам'яті, переміщуючи дані між регістрами та пам'яттю. x86_64 має набагато менше цього, тому він займає трохи менше місця і працює швидше. Інструкції з плаваючою комою та векторним перекручуванням бітів також набагато ефективніші в x86_64.

Загалом, однак, 64-розрядний код не обов'язково швидший і зазвичай більший, як для коду, так і для використання пам'яті під час виконання.

Будь-які програми, які вимагають використання центрального процесора, такі як перекодування, продуктивність дисплея та рендерінг медіа-файлів, будь то аудіо чи візуальне, напевно вимагатимуть (на даний момент) і виграють від використання 64-бітового проти 32-бітного завдяки здатності центрального процесора мати справу з простою кількість даних, які на нього кидаються. Справа не стільки в адресному просторі, скільки в способі обробки даних. 64-розрядний процесор, який має 64-розрядний код, буде працювати ефективніше, особливо з математично складними речами, такими як перекодування та дані VoIP - насправді, будь-які `` математичні '' програми повинні отримати вигоду від використання 64-розрядних процесорів та операційних систем. Доведи мене неправильно.