Мне известно о некоторых очевидных преимуществах архитектуры x64 (более высокие адресные адреса RAM и т.д.)... но:
x86-64 - это немного особый случай - для многих архитектур (например, SPARC) компиляция приложения для 64-битного режима не дает ему никакой пользы, если он не может с пользой использовать более 4 ГБ памяти. Все, что он делает, - это увеличить размер двоичного файла, который может сделать код более медленным, если он влияет на поведение кэша.
Однако x86-64 дает вам больше, чем просто 64-разрядное адресное пространство и 64-битные целочисленные регистры - он также удваивает количество регистров общего назначения, которые на архитектуре с недостатком регистра, например, x86 может привести к значительному увеличению производительности, просто перекомпилируя.
Он также позволяет компилятору предположить, что многие расширения, такие как SSE и SSE2, присутствуют, что также может значительно улучшить оптимизацию кода.
Другим преимуществом является то, что x86-64 добавляет относительную адресацию, которая может значительно упростить независимый от позиции код.
Однако, если приложение не чувствительно к производительности, то ничто из этого не имеет особого значения.
Одно из возможных преимуществ, о которых я еще не упоминал, заключается в том, что он может выявить скрытые ошибки. После того, как вы портируете его на 64-битный, выполняется ряд изменений. Размеры некоторых типов данных изменяются, изменяется соглашение о вызове, изменяется механизм обработки исключений (по крайней мере, в Windows).
Все это может привести к тому, что скрытые ошибки будут всплывать, что означает, что вы можете их исправить.
Предполагая, что ваш код правильный и без ошибок, портирование на 64-битное должно теоретически быть таким же простым, как щелчок переключателя компилятора. Если это не удается, это потому, что вы полагаетесь на вещи, которые не гарантируются языком, и поэтому они являются потенциальными источниками ошибок.
Здесь 64-бит для вас:
Я портировал несколько приложений на С++ и видел примерно 10% -ное ускорение с 64-битным кодом (одна и та же система, тот же самый компилятор, единственное изменение было 32-разрядным и 64-битным режимом компилятора), но большая часть эти приложения занимали довольно много 64-битной математики. YMMV.
Я бы не стал беспокоиться о том, что 32-разрядная поддержка уходит в ближайшее время.
(Отредактировано для включения заметок из комментариев - спасибо!)
Хотя верно, что 32-разрядная версия будет существовать некоторое время в той или иной форме, Windows Server 2008 R2 поставляется только с 64-разрядным SKU. Я бы не удивился, увидев WOW64 в качестве опции установки уже в Windows 8, поскольку большее количество программного обеспечения переносится на 64-разрядный. WOW64 - это накладные расходы на установку, память и производительность. Предел оперативной памяти в 3,5 ГБ в 32-битной Windows вместе с увеличением плотности RAM будет способствовать этой миграции. Я бы предпочел иметь больше оперативной памяти, чем процессор...
Объявите 64-бит! Потратьте время, чтобы ваш 32-разрядный код совместим с 64-разрядными версиями, без проблем и просто. Для нормальных приложений изменения более точно описываются как корректировки кода. Для водителей выбор: адаптировать или потерять пользователей. Когда придет время, вы будете готовы к развертыванию на любой платформе с перекомпиляцией.
IMO текущие проблемы, связанные с кешем, являются спорными; кремниевые улучшения в этой области и последующая 64-битная оптимизация.
Сообщение Rico Mariani о том, почему Microsoft не переносит Visual Studio на 64-разрядный, действительно суммирует его Visual Studio: почему нет 64-битной версии? (Еще)
Это зависит от того, является ли ваш код приложением или библиотекой многократного использования. Для библиотеки имейте в виду, что клиент этой библиотеки может иметь веские основания для запуска в 64-битном режиме, поэтому вы должны убедиться, что ваш сценарий работает. Это может также применяться к приложениям, когда они расширяемы через плагины.
Если у вас нет настоящей потребности сейчас и, вероятно, никогда не будет, для 64-битного режима вам не следует выполнять перенос.
Если у вас нет необходимости сейчас, но может быть, когда-нибудь, вы должны попытаться оценить, сколько усилий это будет (например, включив все соответствующие предупреждения компилятора и попытку 64-битной компиляции). Ожидайте, что некоторые вещи не являются тривиальными, поэтому будет полезно узнать, как проблемы, с которыми вы, вероятно, столкнетесь, и как долго это может потребоваться для их исправления.
Обратите внимание, что из-за зависимостей может возникнуть необходимость: если ваша программа является библиотекой (например, DLL), может потребоваться перенос ее в 64-разрядный режим только из-за того, что некоторые хост-приложения будут перенесены.
В обозримом будущем поддерживаются 32-разрядные приложения.
Если нет деловых причин идти на 64 бит, тогда нет реальной "необходимости" для поддержки 64-битного.
Однако есть некоторые веские причины для перехода на 64 бит в какой-то момент, кроме всех тех, о которых уже говорили другие.
Сложнее покупать компьютеры, которые не являются 64-битными. Несмотря на то, что 32-разрядные приложения будут работать в режиме совместимости на долгие годы, любые новые ПК, продаваемые сегодня или в будущем, скорее всего, будут 64 бит. Если у меня есть блестящая 64-разрядная операционная система, я действительно не хочу запускать "вонючие старые 32-разрядные приложения" в режиме совместимости!
Некоторые вещи просто не работают должным образом в режиме совместимости - это не то же самое, что работать в 32-разрядной ОС на 32-разрядном оборудовании. Я столкнулся с несколькими проблемами (например, доступ к реестру через кусты реестра 32/64 бит, программы, которые терпят неудачу, потому что они не находятся в папке, в которой они ожидают, и т.д.) При работе в режиме совместимости. Я всегда нервничаю в том, что запускаю свой код в режиме совместимости - это просто "не настоящая вещь", и он часто показывает.
Если вы написали свой код в чистоте, то скорее всего вам придется перекомпилировать его как 64-битный exe, и он будет работать нормально, поэтому нет реальной причины не попробовать.
Чем раньше вы создадите собственную 64-разрядную версию, тем проще будет ее работать на 64-битном при добавлении новых функций. Это гораздо лучший план, чем продолжение развития в темные века в течение других "n" лет, а затем попытка выпрыгнуть в свет.
Когда вы приступите к следующему собеседованию, вы сможете сказать, что у вас есть 64-разрядная экспансия и 32- > 64-портовый опыт.
Вы уже знаете о преимуществах x64 (что особенно важно для увеличения размера ОЗУ), и вы не заинтересованы в них, а затем не переносите исполняемый файл (exe). Обычно производительность ухудшается после порта, в основном из-за увеличения размера модуля x64 поверх x86: теперь все указатели требуют двойной длины, и это происходит везде, включая размер кода (некоторые переходы, вызовы функций, vtables, виртуальные вызовы, глобальные символы и т.д.). Не является значительной деградацией, но обычно измеряется (уменьшение скорости на 3-5%, зависит от многих факторов).
DLL стоит портировать, потому что вы получаете новую "аудиторию" в x64-приложениях, которые могут потреблять вашу DLL.
Например, если вы написали 32-битный код (GNU C/++), как показано ниже EDIT: формат кода
struct packet {
unsigned long name_id;
unsigned short age;
};
для сетевого обмена сообщениями, вам необходимо выполнить перенос при повторной компиляции в 64-битной системе, из-за htonl/ntohl и т.д., связь сломается в случае, когда сетевой одноранговый узел все еще использует 32-битную систему (используя тот же код, что и ваш); вы знаете, что sizeof (long) будет изменен с 32 до 64 тоже на вашей стороне.
Подробнее о переносе 32/64 на http://code.google.com/p/effocore/downloads/list, имя документа EffoCoreRef.pdf.
Некоторые ОС или конфигурации не могут запускать 32-разрядные программы. Минимальный Linux без 32-разрядного libc установлен, например. Также IIRC я обычно скомпилировал 32-битную поддержку ядра.
Если эти ОС или конфигурации являются частью вашей потенциальной базы пользователей, тогда да, вы должны ее портировать.
Если вам требуется больше скорости, вам также следует его портировать (как говорили другие, x86-64 имеет больше регистров и классных инструкций, которые ускоряют его).
Или, конечно, если вы хотите, чтобы mmap() или иначе отображали большой файл или много памяти. Тогда 64-бит помогает.
Очень маловероятно, что вы увидите какую-либо выгоду, если вам не нужны экстремальные меры безопасности или непристойные объемы ОЗУ.
В принципе, вы, скорее всего, знаете интуитивно, если бы ваш код был хорошим кандидатом для 64-битного переноса.
Относительно сроков. Я бы не стал беспокоиться, такие вещи, как 32bit, будут вокруг хорошо, но изначально и в обозримом будущем в какой-то другой форме.
См. мой ответ на этот вопрос здесь. Я закрыл это сообщение, в котором говорится, что 64-разрядный компьютер может хранить и получать гораздо больше информации, чем 32-разрядный компьютер, Для большинства пользователей это на самом деле не означает многого, потому что такие вещи, как просмотр в Интернете, проверка электронной почты и воспроизведение Solitaire, работают с комфортом в пределах 32-битной адресации. Там, где 64-битная выгода будет действительно сиять, в тех областях, где у вас много данных, которые компьютер должен будет опрокинуть. Цифровая обработка сигналов, гигапиксельная съемка и продвинутые 3D-игры - все это области, где их огромное количество обработки данных будет иметь большой импульс в 64-битной среде.
Что касается вашего кода, работающего быстрее/лучше, это полностью зависит от вашего кода и требований, предъявляемых к нему.
Что касается проблем с производительностью, это зависит от вашей программы. Если ваша программа интенсивно ориентирована на указатель, перенос на 64-разрядный может привести к снижению производительности, поскольку для кэша CPU с одинаковым размером каждый 64-разрядный указатель занимает больше места в кеше, а сопоставления между виртуальными и физическими также занимают больше пространства TLB, В противном случае, если ваша программа не является интенсивной с указателем, ее производительность выиграет от x64.
Конечно, производительность не единственная причина для переноса, другие проблемы, такие как перенос усилий, планирование времени также должны быть рассмотрены.
Я бы порекомендовал переносить его на 64-разрядный, так что вы запускаете "native" (также я использую OpenBSD. В своем порту AMD64 они не поддерживают 32-разрядную поддержку эмуляции, все должно быть 64 бит)
Кроме того, stdint.h - ваш лучший друг! Портируя свое приложение, вы должны научиться правильно переносить код. Что сделает ваш код работать правильно, когда у нас есть 128-битные процессоры (через несколько десятилетий, надеюсь)
Я портировал 2 или 3 вещи на 64 бит и теперь разрабатываю для них (что очень просто, если вы используете stdint.h), и при первом переносе проекта на 64 бит, вызвавшем появление 2 или 3 ошибок, но это все. Большая часть из них была простой перекомпиляцией, и теперь я не беспокоюсь о различиях между 32 и 64 бит при создании нового кода, потому что я просто автоматически сопоставляю порт. (используя intptr_t и size_t и т.д.)
В случае, когда dll вызывается из 64-битного процесса, DLL также должна быть 64 бита. Тогда неважно, стоит ли это, у вас просто нет выбора.
Одна из проблем, о которой следует помнить, - это доступные библиотеки программного обеспечения. Например, моя компания разрабатывает приложение, которое использует несколько библиотек OpenGL, и мы делаем это на ОС OpenSuSE. В более старых версиях ОС можно было загрузить 32-разрядные версии этих библиотек в архитектуре x86_64. Однако в новых версиях этого нет. Это упростило компиляцию в 64-битном режиме.
64 бит будет работать намного быстрее, когда 64-битные компиляторы станут зрелыми, но когда это произойдет, я не знаю