война миров

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #071, стр. 071-024-5

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

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

После «ручной» оптимизации исходный текст нашей программы будет выглядеть так (оптимизированный вариант crc() с развернутым циклом):

if ((a=n)>3)

// обрабатываем первые n – (n % 4) итераций

for (a = 0; a < n — 3; a += 4)

{

crc_1 += p[a+0];

crc_2 += p[a+2];

crc_3 += p[a+3];

crc_4 += p[a+4];

}

// обрабатываем оставшийся «хвост»

for (a = n — x % 4; a < x; a++) crc += p[a];

// складываем все воедино

crc += crc_1 + crc_2 + crc_3 + crc_4;

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

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