Есть ли хорошая причина для запуска 32-разрядного программного обеспечения вместо 64-разрядного на 64-разрядных компьютерах?

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

Похоже, что 64-разрядное программное обеспечение будет более эффективным, позволит более интенсивно использовать память при необходимости и т. Д. Apple даже использует 64-разрядные процессоры для своих телефонов, хотя у них всего 1-2 ГБ ОЗУ, что значительно ниже 4 ГБ. предел для 32-битных процессоров.

Преимущества 32-битного программного обеспечения в 64-битных средах

• Меньший объем памяти, особенно в приложениях с большим количеством указателей, 64-битный по сравнению с 32-битным может легко удвоить требования к памяти.
• Объектные файлы также меньше.
• Совместимость с 32-битными средами.
• Утечки памяти жестко ограничены 2 ГБ, 3 ГБ или 4 ГБ и не затопят всю систему.

Недостатки 32-битного программного обеспечения в 64-битных средах

• 2 ГБ, 3 ГБ или 4 ГБ памяти на процесс. (Только для каждого процесса в сумме несколько 32-разрядных процессов могут использовать всю доступную системную память.)
• Не использовать дополнительные регистры и расширения набора команд в зависимости от x64. Это сильно зависит от компилятора и процессора.
• Может потребоваться 32-разрядные версии всех (большинство дистрибутивов Linux) или необычные (большинство версий Windows) библиотеки и среды выполнения. Если 32-разрядная версия разделяемой библиотеки загружается исключительно для вашего приложения, и это имеет значение для вашего присутствия. Нет разницы вообще, если вы ссылаетесь статически.

Другие аспекты

• Водители обычно не проблема. Только библиотеки пользовательского пространства должны различаться между 32-битными и 64-битными, а не API модулей ядра.
• Остерегайтесь различной ширины по умолчанию для целочисленных типов данных, требуется дополнительное тестирование.
• 64-разрядная архитектура процессора может даже не поддерживать 32-разрядную архитектуру.
• Некоторые методы, такие как ASLR и другие, зависящие от гораздо большего адресного пространства, чем физическая память, не будут работать (или вообще не будут) в 32-разрядном режиме выполнения.

Если не сравнить здесь очень специфичную архитектуру процессора, операционную систему и библиотечную инфраструктуру, я не смогу вдаваться в подробности.

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

Это означает, что все указатели в вашей программе в два раза больше. И (по крайней мере, в архитектуре ILP32 / LP64) ваши longs также в два раза больше. Обычно это приводит к увеличению размера объектного кода примерно на 30%. Это значит, что …

• Ваш объектный код займет ~ 30% больше времени для загрузки с диска в оперативную память
• ваш объектный код будет занимать ~ 30% больше места в памяти
• вы эффективно сократили пропускную способность вашей памяти (для объектного кода) на ~ 20%
• вы эффективно сократили размер кэша команд на ~ 20%

Это оказывает существенное негативное влияние на производительность.

Делать это имеет смысл, только если вы можете как-то «выкупить» эти затраты производительности. По сути, есть два способа сделать это: вы выполняете много 64-битных целочисленных вычислений или вам требуется более 4 гигабайт отображенной памяти. Если один или оба из них верны, имеет смысл использовать 64-битное программное обеспечение, в противном случае это не так.

Примечание: есть некоторые архитектуры, в которых нет соответствующих 32- или 64-битных вариантов. В этом случае вопрос, очевидно, не имеет смысла. Наиболее известными являются IA64, который является только 64-битным и не имеет 32-битного варианта, и x86 / AMD64, хотя и тесно связанные, с разными архитектурами, x86 только 32-битная, AMD64 только 64-битная.

На самом деле, это последнее утверждение уже не на 100% верно. Linux недавно добавила x32 ABI, который позволяет запускать код AMD64 с 32-разрядными указателями, поэтому, хотя это и не «правильная» архитектура ЦП, это способ использовать архитектуру AMD64 таким образом, как если бы он имел собственный 32 битный вариант. Это было сделано именно потому, что упомянутые выше издержки производительности вызывали реальные измеримые, поддающиеся количественной оценке проблемы для реальных пользователей, выполняющих реальный код в реальных системах.

Если программное обеспечение должно напрямую взаимодействовать с устаревшими системами, драйверами или библиотеками, вам может потребоваться предоставить 32-разрядную версию, поскольку AFAIK для ОС в целом (определенно, для Windows и Linux AFAIK) не позволяет смешивать 64-разрядные и 32-разрядные версии. -битный код в процессе.

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

​

Если ваше программное обеспечение является DLL, вы ДОЛЖНЫ предоставить как 32-битную, так и 64-битную версии. Вы не представляете, будет ли клиент использовать 32-разрядное или 64-разрядное программное обеспечение для связи с DLL, и DLL должна использовать ту же длину в битах, что и приложение. Это не подлежит обсуждению.

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

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

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