В настоящее время я изучаю увеличение производительности между текущей средой сборки моей команды, которая все еще использует gcc-4.1.2, и сборкой, использующей gcc-4.8.1. Результаты были поразительными, с средневзвешенным ускорением регрессии не менее чем на 25%. Я также добавил еще один тест с использованием gcc-4.4.7, но он увидел средневзвешенное значение примерно на 7% ускорения. Я предположил, что большое расхождение было связано с новой семантикой копирования / перемещения в C ++ 11, и поскольку транзакции с памятью были довольно большим узким местом в нашей программе. Мы широко используем типы STL, поэтому, возможно, компилятор хорошо использовал их новые конструкторы перемещения.
Чтобы проверить свои утверждения, я выбрал тест, который показал среднее улучшение производительности, и запустил на нем kcachegrind для обеих компиляций. Результаты опубликованы ниже, и не совсем то, что я ожидал. Я должен указать на быструю и потенциально важную деталь. Мне пришлось статически скомпилировать libstdc ++ gcc-4.8.1. Так по соображениям бюрократии. Это означало, что в локациях kcachegrind были некоторые частные библиотеки, которые я цензурировал для безопасности.
К моему большому удивлению, количество обращений к операциям с памятью было относительно неизменным (malloc
а также _int_malloc
). Еще один интересный результат — полное отсутствие memcpy
и добавление _memcmp_sse4_1
,
Если я хочу проверить свою гипотезу о том, что семантика C ++ 11 является причиной повышения производительности, что мне следует искать в графах callgrind? Должен ли я найти меньше обращений к памяти, или я должен даже найти std::string(string&&)
подписи (которых я на самом деле не нахожу здесь). Имейте в виду, что это составлено с -O3
, что может означать, что такие подписи оптимизированы, отсюда моя дилемма.
Я более чем рад сообщить о таком значительном увеличении производительности, но я хотел бы понять, откуда эта производительность. Дайте мне знать, если нужно сообщить больше результатов для более точных ответов. Я надеюсь, что это не слишком общий вопрос для SO …
Задача ещё не решена.