Для характеристик петли

Question

Итог: скорость имеет значение.

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

За исключением петель.

Мы всегда были рады использовать их, потому что они помогают улучшить читаемость кода и помочь пользователю. ПОЛЬЗОВАТЕЛЬ. После того, как я сказал, определение в моей голове эта мысль пришла в голову:

for (int i = 0; i < 100; i++) 
{ 
    //whatever code 
} 

Давайте предположим случай, когда мы знаем длину. Это выполняет код 100 раз, но он выполняет 201 операцию, которую можно опустить, чтобы помочь машине. Что делать, если мы копируем вставить код в 100 раз, выбрасывая инициализации, состояние и окончание:

//Code[0] 
//Code[1] 
//Code[2] 
//... 

Это маленький кусочек, но все-таки ...

Является ли это обычная практика для лунатиков эффективности?

Answer 1

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

Для примера, возможно, вас заинтересует Duff's device. Это позволяет вам разворачивать цикл в цикле с переменной верхней границей, не беспокоясь о «оставшихся» итерациях в конце.

Если вы зацикливаете от 0 до 200, разворачивание цикла 200x не обязательно значительно улучшит вашу производительность. Там есть компромисс между тем, сколько кода вы генерируете и сколько увеличения производительности вы получаете, избегая ветвления. Я думаю, что во многих кодах распространено не более 10, но у меня нет ссылок на резервное копирование этого номера.

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

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

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

1. Напишите код, чтобы его можно было прочитать.
2. Profile the code, чтобы увидеть, какая часть ест больше всего времени.
3. Посмотрите, есть ли изменение алгоритма/структуры данных, которое я могу внести в этот раздел, чтобы ускорить его.
4. Когда все остальное терпит неудачу, прибегают к этому типу преобразования кода низкого уровня (что вы надеялись, что компилятор позаботится о вас).