32-разрядный по сравнению с 64-разрядными системами

Kristof и Poshi заявили основные технические различия между ОС на 32 и 64 бита, пользовательский опыт обычно очень отличается, чем теория. Потребительские версии на 64 бита Windows до настоящего времени (XP и Vista) имеют большие зияющие дыры в своей поддержке драйвера. У меня было много принтеров, сканеров, и другие внешние устройства утончаются не, работают с версиями на 64 бита, которые хорошо работают с версиями на 32 бита. Это устройства, которые имели драйверы на 64 бита, и они все еще не будут работать. В этой точке я рекомендовал бы избегать чего-либо, что потребитель основывал, который составляет 64 бита от Microsoft, пока Вы не слышите о том, как Windows 7 обрабатывает это, от настоящих конечных пользователей, не только uber-фанатов, у которых в настоящее время есть доступ к нему. Дайте ему 6 месяцев, по крайней мере, и посмотрите то, что испытывают люди. Лично я буду устанавливать разновидность на 32 бита Windows 7, поскольку мои версии на 64 бита Vista являются дорогим бумажным весом, который я прекратил использовать несколько эр назад и вернулся к XP 32 бита.

64-разрядная ОС может использовать больше RAM. Это об этом на практике. 64-разрядные функции безопасности знатока использования Vista/7 для того, куда они помещают жизненные компоненты в RAM, но это не действительно 'noticable' как таковой.

От ChrisInEdmonton:

32-разрядная операционная система в ix86 системе с PAE может обратиться к 64 ГБ RAM. 64-разрядная операционная система на x86-64 может получить доступ к 256 ТБ виртуального адресного пространства, хотя это может быть повышено в последующих процессорах, до 16 EB. Обратите внимание, что некоторые операционные системы ограничивают адресное пространство далее, и большинство материнских плат будет иметь дополнительные ограничения.

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

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

Цитата из Microsoft.com:

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

Некоторые игровые программы используют битовое представление . Шахматы, шашки и othello, например, имеют доску 8х8, т.е. 64 квадрата, так что наличие как минимум 64 бит в машинном слове существенно помогает производительности.

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

На 32-разрядной машине у вас всего 4 294 967 295 байт памяти для адресации. На 64-битной машине у вас есть 1.84467441 × 10^19 байт памяти.

Википедия говорит, что эти

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

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

Виртуальные 64-битные Java-машины Sun запускаются медленнее, чем их 32-битные виртуальные машины, так как Sun реализовала только "серверный" JIT-компилятор (C2) для 64-битных платформ. [9] На 64-битных платформах недоступен "клиентский" компилятор JIT (C1), который выдает менее эффективный код, но компилируется значительно быстрее.

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

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

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

Изменение размера адреса может иметь некоторые большие последствия и последствия.

Этот поток уже слишком длинный, но ...

Большая часть ответов сосредоточена на том, что у вас больше 64-битного адресного пространства, поэтому вы можете обратиться к большему количеству памяти. Примерно для 99% всех приложений это совершенно не актуально. Большой уп.

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

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

Так что "типичное" приложение на Си/Си++ получит прирост производительности примерно на 10% или 15% только за счет перекомпиляции под 64-битные регистры. (Допустим, часть приложения была вычислена ограниченной. Конечно, это не guarenteed, все компьютеры ждут одинаковой скорости. Ваш пробег мая Вари.)

Кроме уже упомянутых преимуществ, здесь есть еще кое-что относительно безопасности:

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

Другое преимущество, которое приходит на ум, заключается в том, что объем виртуальной сопрягаемой памяти, выделенный с помощью vmalloc() в ядре Linux, может быть больше в 64-битном режиме.

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

Взгляните на том 4, preFascicle 1A для некоторых примеров крутых трюков, о которых я говорю.

Самое большое влияние, которое люди заметят в данный момент, это то, что 32-битный ПК может обращаться только к максимуму 4 ГБ памяти. Когда вы снимаете память, выделенную для других целей операционной системой, ваш ПК, вероятно, покажет только около 3.25 ГБ полезной памяти. Перейдите на 64 бит, и этот лимит исчезнет.

Если вы делаете серьезные разработки, то это может быть очень важно. Попробуйте запустить несколько виртуальных машин и память скоро закончится. Скорее всего, серверам понадобится дополнительная память, и вы обнаружите, что 64-битное использование на серверах намного больше, чем на десктопах. Закон Мура гарантирует, что у нас будет еще больше памяти на машинах, и поэтому в какой-то момент десктопы также перейдут на 64 бита в качестве стандарта.

Для более детального описания различий в процессорах ознакомьтесь с этой замечательной статьей из ArsTechnica.

