Могу ли я увидеть какой-либо прирост производительности, если встроить свой собственный клиент и сервер C ++ в 64-битный код?
Для каких приложений нужна 64-битная сборка?
Я бы предположил, что все, что широко использует long, принесет пользу или любое приложение, которому требуется огромный объем памяти (т.е. более 2 ГБ), но я не уверен, что еще.
Архитектурные преимущества Intel x64 по сравнению с x86
Архитектурный недостаток режима x64
В написанных мною приложениях я иногда замечал большое ускорение (30%), а иногда большое замедление (> 2x) при переходе на 64-разрядную версию. Значительное ускорение произошло в приложениях для обработки чисел и обработки видео, в которых я был привязан к регистру.
Единственное большое замедление, которое я видел в моем собственном коде при преобразовании в 64-разрядную версию, связано с массивным приложением, отслеживающим указатели, когда один компилятор сделал несколько действительно плохих «оптимизаций». Другой компилятор сгенерировал код, в котором разница в производительности была незначительной.
Преимущества переноса сейчас
Написание 64-битного кода не так уж и сложно в 99% случаев, если вы знаете, на что обращать внимание. В основном это сводится к использованию size_t и ptrdiff_t вместо int при обращении к адресам памяти (здесь я предполагаю код C / C ++). Преобразование большого количества кода, который не был написан для поддержки 64-разрядной версии, может быть проблемой.
Даже если нет смысла делать 64-битную сборку для вашего приложения (вероятно, нет), стоит потратить время на то, чтобы узнать, что потребуется для создания сборки, чтобы, по крайней мере, весь новый код и будущие рефакторинги будет 64-битным.
Прежде чем слишком усердно работать над выяснением, существует ли технический случай для 64-битной сборки, вы должны убедиться, что существует бизнес случай. Ваши клиенты просят такую сборку? Сможет ли это дать вам определенное преимущество в конкуренции с другими поставщиками? Каковы затраты на создание такой сборки и какие бизнес-расходы будут понесены при добавлении еще одного элемента в процессы бухгалтерского учета, продаж и маркетинга?
Хотя я понимаю, что вам необходимо понимать потенциал повышения производительности, прежде чем вы сможете справиться с конкурентными преимуществами, я настоятельно рекомендую вам подойти к проблеме с точки зрения общей картины. Если вы ведете малый бизнес или ведете индивидуальный бизнес, вы обязаны проявить должную осмотрительность перед собой. Если вы работаете в более крупной организации, ваше начальство высоко оценит усилия, которые вы приложили для обдумывания этих вопросов (или сочтут всю проблему просто чудаковатым излишеством, если вы, кажется, не готовы на них ответить).
С учетом всего сказанного, мой общий технический ответ будет заключаться в том, что подавляющее большинство приложений, ориентированных на пользователя, не увидят никаких преимуществ от 64-битной сборки. Подумайте об этом: сколько проблем с производительностью в вашем текущем приложении возникает из-за привязки к процессору (или ограничения доступа к ОЗУ)? Есть ли проблемы с производительностью в вашем текущем приложении? (В противном случае вам, вероятно, не следует задавать этот вопрос.)
Если это приложение клиент / сервер, я уверен, что задержка в сети гораздо больше влияет на производительность на стороне клиента (особенно если ваши запросы обычно возвращают много данных). Предполагая, что это приложение для базы данных, какая часть вашего профиля производительности связана с задержкой диска на сервере? Если вы подумаете обо всей совокупности факторов, влияющих на производительность, вы лучше поймете, выиграет ли ваше конкретное приложение от 64-битного обновления, и если да, то нужно ли вам обновлять обе стороны или все ваши выгода будет извлечена только из обновления на стороне сервера.
На самом деле, больше ничего. Хотя написание 64-битного приложения может иметь некоторые преимущества для вас, как программиста, в некоторых случаях. Упрощенный пример - приложение, основное внимание которого уделяется взаимодействию с реестром. Как 32-битный процесс, ваше приложение не будет иметь доступа к большим участкам реестра в 64-битных системах.
Продолжая комментарий @ mdbritt, сборка для 64 -bit имеет гораздо больше смысла [в настоящее время], если это сборка сервера или если вы распространяете его среди пользователей Linux.
Похоже, что гораздо больше рабочих станций Windows по-прежнему являются 32-разрядными, и, возможно, не будет большой клиентской базы для новой сборки.
С другой стороны, сейчас многие серверы устанавливаются на 64-битные версии: RHEL, Windows, SLES и т. Д. Сборка НЕ для них может значительно сократить потенциальное использование. , на мой взгляд.
Пользователи настольных Linux также могут использовать 64-битные версии своего любимого дистрибутива (скорее всего, Ubuntu, SuSE или Fedora).
Однако главное очевидное преимущество сборки для 64-разрядной версии состоит в том, что вы обойдете барьер в 3 ГБ для использования памяти.
Согласно этой веб-странице, вы больше всего выиграете от дополнительных регистров общего назначения с 64-битными ЦП, если вы используете много и / или глубоких циклов.
Вы можете ожидать выигрыша благодаря дополнительным регистрам и новому соглашению о передаче параметров (которые действительно связаны с дополнительными регистрами).
