Полагаю, я сосредотачиваюсь на x86, но в целом меня интересует переход с 32 на 64 бит.
Логически я вижу, что константы и указатели в некоторых случаях будут больше, поэтому программы, вероятно, будут больше. И желание выделить память на границах слов для эффективности означало бы больше пустого пространства между выделениями.
Я также слышал, что 32-битный режим на x86 должен очищать свой кеш при переключении контекста из-за возможного перекрытия адресных пространств 4G.
Итак, каковы реальные преимущества 64-битной версии?
И как дополнительный вопрос, будет ли 128 бит еще лучше?
Редактировать:
Я только что написал свою первую 32/64 битную программу. Он создает связанные списки / деревья из 16-байтовых (32-битная версия) или 32-байтовых (64-битная версия) объектов и много печатает в stderr - не очень полезная программа и не что-то типичное, но это моя первая.
Размер: 81128 (32b) v 83672 (64b) - так что особой разницы
Скорость: 17 с (32b) v 24s (64b) - работает на 32-битной ОС (OS-X 10.5.8)
Обновить:
Отмечу, что разрабатывается новый гибридный x32 ABI (Application Binary Interface), который имеет размер 64b, но использует указатели 32b. Для некоторых тестов это приводит к меньшему размеру кода и более быстрому выполнению, чем 32b или 64b.
источник
Ответы:
Если вам не нужен доступ к большему объему памяти, чем позволяет адресация 32b, преимущества будут небольшими, если вообще будут.
При работе на процессоре 64b вы получаете один и тот же интерфейс памяти независимо от того, используете ли вы код 32b или 64b (вы используете тот же кеш и ту же шину).
Хотя архитектура x64 имеет несколько дополнительных регистров, что позволяет упростить оптимизацию, этому часто противодействует тот факт, что указатели теперь стали больше, а использование любых структур с указателями приводит к увеличению трафика памяти. Я бы оценил увеличение общего использования памяти для 64-битного приложения по сравнению с 32-битным примерно на 15-30%.
источник
Обычно я наблюдаю увеличение скорости на 30% для кода с интенсивными вычислениями на x86-64 по сравнению с x86. Скорее всего, это связано с тем, что у нас есть 16 x 64-битных регистров общего назначения и 16 x SSE-регистров вместо 8 x 32-битных регистров общего назначения и 8 x SSE-регистров. Это с компилятором Intel ICC (11.1) на x86-64 Linux - результаты с другими компиляторами (например, gcc) или с другими операционными системами (например, Windows), конечно, могут отличаться.
источник
Независимо от преимуществ, я бы посоветовал вам всегда компилировать свою программу для размера слова системы по умолчанию (32-битного или 64-битного), поскольку если вы скомпилируете библиотеку как 32-битный двоичный файл и предоставите ее на 64-битной system, вы заставите любого, кто хочет установить связь с вашей библиотекой, предоставить свою библиотеку (и любые другие зависимости библиотеки) в виде 32-битного двоичного файла, если по умолчанию доступна 64-битная версия. Это может доставлять неудобства каждому. В случае сомнений предоставьте обе версии своей библиотеки.
Что касается практических преимуществ 64-битной версии ... наиболее очевидным является то, что вы получаете большее адресное пространство, поэтому, если вы используете mmap файл, вы можете адресовать его больше за раз (и загружать большие файлы в память). Еще одно преимущество заключается в том, что при условии, что компилятор хорошо справляется с оптимизацией, многие из ваших арифметических операций могут быть распараллелены (например, размещение двух пар 32-битных чисел в двух регистрах и выполнение двух сложений за одну операцию сложения) и большие вычисления чисел будут выполняться быстрее. Тем не менее, все 64-битные и 32-битные вещи вообще не помогут вам с асимптотической сложностью, поэтому, если вы хотите оптимизировать свой код, вам, вероятно, следует смотреть на алгоритмы, а не на такие постоянные факторы, как этот.
РЕДАКТИРОВАТЬ : не
обращайте внимания на мое заявление о параллельном добавлении. Это не выполняется обычным оператором добавления ... Я запутал это с некоторыми из векторизованных инструкций / SSE. Более точным преимуществом, помимо большего адресного пространства, является наличие регистров общего назначения, что означает, что в файле регистров ЦП можно поддерживать большее количество локальных переменных, что намного быстрее, чем если бы вы поместили переменные в программный стек (что обычно означает выход в кеш L1).
источник
В дополнение к большему количеству регистров 64-разрядная версия по умолчанию имеет SSE2. Это означает, что вы действительно можете выполнять некоторые вычисления параллельно. У расширений SSE были и другие плюсы. Но я думаю, что главное преимущество - это отсутствие необходимости проверять наличие расширений. Если это x64, у него есть SSE2. ... Если мне не изменяет память.
источник
Я кодирую шахматный движок под названием foolsmate . Наилучшее извлечение ходов с использованием поиска по дереву на основе минимакса до глубины 9 (из определенной позиции) заняло:
по
Win32
комплектации: ~17.0s
;после перехода в
x64
конфигурацию: ~10.3s
;Это 41% разгона!
источник
Единственным оправданием для перехода вашего приложения на 64-разрядную версию является необходимость увеличения памяти в таких приложениях, как большие базы данных или приложения ERP с как минимум сотнями одновременных пользователей, где ограничение в 2 ГБ будет превышено довольно быстро, когда приложения кэшируют для повышения производительности. Это особенно важно в ОС Windows, где integer и long по-прежнему 32-битные (у них есть новая переменная _int64. Только указатели 64-битные. На самом деле WOW64 сильно оптимизирован для Windows x64, поэтому 32-битные приложения работают с низкими потерями в 64-битной Windows ОС. Мой опыт работы с Windows x64 - это 32-разрядная версия приложения, работающая на 10-15% быстрее, чем 64-разрядная, так как в первом случае, по крайней мере, для баз данных с проприетарной памятью вы можете использовать арифметику указателей для поддержки b-дерева (наиболее загруженная процессор часть систем баз данных) . Приложения с интенсивными вычислениями, требующие больших десятичных знаков для наивысшей точности, не обеспечиваемой двойным числом в 32-64-битной операционной системе. Эти приложения могут использовать _int64 изначально вместо программной эмуляции. Конечно, большие дисковые базы данных также улучшатся по сравнению с 32-битными просто из-за возможности использования большой памяти для кэширования планов запросов и так далее.
источник
int
везде остается 32-битным, независимо от размера слова среды выполнения. Для чего компиляторlong
остается 32-битным при компиляции для 64-битного? Вы утверждаете, что это делает MSVC? AFAIK, это даже [примерно] покрыто стандартом C ++ 11:sizeof(long) == sizeof(void*)
пожалуйста, кто-нибудь, поправьте меня, если я ошибаюсь, поскольку у меня нет легкого доступа к MSVC.Больше данных передается между ЦП и ОЗУ при каждой выборке из памяти (64 бита вместо 32), поэтому 64-битные программы могут быть быстрее, если они написаны так, чтобы правильно использовать это преимущество.
источник
В конкретном случае от x68 до x68_64 64-разрядная программа будет примерно того же размера, если не немного меньше, будет использовать немного больше памяти и работать быстрее. В основном это связано с тем, что x86_64 имеет не только 64-битные регистры, но и вдвое больше. x86 не имеет достаточного количества регистров, чтобы сделать компилируемые языки настолько эффективными, насколько они могли бы быть, поэтому код x86 тратит много инструкций и пропускную способность памяти, перемещая данные туда и обратно между регистрами и памятью. В x86_64 этого намного меньше, поэтому он занимает немного меньше места и работает быстрее. Инструкции с плавающей запятой и векторными командами с изменением битов также намного эффективнее в x86_64.
В целом, однако, 64-битный код не обязательно быстрее и обычно больше как для кода, так и для использования памяти во время выполнения.
источник
Любые приложения, требующие использования ЦП, такие как транскодирование, отображение и рендеринг мультимедиа, будь то аудио или видео, безусловно, потребуют (на данном этапе) и выиграют от использования 64-битного вместо 32-битного из-за способности ЦП справляться с простыми задачами. количество данных, брошенных на него. Это не столько вопрос адресного пространства, сколько способ обработки данных. 64-битный процессор с 64-битным кодом будет работать лучше, особенно с математически сложными вещами, такими как транскодирование и данные VoIP - фактически, любые «математические» приложения должны выиграть от использования 64-битных процессоров и операционных систем. Докажи, что я неправ.
источник