Вопрос: 32-разрядные и 64-разрядные системы


В чем разница между 32-битными и 64-битными системами?

Если вы использовали их оба, какие резкие различия вы испытали?

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


219
2017-10-17 11:14


Источник


Здесь много недоумений, а также где в Интернете между физической адресацией (доступ к барану) PEA влияет на это, материнская плата влияет на это и логическая адресация (виртуальная память на процесс). На 32-битной виртуальной памяти ограничено 4 ГБ минус то, что резервирует ядро. Он не зависит от ОЗУ, у вас может быть 0,1 МБ или 8 ГБ ОЗУ, и у вас будет ровно 4 ГБ виртуальной памяти (но некоторые зарезервированы ядром). PEA может использоваться, чтобы иметь больше ОЗУ, но это не идеальный ответ, так как ядро ​​НЕ МОЖЕТ получить доступ ко всему. - ctrl-alt-delor


Ответы:


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

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

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

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

  • В 64-битном режиме имеется много других регистров центрального процессора. Регистры - это самая быстрая память в вашей системе. В 64-битном режиме есть только 8 в 32-битном режиме и 16 регистров общего назначения. В научных вычислительных приложениях, которые я написал, я видел повышение производительности на 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 было много проблем с драйверами. В наши дни все лучше.

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

  • Вы можете запускать 32-разрядные приложения (но не драйверы) в 64-разрядной Windows без проблем. Наихудшее замедление, которое я измерил для 32-битного приложения в 64-битной Windows, составляет около 5% (это означает, что если потребовалось 60 секунд, чтобы что-то сделать в 32-битной Windows, потребовалось не более 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).

  • Он не относится к размеру физической шины данных: это больше связано с издержками производства (количество контактов в гнезде CPU) и размерами строк в кеше.


262
2017-10-17 13:11



Очень хороший ответ. Тем более, что вы заметили, что на самом деле нет предела 4 ГБ оперативной памяти, но ограничение использования памяти процесса. Просто для вашей информации, я думаю, вы должны взглянуть на эту ссылку: unawave.de/windows-7-tipps/32-bit-ram-barrier.html?lang=EN - Breakthrough
Это приложения, которые не работают на 64-битных окнах: 16-разрядные приложения / те, которые используют 32-разрядные или неподписанные драйверы режима ядра. Это очень много для такого наркомана, как я ... - fluxtendu
@flextendu, учитывая требования к производительности этих старых программ, вы почти наверняка сможете запустить их на виртуальной машине. С VMware Player, Virtual PC и Virtual Box там нет причин не тестировать одну из них, если у вас есть 32-битная лицензия Windows. Если вы не хотите связываться с этим, они, вероятно, будут работать в режиме «Windows XP». - Mark Booth
BTW, 32-разрядные приложения не будут использовать больше 2 гигабайт ОЗУ, если в их манифесте не включен конкретный флаг. Источник: blogs.technet.com/b/markrussinovich/archive/2008/11/17/... - Hello71
Да, я уверен, что Hello71 поразил что-то довольно важное, что здесь не описано: большинство 32-разрядных приложений никогда не смогут напрямую использовать дополнительную оперативную память. Я думаю, это стоит упомянуть, нет? - Django Reinhardt


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

  1. ОЗУ на ОС: ОЗУ RAM 4 ГБ на x86 для ОС (большую часть времени)
  2. ОЗУ на процесс: Ограничение RAM 4GB на x86 для процессов (всегда). Если вы считаете, что это не важно, попробуйте запустить огромное приложение для работы с базами данных MSSQL. Он будет использовать> 4 ГБ, если у вас есть это и работает намного лучше.
  3. Адреса: Адреса - 64 бита вместо 32 бит, что позволяет вам иметь «большие» программы, которые используют больше памяти.
  4. Ручки доступны для программ: Вы можете создать больше дескрипторов файлов, процессов, ... Пример в Windows x64 вы можете создать> 2000 потоков для каждого процесса, но на x86 ближе к нескольким сотням.
  5. Доступны более широкие программы: С x64 вы можете запускать как x86, так и x64 программы. (Примеры окон: 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, вы можете получить более глубокий вид как это работает здесь,


107
2017-09-25 12:19



Um. IA64 запускает команды x86. Тем не менее, он не поддерживает расширения SSE. На Itanium имеется аппаратное обеспечение для запуска инструкций x86; это эмулятор, но в аппаратном обеспечении. - tzot
Несколько лет назад Раймонд Чен опубликовал о «потоке» в 2000 году, и это более или менее городская легенда: blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx - bk1e
Подтвердите для Arstechnica их объяснение. - Avihu Turzion
Предел оперативной памяти в 4 ГБ не совсем прав (это скорее искусственный предел для домашних пользователей Windows-систем), проверьте PAE, С большинством современных аппаратных средств ядро ​​Linux PAE (которое используется по умолчанию для 32-битного) может удовлетворять более 4 ГБ. То же самое относится к FreeBSD и NetBSD. - Izzy
32-битные системы не могут использовать более 4 ГБ (1-я пункция) из-за этих «адресов» (3-я пункция). Потому что самое высокое 32-битное число - 4,294,967,296 (= 4 ГБ). Таким образом, ваши 1-й и 3-й прыжки являются ТОЛЬКО. Вы можете удалить третий штраф. :) - Jet


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

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

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


46
2017-09-25 12:16



