32-разрядные и 64-разрядные системы

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

1. ОЗУ на ОС: ограничение ОЗУ 4 ГБ на x86 для ОС (большую часть времени)
2. ОЗУ для каждого процесса: ограничение ОЗУ 4 ГБ на x86 для процессов (всегда). Если вы считаете, что это не важно, попробуйте запустить огромное приложение с интенсивным использованием базы данных MSSQL. Он будет использовать > 4GB себя, если у вас есть он доступен и работать гораздо лучше.
3. адреса: адреса 64bits вместо 32bits позволяет иметь" большие " программы, которые используют больше памяти.
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. Существует оборудование, выделенное на Itanium для запуска инструкций x86; это эмулятор, но в аппаратном.

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

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

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

для гораздо более подробного описания процессора различия проверить эту отличную статью от ArsTechnica.

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

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

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

От ChrisInEdmonton:

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

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

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

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

основное "большое дело" на 64bit что вы получаете доступ к гораздо большле адресному пространству памяти чем 32bit. Это значит что вы можете действительно chuck в больше чем 4Gb памяти в ваш компьютер и фактически иметь его внести изменения.

Я уверен, что другие ответы будут идти в детали и преимущества больше, чем я.

в условия обнаружения разницы затем программно вы просто проверяете размер указателя (например, sizeof (void*)). Ответ 4 означает его 32 бита, а 8 означает, что вы работаете в 64-битной среде.

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

на OSX есть и другие преимущества. Смотрите статье, почему имея ядре работать в 64 битном адресном пространстве (независимо от того, если ваше приложение работает 64 или 32) или иметь ваше приложение запускается в 64 битном адресном пространстве (в то время как ядро остается 32 бит) приводит к гораздо лучшей производительности. Подводя итог: если один из них 64-разрядный (ядро или приложение, или оба, конечно), TLB ("буфер перевода lookaside") не нужно сбрасывать при переключении с ядра на использование пространства и обратно (что ускорит доступ к оперативной памяти).

также у вас есть прирост производительности при работе с переменными" 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 (true/enabled), ваш процессор поддерживает x86-64 битный режим, если он говорит 0 (false/disabled), он этого не делает. Если параметр не найден, то его ложный.

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

man 3 sysctl

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

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

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

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

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

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

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

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

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

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

взгляните на том 4, pre-Fascicle 1A для некоторых примеров классных трюков, о которых я говорю.

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

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

эта ветка уже слишком длинная, но ...

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

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

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

Так" типичное " C/C++ приложение получите около 10% или 15% улучшения производительности только путем перекомпиляции для 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) большинство операционные системы и приложения могут работать на 64-разрядном оборудовании.

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

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

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

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

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

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

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

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

некоторые игровые программы использовать бит-доска представление. Шахматы, шашки и Отелло, например, имеют доску 8x8, ie 64 квадрата, поэтому иметь хотя бы 64 бита в машинном слове значительно помогает представлению.

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

термин 32-бит и 64-бит относится к тому, как процессор компьютера (также называемый CPU) обрабатывает информацию. 64-разрядные версии Windows обрабатывают большие объемы оперативной памяти более эффективно, чем 32-разрядные системы.

скорость может быть разной на мой взгляд

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

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

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