Портирование C++ на 32 бита кодирует к 64 битам - действительно ли это стоит того? Почему?

См. Мой ответ на этот вопрос здесь. Я закрыл этот пост, сказав, что 64-разрядный компьютер может хранить и извлекать гораздо больше информации, чем 32-разрядный компьютер. Для большинства пользователей это на самом деле мало что значит, потому что такие вещи, как просмотр веб-страниц, проверка электронной почты и игра в пасьянс - все это удобно в рамках 32-битной адресации. Преимущество 64-разрядной версии действительно проявляется в областях, где у вас есть много данных, которые компьютер должен будет обработать. Цифровая обработка сигналов, гигапиксельная фотография и продвинутые 3D-игры - все это области, в которых обработка их огромных объемов данных будет значительно увеличена в 64-битной среде.

Что касается вашего кода, работающего быстрее / лучше, это полностью зависит от вашего кода и предъявляемые к нему требования.

По поводу сроков. Я бы не беспокоился, такие вещи, как 32-битная версия, будут существовать некоторое время изначально и в обозримом будущем в какой-то другой форме.

Маловероятно, что вы заметите какую-либо пользу, если только вам не понадобятся крайние меры безопасности или неприличное количество оперативной памяти.

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

Вы уже знаете о преимуществах x64 (в первую очередь, увеличенный размер ОЗУ), и они вас не интересуют, тогда не переносите исполняемый файл (exe). Обычно производительность снижается после порта, в основном из-за увеличения размера модуля x64 по сравнению с x86: теперь все указатели требуют двойной длины, и это распространяется повсюду, включая размер кода (некоторые переходы, вызовы функций, vtables, виртуальные вызовы, глобальные символы и т. д.). Это незначительное ухудшение, но обычно поддается измерению (снижение скорости на 3-5%, зависит от многих факторов).

DLL стоит переносить, потому что вы получаете новую «аудиторию» в приложениях x64, которые могут использовать вашу DLL.

Если нет бизнес-причины для перехода на 64-разрядную версию, тогда нет реальной «необходимости» в поддержке 64-разрядной версии.

Однако есть кое-что хорошее причины для перехода на 64-битную версию в какой-то момент, помимо тех, о которых другие уже упоминали.

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

• Некоторые вещи просто не работают должным образом в режиме совместимости - это не то же самое, что запуск в 32-битной ОС на 32-битном оборудовании. Я столкнулся с несколькими проблемами (например, с доступом к реестру через 32/64 битные кусты реестра, программы, которые не работают, потому что они не находятся в папке, в которой они ожидают быть, и т. Д.) При работе в режиме совместимости. Я всегда нервничаю из-за запуска моего кода в режиме совместимости - это просто «не настоящая вещь», и это часто проявляется.

• Если вы написали свой код чисто, то, скорее всего, вам нужно только перекомпилировать его как 64-битный exe, и он будет работать нормально, поэтому нет реальной причины не попробовать.

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

• Когда вы пойдете на следующее собеседование, вы сможете сказать, что у вас есть 64-битный опыт и опыт переноса 32-> 64.

Это зависит от того, является ли ваш код приложением или многоразовой библиотекой. Что касается библиотеки, имейте в виду, что у клиента этой библиотеки могут быть веские причины для работы в 64-битном режиме, поэтому вы должны убедиться, что ваш сценарий работает. Это также может относиться к приложениям, если они расширяются через плагины.

1. Если вашей программе нет необходимости работать в 64-разрядной версии, зачем вам это? Если вы не ограничены памятью и у вас нет огромных наборов данных, в этом нет смысла. У новой Miata нет больших шин, потому что они ей не НУЖНЫ.
2. 32-битная поддержка (даже если только через эмуляцию) уйдет в прошлое, когда ваше программное обеспечение перестанет быть полезным. Мы по-прежнему эмулируем Atari 2600, не так ли?
3. Нет, по всей вероятности, ваше приложение будет работать медленнее в 64-битном режиме просто потому, что его меньше будет помещаться в кэш процессора. Это может быть немного безопаснее, но хорошим кодировщикам этот костыль не нужен :)

