64-битные программы больше и быстрее 32-битных версий?
Я полагаю, что фокусируюсь на x86, но в целом меня интересует переход с 32 на 64 бит.
Логически я вижу, что константы и указатели в некоторых случаях будут больше, поэтому программы, вероятно, будут больше. И желание распределять память по границам слов для эффективности означало бы больше пробелов между распределениями.
Я также слышал, что 32-битный режим на x86 должен очищать свой кэш при переключении контекста из-за возможного перекрытия адресных пространств 4G.
Итак, каковы реальные преимущества 64 бит?
И в качестве дополнительного вопроса, 128 бит будет еще лучше?
Редактировать:
Я только что написал свою первую 32/64 битную программу. Он создает связанные списки / деревья из 16-байтовых (32-битная версия) или 32-байтовых (64-битная версия) объектов и много печатает в stderr - не очень полезная программа и не что-то типичное, но это мой первый.
Размер: 81128(32b) v 83672(64 b) - так что нет большой разницы
Скорость: 17 с (32b) v 24 с (64 b) - работает на 32-битной ОС (OS-X 10.5.8)
Обновить:
Я отмечаю, что разрабатывается новый гибридный xI ABI (Application Binary Interface), который является 64 b, но использует указатели 32b. Для некоторых тестов это приводит к меньшему коду и быстрому выполнению, чем 32b или 64 b.
10 ответов
Если вам не требуется доступ к большему объему памяти, который позволит вам использовать адресация 32b, преимущества будут незначительными, если таковые имеются.
При работе на 64-битном процессоре вы получаете один и тот же интерфейс памяти, независимо от того, используете ли вы 32-битный или 64-битный код (вы используете тот же кеш и ту же шину).
В то время как архитектура x64 имеет несколько больше регистров, что позволяет упростить оптимизацию, этому часто противодействует тот факт, что указатели теперь больше и использование любых структур с указателями приводит к увеличению трафика в памяти. Я бы оценил увеличение общего объема используемой памяти для приложения 64b по сравнению с 32b примерно на 15-30 %.
Я обычно вижу улучшение скорости на 30% для кода с интенсивными вычислениями на x86-64 по сравнению с x86. Это, скорее всего, связано с тем, что у нас есть 16 x 64-битных регистров общего назначения и 16 x SSE регистров вместо 8 x 32-битных регистров общего назначения и 8 x SSE регистров. Это с компилятором Intel ICC (11.1) на Linux x86-64 - результаты с другими компиляторами (например, gcc) или с другими операционными системами (например, Windows), конечно, могут отличаться.
Независимо от преимуществ, я бы предложил, чтобы вы всегда компилировали свою программу для размера слова системы по умолчанию (32-битного или 64-битного), поскольку, если вы компилируете библиотеку как 32-битный двоичный файл и предоставляете ее на 64-битном Система, вы заставите любого, кто хочет соединиться с вашей библиотекой, предоставить свою библиотеку (и любые другие библиотечные зависимости) в виде 32-битного двоичного файла, когда 64-битная версия доступна по умолчанию. Это может быть довольно неприятно для всех. В случае сомнений предоставьте обе версии вашей библиотеки.
Что касается практических преимуществ 64-битного... наиболее очевидным является то, что вы получаете большее адресное пространство, поэтому, если mmap файл, вы можете обратиться к большему количеству его сразу (и загрузить большие файлы в память). Другое преимущество состоит в том, что, если компилятор хорошо выполнит оптимизацию, многие из ваших арифметических операций могут быть распараллелены (например, поместив две пары 32-битных чисел в два регистра и выполнив два сложения в одной операции сложения), и большие вычисления чисел будут выполняться быстрее. Тем не менее, целые 64-битные и 32-битные компоненты вообще не помогут вам с асимптотической сложностью, поэтому, если вы хотите оптимизировать свой код, вам, вероятно, следует обратить внимание на алгоритмы, а не на постоянные факторы, подобные этому.
РЕДАКТИРОВАТЬ:
Пожалуйста, не обращайте внимания на мое утверждение о параллельном сложении. Это не выполняется обычным оператором add... Я путал это с некоторыми векторизованными инструкциями /SSE. Более точное преимущество, помимо большего адресного пространства, состоит в том, что существует больше регистров общего назначения, что означает, что в регистровом файле ЦП может поддерживаться больше локальных переменных, что гораздо быстрее, чем если вы поместите переменные в программный стек (что обычно означает выход в кэш L1).
В дополнение к наличию большего количества регистров, 64-битный имеет SSE2 по умолчанию. Это означает, что вы действительно можете выполнять некоторые вычисления параллельно. У расширений SSE были и другие плюсы. Но я полагаю, что главное преимущество не в том, чтобы проверять наличие расширений. Если это x64, у него есть доступный SSE2.... Если память мне не изменяет
Единственным оправданием для переноса вашего приложения на 64-битную является потребность в большем объеме памяти в приложениях, таких как большие базы данных или приложения ERP, по крайней мере, с сотнями одновременных пользователей, где предел 2 ГБ будет превышен довольно быстро, когда приложения кешируют для повышения производительности. Это особенно касается ОС Windows, где целое и длинное все еще 32-разрядные (у них есть новая переменная _int64. Только 64-разрядные указатели. Фактически WOW64 высоко оптимизирован в Windows x64, так что 32-разрядные приложения работают с низким штрафом в 64-разрядной Windows ОС. Мой опыт работы с Windows x64 состоит в том, что 32-битная версия приложения работает на 10-15% быстрее, чем 64-битная, поскольку в первом случае, по крайней мере, для проприетарных баз данных памяти вы можете использовать арифметику указателей для поддержки b-дерева (наиболее ресурсоемкая часть систем баз данных) Приложения, требующие большого объема вычислений, которым требуются большие десятичные дроби для обеспечения максимальной точности, которая не обеспечивается двойной на 32-64-битной операционной системе. Эти приложения могут использовать _int64 вместо естественной эмуляции программного обеспечения. Конечно, большие дисковые базы данных также продемонстрируют улучшение по сравнению с 32-битными просто возможность использовать большую память для кэширования планов запросов и так далее.
В конкретном случае с x68 по x68_64 64-битная программа будет примерно того же размера, если не чуть меньше, будет использовать немного больше памяти и работать быстрее. В основном это связано с тем, что x86_64 не только имеет 64-битные регистры, но и вдвое больше. В x86 недостаточно регистров, чтобы сделать скомпилированные языки настолько эффективными, насколько они могли бы быть, поэтому код x86 тратит много инструкций и пропускную способность памяти, перемещая данные назад и вперед между регистрами и памятью. x86_64 имеет гораздо меньше, поэтому занимает немного меньше места и работает быстрее. Инструкции с плавающей точкой и вектором с битами также намного эффективнее в x86_64.
В целом, однако, 64-битный код не обязательно немного быстрее и обычно больше как для кода, так и для использования памяти во время выполнения.
Больше данных передается между ЦП и ОЗУ для каждой выборки памяти (64 бита вместо 32), поэтому 64-битные программы могут быть быстрее при условии их написания, чтобы они должным образом воспользовались этим.
Любые приложения, которые требуют использования ЦП, такие как транскодирование, производительность отображения и рендеринг мультимедиа, будь то аудио или визуальное, безусловно, потребуют (на данный момент) и выиграют от использования 64-битных по сравнению с 32-битными из-за способности ЦП иметь дело с чистой количество данных, брошенных на это. Это не столько вопрос адресного пространства, сколько способ обработки данных. 64-битный процессор с 64-битным кодом будет работать лучше, особенно с такими математически сложными вещами, как транскодирование и данные VoIP - на самом деле, любые математические приложения должны выиграть от использования 64-битных процессоров и операционных систем. Докажи, что я неправ.
На моей машине такое же кодирование h265 работает почти в два раза быстрее, используя virtulDub_x64 (с библиотекой x64 h265) по сравнению с virtulDub_x32 (обычная библиотека x32 h265). Вероятно, это связано с тем, что операции с длинными (64-битными) числами (т. е.: добавление) могут выполняться с одной инструкцией на x64, но на 32-битной требуется две: добавить младшую часть, а затем добавить (с переносом) старшую часть. Таким образом, если целочисленная математика не ограничена 32-битными целыми числами, большая часть из них займет больше времени под x32.