Я пытаюсь оптимизировать часть кода, которая вызывается в параллельном регионе (OpenMP). Я провел анализ доступа к памяти с помощью Intel VTune Amplifier 2015 и немного смущен результатом. Я повторил анализ с уровнями оптимизации O1, O2 и O3 на Intel Composer 2015, но результат тот же. Усилитель утверждает, что большинство пропусков LLC появляются в следующих трех строках:
__attribute__ ((aligned(64))) double x[4] = {1.e0,-1.e0, 0.e0, 0.e0};
__attribute__ ((aligned(64))) double y[4] = {0.e0,-1.e0, 1.e0, 0.e0};
__attribute__ ((aligned(64))) double z[4] = {0.e0, 0.e0,-1.e0, 1.e0};
Данные выровнены, потому что к ним обращаются позже в векторизованном коде. Я не могу опубликовать весь код здесь, потому что он имеет авторское право. Это примерно 75% от общего числа пропущенных кешей в этой функции, хотя в коде много вычислений и других массивов.
Для O0-оптимизации я получаю гораздо более реалистичные результаты, потому что там, где такие строки
res[a] += tempres[start + b] * fact;
Но там все выполнение требует гораздо больше времени (это ясно). Но каким результатам я могу доверять? Или какое альтернативное программное обеспечение я могу использовать для тестирования.
Заранее спасибо!
Глядя только на проценты, можно ввести в заблуждение (75% от 100 — это меньше, чем 10% от 1000) — вам нужно посмотреть на абсолютное количество промахов при сравнении.
Поведение кэша также сложно интуитивно, особенно в сочетании с оптимизацией компилятора и конвейерами ЦП.
Похоже, что оптимизированные сборки в большинстве случаев пропускают кеш при инициализации (что не так уж удивительно), но им удается хранить почти все вычисления в кеше, поэтому здесь я не вижу проблем.
Если ты хочешь быть конечно, вам нужно изучить сгенерированную сборку и справочные руководства для вашего оборудования.
Поиск инструмента, который подтверждает ваши ожидания, в значительной степени является пустой тратой времени, так как вы не можете быть уверены, что тот инструмент не тот, который по ошибке.