Сообщение Рико Мариани о том, почему Microsoft не переносит Visual Studio на 64-разрядную версию, действительно подводит итог Visual Studio: Почему нет 64-битной версии? (пока)

Если у вас сейчас нет реальной потребности в 64-битном режиме, и, вероятно, никогда не будет, вам не следует выполнять перенос.

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

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

В обозримом будущем 32-битные приложения будут по-прежнему поддерживаться.

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

Я бы не стал беспокоиться о том, что поддержка 32-битной версии скоро прекратится.

(Отредактировано, чтобы включить примечания из комментариев - спасибо!)

Хотя это правда, что 32-разрядные версии будут доступны для хотя в той или иной форме Windows Server 2008 R2 поставляется только с 64-разрядным SKU. Я не удивлюсь, увидев WOW64 в качестве варианта установки уже в Windows 8, поскольку все больше программного обеспечения переходит на 64-разрядную версию. WOW64 - это накладные расходы на установку, память и производительность. Ограничение ОЗУ 3,5 ГБ в 32-разрядной версии Windows вместе с увеличением плотности ОЗУ будет способствовать этой миграции. Я бы предпочел иметь больше ОЗУ, чем ЦП ...

Примите 64-битную версию! Найдите время, чтобы сделать свой 32-битный код 64-битным, это несложно и просто. Для обычных приложений изменения более точно описываются как исправления кода. У водителей выбор: адаптироваться или потерять пользователей. Когда придет время, вы будете готовы к развертыванию на любой платформе с перекомпиляцией.

ИМО, текущие проблемы, связанные с кешем, спорные; В ближайшее время будут внесены усовершенствования в кремнии в этой области и дальнейшая 64-битная оптимизация.

накладные расходы на память и производительность. Ограничение ОЗУ 3,5 ГБ в 32-разрядной версии Windows вместе с увеличением плотности ОЗУ будет способствовать этой миграции. Я бы предпочел иметь больше ОЗУ, чем ЦП ...

Примите 64-битную версию! Найдите время, чтобы сделать свой 32-битный код 64-битным, это несложно и просто. Для обычных приложений изменения более точно описываются как исправления кода. У водителей выбор: адаптироваться или потерять пользователей. Когда придет время, вы будете готовы к развертыванию на любой платформе с перекомпиляцией.

ИМО, текущие проблемы, связанные с кешем, спорные; В ближайшее время будут внесены усовершенствования в кремнии в этой области и дальнейшая 64-битная оптимизация.

накладные расходы на память и производительность. Ограничение 3,5 ГБ ОЗУ в 32-разрядной Windows вместе с увеличением плотности ОЗУ будет способствовать этой миграции. Я бы предпочел иметь больше ОЗУ, чем ЦП ...

Примите 64-битную версию! Найдите время, чтобы сделать свой 32-битный код 64-битным, это несложно и просто. Для обычных приложений изменения более точно описываются как исправления кода. У водителей выбор: адаптироваться или потерять пользователей. Когда придет время, вы будете готовы к развертыванию на любой платформе с перекомпиляцией.

ИМО, текущие проблемы, связанные с кешем, спорные; Ожидаются улучшения в этой области и дальнейшая 64-битная оптимизация.

Найдите время, чтобы сделать свой 32-битный код 64-битным, это несложно и просто. Для обычных приложений изменения более точно описываются как исправления кода. У водителей выбор: адаптироваться или потерять пользователей. Когда придет время, вы будете готовы к развертыванию на любой платформе с перекомпиляцией.

ИМО, текущие проблемы, связанные с кешем, спорные; В ближайшее время будут внесены усовершенствования в кремнии в этой области и дальнейшая 64-битная оптимизация.

