C ++ определяет «лучшую» версию режима сборки в VS - PullRequest
Новая
       26

C ++ определяет «лучшую» версию режима сборки в VS

6 голосов
/ 17 марта 2010

В настоящее время я использую следующие определения препроцессора и различные параметры оптимизации:

  • WIN32_LEAN_AND_MEAN
  • VC_EXTRALEAN
  • NOMINMAX
  • _CRT_SECURE_NO_WARNINGS
  • _SCL_SECURE_NO_WARNINGS
  • _SECURE_SCL = 0
  • _HAS_ITERATOR_DEBUGGING = 0

Мой вопрос заключается в том, что другие вещи используют другие SO, добавляя, определяя, чтобы получить сборку Release Mode из VS C ++ (2008,2010) для максимально возможной производительности?

Кстати, я пробовал PGO и т. Д., Это немного помогает, но ничто не сравнится с GCC, также я не использую потоки, C ++ я говорю о том, что он больше похож на C, но использует шаблоны алгоритмы STL и т. д.

В настоящее время очень простые сегменты кода бледнеют по сравнению с производительностью по сравнению с тем, что GCC производит на эквивалентной машине x86, работающей под управлением Linux (ядро 2.6+) с использованием 02.

Примечание: Я полагаю, что многие проблемы напрямую связаны с версией STL (Dinkum), предоставляемой MS. Могли бы люди рассказать подробнее об опыте использования STLPort и т. Д. С VS C ++.

1 Ответ

1 голос
/ 17 марта 2010

Я не вижу, как включение: 

_CRT_SECURE_NO_WARNINGS
_SCL_SECURE_NO_WARNINGS

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

ОБНОВЛЕНИЕ : Более того, компилятор может делать только так много. Держу пари, вы бы получили более производительный код, если бы вы оснастили и исправили существующие горячие точки вместо того, чтобы пытаться получить крошечный процент (если таковой) выгоды от фазы компиляции и компоновки.

UPDATE2 : _HAS_ITERATOR_DEBUGGING нельзя использовать при компиляции сборок релиза в любом случае в соответствии с MSDN . WIN32_LEAN_AND_MEAN VC_EXTRALEAN (и, вероятно, NOMINMAX, хотя производительность не является главной причиной для отключения этого), может дать вам некоторое повышение производительности, хотя все остальные имеют сомнительную ценность. Вы должны предпочесть правильный быстрый код более ( возможно - и я подчеркиваю, возможно) немного быстрее, но более подверженный риску код.

...