32-битная платформа и ограничение 4 ГБ являются некорректным и являются (главным образом) лимитом выбора архитектуры / дизайна операционной системы. Действительно, 4 ГБ с 32-битами действительно находится на пределе в пространстве VA процесса. Физический адрес поддерживает 36 бит на 32-разрядных процессорах Intel - Tall Jeff
Вы делаете хорошую точку, которая, безусловно, верна. Но влияние в реальном мире пользователей ПК заключается в том, что машина не будет использовать полный 4 ГБ, за которые они заплатили. У моего папы была эта проблема, и она все еще путается, что 4 ГБ, за которую он заплатил, не может быть полностью использован.
Цените свою точку зрения, но просто пытаетесь понять, что исправление не находится в процессоре или идет на 64-битные, это всего лишь немного улучшенный дизайн ОС. Это относится, например, к корпоративным версиям Windows даже в 32-разрядных версиях. Это позволяет использовать 64 ГБ оперативной памяти. - Tall Jeff
Технически, предел не исчезает. Он продвигается дальше туда, где нецелесообразно / невозможно установить столько RAM на машине в любое время в течение следующего десятилетия или около того.
См. Мое замечание о PAE выше: предел 4 ГБ не соответствует всей системе, но применяется только к отдельным процессам (ни один процесс не может получить доступ к 4 ГБ и самому себе), но вся система, т. е. все процессы вместе, может активировать PAE). Поэтому, если у вас нет приложений, которые получают прибыль от доступа к 4 ГБ и выше (например, видеоредакторы / конвертеры с большими видеофайлами) а также 8GB +, это не должно иметь большого значения, будь то 32-битный или 64-битный. - Izzy


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

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


31
2017-10-13 10:45



Этот ответ предполагает, что PowerPC64 не так хорош, как x86-64. Правда в том, что powerpc64 не улучшил powerpc, поскольку powerpc не был сломан. - ctrl-alt-delor
Linux теперь имеет x32 ABI, со всеми преимуществами скорости x86-64 (больше регистров, переработанный ABI), но с 32-битными указателями. +1, указав, что преимущества 64-битного режима не зависят от фактического увеличения ширины, а от возможности сбросить много багажа, который удерживал архитектуру. 64-битные регионы имеют ценность для некоторых приложений, но требуется меньше 64-битного пространства указателей. - Peter Cordes


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

От ChrisInEdmonton:

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


19
2017-10-17 11:24



Для ОС 32-разрядная и 64-разрядная ТОЛЬКО относится к размеру указателей (что правильно описывает ваш первый абзац). -1: Некоторые операционные системы предпочитают блокировать размер целого по умолчанию на размер указателя, но ни Windows, ни Linux не делают этого. Целочисленная математическая точность не изменяется. НЕТ широко используемая ОС изменяет точность с плавающей точкой (что утверждает второй абзац). «float» или «single» - 32-разрядный, «double» - 64-разрядный, независимо от того, использует ли ОС 32-разрядные или 64-разрядные указатели. - Mr Fooz
Ах, я был явно ошибаюсь, спасибо, что освободил это :) - Phoshi
Нет проблем. -1 -> +1 - Mr Fooz
Возможно, стоит отредактировать ваш ответ, чтобы указать, сколько оперативной памяти можно получить. 32-разрядная операционная система в системе ix86 с PAE может обслуживать до 64 ГБ ОЗУ. 64-разрядная операционная система на x86-64 может получить доступ к виртуальному адресному пространству до 256 ТБ, хотя это может быть увеличено в последующих процессорах, до 16 EB. Обратите внимание, что некоторые операционные системы дополнительно ограничивают адресное пространство, и большинство материнских плат будут иметь дополнительные ограничения. - ChrisInEdmonton
Я хотел, чтобы это было просто, поскольку цифры в основном достаточно высоко, чтобы в данный момент быть неактуальным, но теперь не может помешать им вставить их. - Phoshi


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

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

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

Основополагающая «большая сделка» на 64-битной основе заключается в том, что вы получаете доступ к гораздо большему пространству адресов памяти, чем 32 бит. Это означает, что вы действительно можете вставлять более 4 ГБ памяти в свой компьютер и на самом деле это имеет значение.

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

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


14
2017-09-25 12:29



Если вы пишете программы, которые небрежно предполагают, что определенные типы указателей имеют тот же размер, что и определенные интегральные типы, ур делает это заново. Это было верно в течение длительного времени. - David Thornley
@David: Ты абсолютно прав. К сожалению, есть тонна кода, который делает именно это.


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

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

man 3 sysctl

10
2017-09-25 12:34



error: "machdep.cpu.extfeatures" - неизвестный ключ
Думаю, это не называется EM64T, также, если вам не очень жаль, чтобы иметь intel.


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

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

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

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

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

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

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

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

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


9
2018-05-01 21:19





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

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


8
2017-09-25 12:36





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

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


7
2017-10-17 11:29



Больше регистров и переработанная ABI (передающая функция args в регистре) обычно составляет 10-15% ускорения, что довольно прилично. В настоящее время есть x32 Linux ABI с 32-битными указателями, но с использованием longd-режима amd64 и условных условных обозначений args-in-registers. Таким образом, у вас есть все преимущества amd64 в скорости, но без накладных расходов при необходимости 64 бит для каждого указателя. Это хорошо для всего, что не нуждается в 4 ГБ (виртуальной) памяти. - Peter Cordes