32-бітні та 64-бітні системи

Які відмінності між 32-розрядною та 64-бітовою системами?

Якщо ви вживали їх обох, які різкі відмінності ви відчули?

Чи буде проблема використовувати 32-бітні програми в 64-бітних системах в деяких випадках?

Примітка. Ці відповіді стосуються стандартних ПК на базі x86 (Intel та AMD) та Windows (як правило, налаштованих для кінцевих користувачів). Інші 32-бітні або 64-бітні мікросхеми, інші ОС та інші конфігурації ОС можуть мати різні компроміси.

З технічної точки зору 64-бітна ОС дає вам:

• Дозволяє окремим процесам адресувати більше 4 ГБ оперативної пам’яті кожен (на практиці більшість, але не всі 32-бітні ОС також обмежують загальну оперативну пам'ять системи менше 4 Гб, а не лише максимум на додаток).

• Усі вказівники беруть 8 байт замість 4 байтів. Ефект від використання оперативної пам’яті мінімальний (тому що ви, швидше за все, не маєте додатка, заповненого гігабайти покажчиків), але в гіршому теоретичному випадку це може зробити так, щоб кеш процесора міг вмістити на 1/2 більше покажчиків (що робить це ефективно на 1/2 розміру). Для більшості застосунків це не велика справа.

• Існує набагато більше регістрів загального призначення CPU в 64-бітному режимі. Регістри - це найшвидша пам'ять у всій вашій системі. Є лише 8 в 32-бітному режимі та 16 регістрів загального призначення в 64-бітному режимі. У написаних нами наукових обчислювальних програмах я помітив до 30% підвищення продуктивності, перекомпілювавшись у 64-бітному режимі (моя програма дійсно могла б використовувати додаткові регістри).

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

З точки зору користувача:

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

• Якщо у вас є будь-які програми для вимкнення пам'яті (наприклад, редактори фотографій, обробка відео, наукові обчислення тощо), якщо у вас є (або ви можете придбати) більше 3 ГБ оперативної пам’яті, і ви можете отримати 64-бітну версію програми, вибір простий: використовуйте 64-бітну ОС.

• Деяке обладнання не має 64-бітних драйверів. Перед переключенням перевірте свою материнську плату, усі плагіни та всі пристрої USB. Зауважте, що в перші дні Windows Vista було багато проблем з драйверами. У ці дні справи взагалі краще.

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

• Ви можете запускати 32-бітні програми (але не драйвери) в 64-бітних Windows без проблем. Найгірше уповільнення, яке я вимірював для 32-розрядного додатку в 64-розрядної Windows, становить близько 5% (це означає, що якщо зробити 32-бітну Windows потрібно 60 секунд, то це зайняло максимум 60 * 1,05 = 65 секунд при той самий 32-розрядний додаток у 64-бітних Windows).

Що з 32-розрядної та 64-бітової версій не означає:

У системах x86 32-розрядні проти 64-бітні безпосередньо стосуються розміру вказівників. Це все.

• Це не відноситься до розміру C intтипу. Це вирішено конкретною реалізацією компілятора, і більшість популярних компіляторів вибирають 32-розрядні intв 64-бітних системах.

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

• Це не стосується безпосередньо розміру шини фізичної адреси. Наприклад, для системи з 64 бітовими лініями кешу і максимум 512 Гбіт пам'яті потрібно лише 33 біти в шині адреси (тобто log2(512*1024**3) - log2(64) = 33).

• Це не стосується розміру фізичної шини даних: це більше пов'язано з витратами на виробництво (кількість штифтів у процесорному сокеті) та розмірами кеш-рядків.

В основному ви можете зробити все в більшому масштабі:

1. Оперативна пам’ять на ОС: обмеження оперативної пам’яті 4 Гб на x86 для ОС (більшість часу)
2. Оперативна пам’ять на процес: обмеження оперативної пам’яті 4 Гб на x86 для процесів (завжди). Якщо ви вважаєте, що це не важливо, спробуйте запустити величезний інтенсивний додаток для бази даних MSSQL. Він використовуватиме сам 4 Гб, якщо у вас є доступний і працює набагато краще.
3. Адреси: Адреси - це 64 біти замість 32 біт, що дозволяє мати "більші" програми, що використовують більше пам'яті.
4. Ручки, доступні програмам: Ви можете створити більше файлових ручок, процесів, ... Приклад у Windows x64 ви можете створити> 2000 потоків за процес, але на x86 ближче до декількох сотень.
5. Доступні ширші програми: з x64 можна запускати як програми x86, так і x64. (Приклад windows: wow64, windows32 в емуляції Windows64)
6. Параметри емуляції: з x64 можна запускати як V86, так і x86 та x64.
7. Швидше: деякі обчислення проходять швидше на 64-бітному процесорі
8. Розділення декількох системних ресурсів: Багато пам'яті оперативної пам’яті дуже важливо, коли ви хочете запустити хоча б одну віртуальну машину, яка розділяє ресурси системи.
9. Доступні ексклюзивні програми: Кілька нових програм підтримують лише x64. Приклад Exchange 2007.
10. Майбутній застарілий x86 ?: З часом буде використовуватися все більше 64-бітних і більше x86 не використовуватимуться. Тож постачальники підтримуватимуть лише 64-бітні і більше.

Два великих типи 64-бітових архітектур - це архітектури x64 та IA64. Але x64 - найпопулярніший на сьогоднішній день.

x64 може виконувати команди x86, а також команди x64. IA64 також виконує команди x86, але це не робить розширення SSE. Існує обладнання, присвячене Itanium, для виконання інструкцій x86; це емулятор, але апаратно.

Як згадував @Phil, ви можете глибше зрозуміти, як це працює тут .

Найбільший вплив, який люди помітять на даний момент, полягає в тому, що 32-бітний ПК може підтримувати максимум 4 Гб пам'яті. Коли ви знімаєте операційну систему пам'яті, виділеної для інших цілей, ваш ПК, ймовірно, відображатиметься лише 3,25 ГБ пам’яті. Перемістіть на 64 біт, і ця межа зникає.

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

Щоб отримати більш детальний опис відмінностей процесорів, ознайомтеся з цією чудовою статтею від ArsTechnica .

Нічого не є безкоштовним: хоча 64-розрядні програми можуть отримати доступ до більшої пам’яті, ніж 32-бітні програми, недоліком є ​​те, що їм потрібно більше пам’яті. Усі ті вказівники, на які раніше було потрібно 4 байти, зараз їм потрібно 8. Наприклад, вимога за замовчуванням у Emacs - це на 60% більше пам'яті, коли вона вбудована для 64-бітної архітектури. Цей додатковий слід погіршує продуктивність на кожному рівні ієрархії пам’яті: більша кількість виконуваних файлів займає більше часу для завантаження з диска, більші робочі набори викликають більше підказок, а більші об'єкти означають менше вміщення в кеш процесора. Якщо ви думаєте про процесор з кеш-пам'яттю LK 16K, 32-розрядний додаток може працювати з 4096 вказівниками до його пропуску та переходу до кешу L2, але 64-бітний додаток повинен досягти кешу L2 лише після 2048 покажчиків.

На x64 це пом'якшується іншими архітектурними удосконаленнями, такими як інші регістри, але на PowerPC, якщо ваша програма не може використовувати> 4G, швидше за все, вона працюватиме швидше на "ppc", ніж "ppc64". Навіть в Intel є навантаження, яка працює швидше на x86, і мало хто працює на 5% швидше, ніж на x64, ніж на x86.

64-бітова ОС може використовувати більше оперативної пам'яті. Саме про це, на практиці. 64-розрядна Vista / 7 використовує ефективніші функції безпеки, де вони розміщують життєво важливі компоненти в оперативній пам’яті, але це не дуже «помітно» як таке.

Від ChrisInEdmonton:

32-розрядна операційна система в ix86 з PAE може обробляти до 64 ГБ оперативної пам’яті. 64-розрядна операційна система на x86-64 може отримати доступ до 256 ТБ віртуального адресного простору, хоча це може бути збільшено в наступних процесорах, до 16 ЕБ. Зауважте, що деякі операційні системи додатково обмежують адресний простір, і більшість материнських плат матимуть додаткові обмеження.

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

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

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

Основна "велика справа" на 64 бітах полягає в тому, що ви отримуєте доступ до значно більшого адресного простору пам'яті, ніж 32-бітний. Це означає, що ви дійсно можете посміхнути більше 4 Гб оперативної пам’яті на свій комп’ютер і насправді це має значення.

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

Що стосується виявлення різниці, то програмно ви просто перевіряєте розмір вказівника (наприклад, sizeof (void *)). Відповідь 4 означає його 32 біти, а 8 означає, що ви працюєте в 64-бітовому середовищі.

32-бітний процес має віртуальний адресний простір у 4 Гб; це може бути занадто мало для деяких додатків. Додаток 64 біт має практично необмежений адресний простір (звичайно, він обмежений, але ви, швидше за все, не досягнете цієї межі).

У OSX є й інші переваги. Дивіться наступну статтю , чому запуск ядра в 64-бітному адресному просторі (незалежно від того, чи працює ваш додаток 64 або 32) або запуск програми в 64-бітному адресному просторі (в той час як ядро ​​все ще 32-бітне) призводить до набагато кращої продуктивності. Підводячи підсумок: Якщо будь-який з них має 64 біт (ядро або додаток, або обидва, звичайно,), TLB ("буфер перекладу перегляду") не потрібно мити щоразу, коли ви переходите з ядра, щоб використовувати простір і назад (що прискорить швидкість доступ до оперативної пам’яті).

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

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

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

sysctl machdep.cpu.extfeatures

Якщо в ньому перераховано EM64T, ваш процесор підтримує 64-бітний адресний простір відповідно до стандарту x86-64. Ви також можете шукати

sysctl hw.optional.x86_64

Якщо він говорить 1 (вірно / увімкнено), ваш процесор підтримує бітовий режим x86-64, якщо він говорить 0 (помилково / вимкнено), це не так. Якщо налаштування взагалі не знайдено, вважайте його помилковим.

Примітка. Ви також можете отримати змінні sysctl з внутрішньої програми C, не потрібно використовувати інструмент командного рядка. Побачити

man 3 sysctl

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

Деякі речі, сказані в цій темі (як подвоєння # регістрів), стосуються лише x86-> x86_64, а не 64-бітових. Як і те, що під x86_64 на одному гарантованому рівні є SSE2, 686 опкодів та дешевий спосіб зробити PIC. Ці функції суворо не про 64-бітові, а про скорочення спадщини та усунення відомих обмежень x86

Більше того, люди досить часто вказують на подвоєння регістрів як причину прискорення, в той час, як скоріше за все за допомогою стандартного SSE2 використовується хитрість (прискорення memcpy та подібні функції). Якщо ви ввімкнете один і той же набір для x86, різниця набагато менша. (*) (***)

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

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

В цілому мої прості тести вказують, що вони приблизно скасують один одного, якщо драйвери та бібліотеки часу виконання повністю адаптуються, не даючи значної різниці швидкості для середнього додатка. Однак деякі програми можуть раптово ставати швидшими (наприклад, коли це залежить від AES) або повільніше (важлива структура даних постійно переміщується / сканується / ходить і містить безліч покажчиків). Проте тести були на Windows, і тому оптимізація PIC не орієнтувалася.

Зауважте, що більшість мов JIT-VM (Java, .NET) в середньому (внутрішньо) використовують значно більше покажчиків, ніж, наприклад, C ++. Можливо, їх використання в пам'яті збільшується більше, ніж у середній програмі, але я не наважуюся прирівнювати це безпосередньо до уповільнюючих ефектів (оскільки це справді складний і прикольний звір і часто важко передбачити без вимірювання)

64-бітні Windows за замовчуванням використовують SSE2 для плаваючої точки, що, здається, прискорює прості операції та уповільнює складні (sin, cos тощо) операції.

(*) Маловідомий факт полягає в тому, що кількість реєстрів SSE також подвоюється в 64-бітному режимі

(**) У доктора Доббса була чудова стаття про це кілька років тому.

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

Погляньте на том 4, попередній Fascicle 1A, щоб ознайомитись із деякими прикладами крутих хитрощів, про які я говорю.

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

Архітектура x86_64 назад сумісна з x86. Можна запустити немодифіковані 32-бітні операційні системи. Також можна запустити немодифіковане 32-бітове програмне забезпечення з 64-бітної ОС. Для цього знадобляться всі звичайні 32-бітні бібліотеки. Можливо, їх потрібно буде встановити окремо.

Ця тема вже занадто довга, але ...

Більшість відповідей зосереджені на тому, що у вас є більший, 64-розрядний адресний простір, щоб ви могли отримати більше пам'яті. Для приблизно 99% усіх програм це абсолютно не має значення. Великий кружок.

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

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

Таким чином, "типовий" C / C ++ додаток отримає приблизно 10% або 15% поліпшення продуктивності лише шляхом перекомпіляції для 64-розрядних. (Якщо припустити, що частина програми була обчислена. Звичайно, це не гарантовано; всі комп'ютери чекають однакової швидкості. Ваш пробіг може змінюватися.)

Окрім уже згаданих переваг, тут є ще кілька щодо безпеки:

• x86_64 cpus має біт невиконання у своїх таблицях сторінок. Тобто це може запобігти сприятливим експлуатаціям через перекриття буфера. 32-бітний x86 cpus підтримує цю функцію лише в режимі PAE.
• Більший адресний простір дозволяє покращити рандомізацію макета адресного простору (ASLR), що ускладнює експлуатацію перекриття буфера.
• x86_64 cpus має незалежний від позиції код, тобто доступ до даних відносно реєстру покажчиків інструкцій (RIP).

Ще одна перевага, яка спадає на думку, полягає в тому, що обсяг віртуальної суміжної пам’яті, виділений vmalloc()в ядрі Linux, може бути більшим у 64-бітному режимі.

З 32-бітовою машиною у вас є лише 4,294,967,295 байт пам'яті. З 64-розрядною машиною ви маєте 1,84467441 × 10 ^ 19 байт пам'яті.

Про це говорить Вікіпедія

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

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

64-бітні віртуальні машини Java Sun запускаються повільніше, ніж їхні 32-бітні віртуальні машини, оскільки Sun реалізує лише "серверний" компілятор JIT (C2) для 64-бітних платформ. [9] "Клієнтський" компілятор JIT (C1), який створює менш ефективний код, але збирається набагато швидше, недоступний на 64-бітних платформах.

Слід зазначити, що швидкість - не єдиний фактор, який слід враховувати при порівнянні 32-бітних та 64-бітних процесорів. Такі програми, як багатозадачність, стрес-тестування та кластеризація (для високоефективних обчислень), HPC, можуть більше підходити до 64-бітної архітектури за умови правильного розгортання. З цієї причини 64-бітні кластери широко розгорнуті у великих організаціях, таких як IBM, HP та Microsoft.

Цитата від Microsoft.com:

У наступній таблиці збільшені максимальні ресурси комп’ютерів, що базуються на 64-бітних версіях Windows та 64-бітному процесорі Intel, порівнюються з існуючими 32-бітовими максимумами ресурсів.

Крістоф та Поші заявили, що основні технічні відмінності між 32 та 64 бітовою ОС "досвід користувача, як правило, значно відрізняється від теорії. На сьогоднішній день 64-розрядні споживчі версії Windows (XP та Vista) мають великі зазори в підтримці драйверів. У мене було багато принтерів, сканерів та інших зовнішніх пристроїв, які не працюють з 64-бітовими версіями, які добре працюють з 32-бітовими версіями. Це пристрої, які мали 64 бітні драйвери, і вони все одно не працюватимуть. На даний момент я рекомендую вам не триматися подалі від будь-яких споживачів, що є 64-бітним від Microsoft, поки ви не почуєте про те, як Windows 7 справляється з цим, від реальних кінцевих користувачів, а не лише від убер-вундеркінів, які наразі мають до нього доступ. Дайте йому хоча б 6 місяців і подивіться, що відчувають люди.

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

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

Термін 32-розрядний і 64-бітний відноситься до способу обчислювальної машини процесором (його також називають процесором). 64-бітні версії Windows обробляють велику кількість оперативної пам’яті з випадковим доступом (ОЗУ) ефективніше, ніж 32-бітні системи.

На мою думку, швидкість може бути різною

Іншим моментом, що стосується Microsoft Windows, є те, що багато років існував API Win32, призначений для 32-бітних операційних систем і не оптимізований для 64-бітного компіляції. Коли я пишу деякі DLL-файли для своїх додатків, я зазвичай компілюю в Win32, що не є 64-бітовою версією речей. До Vista не було багато успішних 64-бітних версій Windows. Я вважаю, що там, де я працюю, моя нова машина має 4 Гб оперативної пам’яті, але я все ще використовую 32-бітну Windows XP Pro, оскільки це відомий стабільний O / S відносно XP64 або Vista.

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

Зміна розміру адреси може мати великі наслідки та наслідки.

У більшості практичних цілей ви, мабуть, не помітите різниці.

Для встановлення 64-бітної операційної системи у вас повинен бути 64-розрядний процесор (більшість процесорів за останні кілька років).

У 64-бітної операційної системи є кілька переваг:

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

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