Влияние производительности -fno-strict-aliasing

Ответ 1

Это будет сильно отличаться от компилятора к компилятору, так как разные компиляторы реализуют его с разными уровнями агрессии. GCC довольно агрессивен в этом отношении: включение строгого псевдонима заставит его думать, что указатели, которые "очевидно" эквивалентны человеку (как, например, foo *a; bar *b = (bar *) a;), не могут иметь псевдоним, что позволяет для некоторых очень агрессивных преобразований, но, очевидно, может нарушить не тщательно написанный код. По этой причине Apple GCC отключает строгий псевдоним по умолчанию.

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

По моему опыту, влияние строгого псевдонима на производительность главным образом связано с движением инвариантного кода цикла, где информация о типе может использоваться, чтобы доказать, что загрузки в цикле не могут наложить псевдоним на массив, который перебирается, что позволяет их извлекать из петля. YMMV.

Ответ 2

Что я могу рассказать вам по опыту (протестировав это с помощью большого проекта на PS3, PowerPC, являющегося архитектурой, из-за которой многие регистры действительно могут извлечь выгоду из SA достаточно хорошо) заключается в том, что оптимизация, которую вы собираетесь увидеть, как правило, будет очень локальным (с точки зрения объема) и небольшим. В 20 Мб исполняемый файл скрепил, возможно, 80 КБ раздела .text(= code), и все это было в небольших областях и циклах.

Эта опция может сделать ваш сгенерированный код немного более легким и оптимизированным, чем сейчас (подумайте в диапазоне от 1 до 5 процентов), но не ожидайте больших результатов. Следовательно, эффект использования -fno-strict-aliasing, вероятно, не будет иметь большого влияния на вашу производительность. Тем не менее, наличие кода, который требует -fno-strict-aliasing, в лучшем случае является субоптимальной ситуацией.

Ответ 3

Вот ссылка на исследование, проведенное в 2004 году: http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1124&context=ecetr, касающееся, среди прочего, строгого воздействия на производительность кода. Рисунок 2.5 показывает относительное улучшение от 3% до 10%.

Объяснение исследователям ухудшения производительности:

Из проверки кода сборки мы обнаружили, что деградация является следствием алгоритм распределения регистров. GCC реализует распределитель регистров раскраски графа [2, 3]. При строгом сглаживании диапазоны переменных переменных становятся длиннее, что приводит к высокому регистровому давлению и "проливанию". С более консервативным псевдонимом одни и те же переменные переносят передачу памяти в конце их (более коротких) диапазонов в реальном времени.

[2] Питер Бергнер, Питер Дал, Дэвид Энгебретсен и Мэтью Т. Окифе. Код разлива минимизация путем разлива области интерференции. В конференции SIGPLAN по программированию Разработка и внедрение языков, страницы 287-295, 1997.

[3] Престон Бриггс, Кейт Д. Купер и Линда Торшон. Усовершенствования графовой окраски распределение регистров. ACM-транзакции на языках программирования и системах, 16 (3): 428-455, май 1994 года.