Исследование параллелизма на уровне команд

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

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

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

Если я вас правильно понял, вас не интересуют SIMD или потоки, вы просто получаете оптимальный порядок обычных инструкций процессора.

Первое, что нужно проверить, это то, нацелен ли ваш компилятор на правильный подтип ЦП. Компилятор обычно переупорядочивает инструкции, чтобы уменьшить зависимости от одной инструкции к другой, но для компилятора жизненно важно знать, на какую версию ЦП вы нацеливаетесь. (в частности, более старый GCC иногда не может обнаружить новейшие процессоры, а затем оптимизируется для i386).

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

Наконец, для процессоров Intel собственный компилятор C ++ от Intel утверждает, что лучше всех справляется с этой задачей. У них также есть профилировщик vTune, который специально может сообщать об эффективном использовании ALU в горячих точках вашей программы.

Предыдущие ответы хороши. Кроме того, на сайте Intel есть чему поучиться, и если у вас есть бюджет, то стоит взглянуть на инструменты Intel.
Статьи Intel по оптимизации

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

Однако есть несколько областей, в которых человек может помочь процессу.

Компилятор обычно очень консервативен в переупорядочивании вычислений с плавающей запятой, потому что это может немного изменить результат. Так, например, предполагая этот код:

float f, g, h, i;
float j = f + g + h + i;

, вы, вероятно, получите нулевое значение ILP, потому что написанный вами код оценивается как ((f + g) + h) + i : результат первого сложение используется как операнд для следующего, результат которого используется как операнд в последнем сложении. Никакие два дополнения не могут выполняться параллельно.

Если вместо этого вы запишете его как float j = (f + g) + (h + i) , ЦП сможет выполнить f + g и h + i параллельно. Они не зависят друг от друга.

В общем, ILP препятствует зависимостям. Иногда они являются прямыми зависимостями между арифметическими инструкциями, как указано выше, а иногда - зависимостями хранения / загрузки.

Загрузка и сохранение занимают много времени по сравнению с операциями в регистре, и операции, которые зависят от них, должны будут ждать завершения операции загрузки / сохранения.

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

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

При отсутствии зависимостей ЦП планирует операции для параллельного выполнения. Итак, все, что вам нужно сделать, чтобы использовать ILP, - это разорвать длинные цепочки зависимостей.

Конечно, легче сказать, чем сделать ... :)

Но если вы потратите некоторое время на профилировщик и изучите вывод сборки компилятора, вы иногда можете получить впечатляющее ускорение от ручной оптимизации вашего кода чтобы лучше использовать ILP.

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

Что-то вроде Acumems SlowSpotter может помочь (если вам действительно не нужно вручную оптимизировать для ILP, и в этом случае я не знаю хорошего инструмента если компилятор не может выплюнуть хороший отчет по оптимизации для вас, компиляторы IIRC the Cray и SGI MIPS могут создавать отчеты, подобные .).