64-битные программы больше и быстрее 32-битных версий?


85

Полагаю, я сосредотачиваюсь на 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.

https://sites.google.com/site/x32abi/


1
Похоже на дубликат stackoverflow.com/questions/324015/…
Suma

1
И мой, сделанный несколько дней назад: stackoverflow.com/questions/2334148/…
Mr. Boy,

Я согласен, что есть некоторые совпадения, но пока нет кеш-памяти процессора и 128-битных частей. Спасибо Suma и John за ссылки.
philcolbourn


«Я также слышал, что 32-битный режим на x86 должен очищать свой кеш при переключении контекста из-за возможного перекрытия адресных пространств 4G». Не могли бы вы указать мне ссылку, в которой говорится об этом?
gkb0986 05

Ответы:


30

Если вам не нужен доступ к большему объему памяти, чем позволяет адресация 32b, преимущества будут небольшими, если вообще будут.

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

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


2
Каково ваше мнение о предлагаемом x32 ABI?
philcolbourn

Я думаю, что memcpy и strcpy будут быстрее, чем 32-битный процессор, потому что он будет читать по одному слову каждый раз, поскольку слово составляет 8 байт на 64-битном процессоре
Марк Ма

43

Обычно я наблюдаю увеличение скорости на 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), конечно, могут отличаться.


1
Под «интенсивными вычислениями» вы подразумеваете графику, матрицу, ДПФ?
philcolbourn

4
@phil: да, в основном обработка изображений, в основном целочисленные (с фиксированной точкой), много кода SIMD и т. д.
Пол Р

Я заметил, что 64-битные компиляторы используют регистры SSE, а 32-битные компиляторы используют стандартный ALU. Это ускоряет работу 64-битного кода за счет более узкой ширины FP (64 против 80) и дополнительных инструкций.
IamIC

16

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

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

РЕДАКТИРОВАТЬ : не
обращайте внимания на мое заявление о параллельном добавлении. Это не выполняется обычным оператором добавления ... Я запутал это с некоторыми из векторизованных инструкций / SSE. Более точным преимуществом, помимо большего адресного пространства, является наличие регистров общего назначения, что означает, что в файле регистров ЦП можно поддерживать большее количество локальных переменных, что намного быстрее, чем если бы вы поместили переменные в программный стек (что обычно означает выход в кеш L1).


> «например, размещение двух пар 32-битных чисел в двух регистрах и выполнение двух сложений за одну операцию сложения» Есть ли какой-нибудь компилятор, выполняющий это? Кроме того, похоже, что то же самое можно сделать на x86 с использованием инструкций SSE.
Suma

Думать о таком «добавлении двух в одном» больше, это ерунда, и ни один компилятор не может сделать это в качестве оптимизации, потому что добавление из более низких 32b может перетекать в более высокие 32b. Для этого вам потребуются инструкции SIMD.
Suma

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

«Постоянные факторы» - похоже на то, что сказал бы Брайан Харви.
philcolbourn

5

В дополнение к большему количеству регистров 64-разрядная версия по умолчанию имеет SSE2. Это означает, что вы действительно можете выполнять некоторые вычисления параллельно. У расширений SSE были и другие плюсы. Но я думаю, что главное преимущество - это отсутствие необходимости проверять наличие расширений. Если это x64, у него есть SSE2. ... Если мне не изменяет память.


4

Я кодирую шахматный движок под названием foolsmate . Наилучшее извлечение ходов с использованием поиска по дереву на основе минимакса до глубины 9 (из определенной позиции) заняло:

по Win32комплектации: ~ 17.0s;

после перехода в x64конфигурацию: ~ 10.3s;

Это 41% разгона!


2

Единственным оправданием для перехода вашего приложения на 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.
Мэтью Холл

3
@Matthew Hall: Его стандарт 64-битной операционной системы Windows и, следовательно, MSVC следует этой модели LLP64 (против LP64 для вариантов Unix). Обратитесь ( msdn.microsoft.com/en-us/library/3b2e7499(v=vs.100).aspx ).
GirishK 02

1

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


11
На самом деле это не так: шина памяти имеет любую ширину, которая не имеет принципиального отношения к ширине регистров процессора. Некоторые 32-битные системы выбирают 128 бит за раз, есть 64-битные системы, которые выбирают 32 за раз, и даже 32-битные системы, которые извлекают память не более 8 бит за раз.
Эндрю МакГрегор,

Хорошо, я не знал об этом - тем не менее, разве не правильно, что одна инструкция mov передает 64 бита на 64-битном процессоре и 32 бита на 32-битном процессоре? Итак, при копировании большого объема памяти из точки A в точку B это, по крайней мере, будет означать, что на 64-битном процессоре потребуется выполнять меньше инструкций mov (даже если шина памяти является узким местом)?
Rune Aamodt,

2
При перемещении большого объема памяти вы будете использовать инструкции 128b SIMD как на x86, так и на x64.
Suma

Что именно есть «64-битные системы, которые загружают по 32 за раз»? Назовите несколько. Если да, то действительно ли это «64-битные системы»?
Johnny

1

В конкретном случае от x68 до x68_64 64-разрядная программа будет примерно того же размера, если не немного меньше, будет использовать немного больше памяти и работать быстрее. В основном это связано с тем, что x86_64 имеет не только 64-битные регистры, но и вдвое больше. x86 не имеет достаточного количества регистров, чтобы сделать компилируемые языки настолько эффективными, насколько они могли бы быть, поэтому код x86 тратит много инструкций и пропускную способность памяти, перемещая данные туда и обратно между регистрами и памятью. В x86_64 этого намного меньше, поэтому он занимает немного меньше места и работает быстрее. Инструкции с плавающей запятой и векторными командами с изменением битов также намного эффективнее в x86_64.

В целом, однако, 64-битный код не обязательно быстрее и обычно больше как для кода, так и для использования памяти во время выполнения.


2
Я не совсем понимаю, о чем вы говорите. Изначально (первое предложение) вы говорите, что 64-битные программы обычно работают быстрее, но затем ваше последнее предложение, кажется, отбрасывает все, что говорит «не совсем»
СН

1

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


Нет. Не будет. Если потребность в ОЗУ превышает 4 ГБ, только это будет быстрее. Вы можете легко выполнить поиск в целочисленном массиве 1000Millions менее чем в 4 ГБ данных в 32-битной архитектуре. Таким образом, использование 64-битной машины здесь замедлится
sapy
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.