32-битные и 64-битные системы

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

С технической точки зрения 64-битная ОС дает вам:

• Позволяет отдельным процессам обращаться к более чем 4 ГБ ОЗУ каждый (на практике большинство, но не все 32-разрядные ОС также ограничивают общий объем используемой оперативной памяти системы менее 4 ГБ, а не только максимум для каждого приложения).

• Все указатели занимают 8 байтов вместо 4 байтов. Влияние на использование ОЗУ минимально (поскольку маловероятно, что приложение будет заполнено гигабайтами указателей), но в худшем теоретическом случае это может сделать кэш-память ЦП способной удерживать в 1/2 раза больше указателей (делая это будет эффективно 1/2 размера). Для большинства приложений это не так уж важно.

• В 64-битном режиме гораздо больше регистров ЦП общего назначения. Регистры являются самой быстрой памятью во всей вашей системе. В 32-битном режиме есть только 8 и 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 вы можете запускать виртуальные машины 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-битной архитектуры. Эта дополнительная нагрузка снижает производительность на всех уровнях иерархии памяти: большие исполняемые файлы загружаются с диска дольше, большие рабочие наборы вызывают больше подкачки, а большие объекты означают меньшее размещение в кэшах процессора. Если вы подумаете о ЦП с кешем L1 16 КБ, 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 EB. Обратите внимание, что некоторые операционные системы еще больше ограничивают адресное пространство, и большинство материнских плат будут иметь дополнительные ограничения.

Не уверен, что смогу ответить на все ваши вопросы без написания целого эссе (всегда есть Google ...), но вам не нужно разрабатывать свои приложения по-другому для 64-битных систем. Я предполагаю, что имеется в виду, что вы должны помнить о вещах, например, размеры указателя больше не соответствуют размеру целых. И у вас есть масса потенциальных проблем со встроенными допущениями для определенных типов данных длиной четыре байта, которые могут больше не соответствовать действительности.

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

Я думаю, что это проблема реализации, а не дизайна. Т.е. я думаю, что «дизайн», скажем, пакета для редактирования фотографий будет одинаковым независимо от размера слов. Мы пишем код, который компилируется как в 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 

Обратите внимание, что адресное пространство может использоваться для более чем (реальной) памяти. Можно также отобразить в памяти большие файлы, что может повысить производительность в более странных шаблонах доступа, потому что включается более мощное и эффективное кэширование на уровне виртуальных машин на уровне блоков. Кроме того, безопаснее выделять большие блоки памяти на 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 ++. Вероятно, их использование памяти увеличивается больше, чем для средней программы, но я не смею приравнивать это непосредственно к замедляющим эффектам (так как это действительно сложный и забавный зверь, который часто трудно предсказать без измерения)

(*) малоизвестный факт - число регистров SSE также удваивается в 64-битном режиме

(**) У доктора Доббса была хорошая статья об этом несколько лет назад.

Помимо очевидных проблем с пространством запоминания, о которых здесь упоминает большинство людей, я думаю, что стоит взглянуть на понятие «вычислений с широким словом», о котором Кнут (среди прочих) говорил в последнее время. За счет манипулирования битами можно получить много преимуществ, а побитовые операции с 64-битным словом идут намного дальше, чем с 32-битным словом. Короче говоря, вы можете выполнять больше операций в регистрах, не обращаясь к памяти, и с точки зрения производительности это довольно большой выигрыш.

Взгляните на Том 4, предисловие 1А, чтобы найти примеры классных трюков, о которых я говорю.

Помимо возможности адресовать больше памяти, x86_64 также имеет больше регистров, позволяющих компилятору генерировать более эффективный код. Улучшение производительности, как правило, будет довольно незначительным.

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