Поставка 64-битных версий вашего программного обеспечения - PullRequest
7 голосов
/ 27 ноября 2008

Могу ли я ожидать какого-либо прироста производительности, если встроить свой собственный клиент и сервер C ++ в 64-битный код?

Какие приложения выигрывают от 64-битной сборки?

Я бы предположил, что все, что широко использует long, принесет пользу, или любое приложение, которому требуется огромный объем памяти (т. Е. Более 2 ГБ), но я не уверен, что еще.

Ответы [ 6 ]

17 голосов
/ 27 ноября 2008

Архитектурные преимущества Intel x64 по сравнению с x86

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

Архитектурный недостаток режима x64

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

В приложениях, которые я написал, я иногда видел большие ускорения (30%) и иногда видел большие замедления (> 2x) при переходе на 64-битные. Большие ускорения произошли в приложениях обработки чисел / обработки видео, где я был привязан к регистру.

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

Преимущество портирования сейчас

Написание 64-битно-совместимого кода не так уж сложно в 99% случаев, если вы знаете, на что обращать внимание. В основном, это сводится к использованию size_t и ptrdiff_t вместо int при обращении к адресам памяти (здесь я предполагаю код C / C ++). Может быть трудно преобразовать много кода, который не был написан для 64-битной поддержки.

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

5 голосов
/ 27 ноября 2008

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

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

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

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

1 голос
/ 27 ноября 2008

Продолжение комментария @ mdbritt , сборка для 64-битной системы имеет гораздо больший смысл [на данный момент], если это сборка сервера или вы распространяете ее среди пользователей Linux.

Кажется, что гораздо больше рабочих станций Windows все еще 32-разрядные, и для новой сборки может не хватить большой клиентской базы.

С другой стороны, многие серверные установки сейчас 64-битные: RHEL, Windows, SLES и т. Д. НЕ сборка для них будет отсекать большой потенциал использование, на мой взгляд.

Пользователи Linux для настольных компьютеров также могут использовать 64-разрядные версии своего любимого дистрибутива (скорее всего, Ubuntu, SuSE или Fedora).

Однако главное очевидное преимущество построения для 64-битной системы - это преодоление барьера в 3 ГБ для использования памяти.

1 голос
/ 27 ноября 2008

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

0 голосов
/ 27 ноября 2008

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

0 голосов
/ 27 ноября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...