Ничего не освобождается: хотя 64-битные приложения могут получить доступ к большему объему памяти, чем 32-битные приложения, недостаток заключается в том, что им требуется больше памяти. Все те указатели, которые раньше требовали 4 байта, теперь им нужно 8. Например, по умолчанию в Emacs при сборке для 64-битной архитектуры требуется на 60% больше памяти. Этот дополнительный след снижает производительность на каждом уровне иерархии памяти: большие исполняемые файлы дольше загружаются с диска, большие рабочие наборы вызывают больше подкачки, а большие объекты означают меньше места в кэш-памяти процессора. Если подумать о процессоре с 16K L1 кэшем, то 32-битное приложение может работать с 4096 указателями, прежде чем пропустит и перейдет в L2 кэш, но 64-битное приложение должно дотянуться до L2 кэша всего лишь после 2048 указателей.

На x64 это смягчается другими архитектурными усовершенствованиями, такими как увеличение количества регистров, но на PowerPC, если ваше приложение не может использовать >4G, оно, скорее всего, будет работать быстрее на "ppc", чем на "ppc64". Даже на Intel есть рабочие нагрузки, которые работают быстрее на x86, и лишь немногие из них работают более чем на 5% быстрее на x64, чем на x86.

Не уверен, что смогу ответить на все ваши вопросы без написания целого сочинения (всегда есть 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. Работа с регистрами намного быстрее, чем работа с оперативной памятью, и чем больше регистров есть у CPU, тем реже ему приходится менять значения регистров на оперативную память и обратно на регистры.

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

sysctl machdep.cpu.extfeatures

Если он содержит список EM64T, то Ваш процессор поддерживает 64-битное адресное пространство согласно стандарту x86-64. Также можно посмотреть

sysctl hw.optional.x86_64

Если написано 1 (true/abled), то ваш процессор поддерживает битный режим x86-64, если написано 0 (false/disabled), то нет. Если параметр вообще не найден, считайте, что он ложный.

Примечание: Вы также можете получать sysctl переменные из "родного" приложения на C, без необходимости использования утилиты командной строки. Смотрите

man 3 sysctl

В принципе, можно сделать всё в большем масштабе:

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-битные.

2 больших типа 64-битных архитектур - это x64 и IA64 архитектуры. Но на сегодняшний день x64 является самой популярной.

x64 может выполнять как команды x86, так и команды x64. IA64 также выполняет x86 команды, но не делает SSE расширений. Для выполнения x86 команд на Itanium выделено аппаратное обеспечение; это эмулятор, но на аппаратном уровне.

Как уже упоминал @Phil, здесь можно глубже взглянуть на .

Обратите внимание, что адресное пространство может быть использовано для более (реальной) памяти. Можно также карты памяти большие файлы, которые могут улучшить производительность в более нечетные шаблоны доступа, потому что более мощный и эффективный блок-уровня VM уровне кэширования запускается. Также безопаснее выделять большие блоки памяти на 64-бите, так как heapmanager реже сталкивается с фрагментацией адресного пространства, что не позволяет ему выделять большой блок.

Некоторые вещи, сказанные в этом потоке (например, удвоение регистров #), относятся только к x86-> x86_64, а не к 64-битным вообще. Так же как и то, что под x86_64 гарантированно имеется SSE2, 686 опкодов и дешевый способ делать PIC. Речь идет, строго говоря, не о 64-битности, а об урезании наследия и исправлении известных ограничений x86

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

Также имейте в виду, что часто применяется начальное наказание, так как средняя структура данных будет увеличиваться просто потому, что размер указателя больше. Это также имеет эффект кэширования, но более заметно в том, что средняя memcpy() (или любой эквивалент памяти на вашем языке) займет больше времени. Это только в размере нескольких процентов btw, но и указанное выше ускорение тоже в этом размере.

Обычно на 64-битных архитектурах накладные расходы на выравнивание также больше (записи, ранее 32-битные только часто становились смесью 32-битных и 64-битных значений), что ещё больше взрывает структуры. В целом, мои простые тесты показывают, что если драйверы и библиотеки времени исполнения полностью адаптированы, то они грубо взаимно уничтожат друг друга, не давая никакой существенной разницы в скорости для среднего приложения. Однако некоторые приложения могут внезапно стать быстрее (например, в зависимости от AES) или медленнее (критическая структура данных постоянно перемещается/сканируется/ходит и содержит много указателей). Тем не менее, тесты проводились под Windows, поэтому оптимизация PIC не была протестирована.

Обратите внимание, что большинство языков JIT-VM (Java, .NET) используют в среднем значительно больше указателей (внутренне), чем, например, C++. Вероятно, их использование памяти увеличивается больше, чем для средней программы, но я не осмелюсь приравнять это непосредственно к замедляющим эффектам (так как это действительно сложные и фанковитые звери, и часто их трудно предсказать без измерений)

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

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

(**) Несколько лет назад доктор Доббс написал хорошую статью об этом.