Найдите время, чтобы сделать свой 32-битный код 64-битным, это несложно и просто. Для обычных приложений изменения более точно описываются как исправления кода. У водителей выбор: адаптироваться или потерять пользователей. Когда придет время, вы будете готовы к развертыванию на любой платформе с перекомпиляцией.

ИМО, текущие проблемы, связанные с кешем, спорные; В ближайшее время будут внесены усовершенствования в кремнии в этой области и дальнейшая 64-битная оптимизация.

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

Все это может привести к появлению скрытых ошибок, а это значит, что вы можете их исправить.

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

If you don't have any real need now, and likely never will, for 64-bit mode, you shouldn't do porting.

If you don't have the need now, but may have it some day, you should try to estimate how much effort it will be (e.g. by turning on all respective compiler warnings, and attempting a 64-bit compilation). Expect that some things aren't trivial, so it will be useful to know how what problems you would likely encounter, and how long it would likely take to fix them.

Notice that a need may also arise from dependencies: if your program is a library (e.g. a DLL), it may be necessary to port it to 64-bit mode just because some host application gets ported.

For a foreseeable future, 32-bit applications will continue to be supported.

Некоторые ОС или конфигурации не могут запускать 32-разрядные программы. Например, минимальный Linux без установленной 32-битной libc . Кроме того, IIRC I обычно компилирует 32-разрядную поддержку из ядра.

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

Если вам нужно больше скорости, вам следует также портируйте его (как говорили другие, x86-64 имеет больше регистров и классных инструкций, которые ускоряют его).

Или, конечно, если вы хотите использовать mmap () или иным образом отобразить большой файл или много памяти. Тогда помогает 64-битная версия.

Я бы добавил:

• Относитесь скептически даже к результатам профилировщика: сначала используйте свой мозг.
• Не верьте этому, пока не увидите. РЕДАКТИРОВАТЬ: код формата

  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.

Что касается проблем с производительностью, то это действительно зависит от вашей программы. Если ваша программа интенсивно использует указатели, перенос на 64-разрядную версию может привести к снижению производительности, поскольку для кеш-памяти ЦП с тем же размером каждый 64-разрядный указатель занимает больше места в кеше, а сопоставления виртуальных и физических объектов также занимают больше пространства TLB. . В противном случае, если ваша программа не требует интенсивного использования указателей, ее производительность улучшится от x64.

Конечно, производительность - не единственная причина для переноса, другие вопросы, такие как усилия по переносу, планирование времени, также должны быть рассмотрены.

Я бы порекомендовал перенести его на 64-битную версию, чтобы вы использовали "родной" (также я использую OpenBSD. В своем порте на AMD64 они не поддерживают 32-битную эмуляцию, все должно быть 64-битным)

Кроме того, stdint.h - ваш лучший друг! Портировав свое приложение, вы должны научиться что заставит ваш код работать правильно, когда у нас тоже будут 128-битные процессоры (надеюсь, через несколько десятилетий)

Я перенес 2 или 3 вещи на 64-битные и теперь разрабатываю f или и то, и другое (что очень просто, если вы используете stdint.h), и в моем первом проекте при переносе на 64-битную версию появилось 2 или 3 ошибки, но это было все. По большей части это была простая перекомпиляция, и теперь я не беспокоюсь о различиях между 32 и 64 битами при создании нового кода, потому что я просто автоматически кодирую переносимый код. (с использованием intptr_t, size_t и т. д.)

Если dll вызывается из 64-битного процесса, то dll тоже должна быть 64-битной. Тогда это так. независимо от того, стоит ли оно того, у вас просто нет выбора.

Одна проблема, о которой следует помнить, - это доступные библиотеки программного обеспечения. Например, моя компания разрабатывает приложение, использующее несколько библиотек OpenGL, и мы делаем это в ОС OpenSuSE. В более старых версиях ОС можно было загрузить 32-битные версии этих библиотек на архитектуре x86_64. Однако в более новых версиях этого нет. Это упростило компиляцию в 64-битном режиме.