Операция сравнения < быстрее, чем <=? Влияет ли выбор оператора на производительность в C++?

Краткий ответ: нет, разницы в производительности нет

На современных компиляторах и процессорах выбор между < и <= не влияет на скорость выполнения. Компилятор оптимизирует оба варианта до одинакового машинного кода. Если когда-то (в эпоху 8-битных процессоров) и была разница, то сейчас это миф из прошлого.

Почему так происходит?

Процессоры x86-64 и ARM имеют инструкции для всех типов сравнений: JL (jump if less), JLE (jump if less or equal), JGE и т.д. Все они выполняются за одинаковое количество тактов (обычно 1 такт). Более того, компиляторы часто преобразуют i <= n в i < n+1 или наоборот, чтобы получить более эффективный код.

Проверим на практике

Рассмотрим два цикла:

// Вариант 1: i < n
int sum1 = 0;
for (int i = 0; i < 1000000; ++i) {
    sum1 += i;
}

// Вариант 2: i <= n
int sum2 = 0;
for (int i = 0; i <= 999999; ++i) {
    sum2 += i;
}

Скомпилируем с -O2 (g++ или clang++) и посмотрим на ассемблер. Оба варианта дадут практически идентичный код:

; Примерный ассемблер для x86-64
xor eax, eax          ; sum = 0
xor ecx, ecx          ; i = 0
.L2:
add eax, ecx          ; sum += i
add ecx, 1            ; ++i
cmp ecx, 1000000      ; сравнение с границей
jl .L2                ; jump if less (или jle для второго варианта)

Единственное отличие — инструкция jl vs jle. Но обе выполняются за 1 такт на современных процессорах (Intel Core, AMD Ryzen).

Что насчёт вложенных циклов и сложных условий?

Если условие сложнее (например, if (a < b && c <= d)), компилятор может переставить сравнения или объединить их. Но опять же, выбор оператора не даст преимущества.

Когда разница может быть заметна?

• На очень старых процессорах (Intel 8086, Z80) — там сравнение на равенство могло быть дороже. Но такие CPU уже не используются в современном софте.
• В циклах с инкрементом на 1 — компилятор может заменить i <= n на i < n+1, если n+1 не вызывает переполнения. Но это не делает код быстрее или медленнее.
• Если граница цикла — отрицательное число — тут может возникнуть проблема со знаковым переполнением, но это уже вопрос корректности, а не производительности.

Вывод

Не заморачивайтесь на выбор между < и <=. Пишите код так, чтобы он был читаемым и логичным. Если вам нужно выполнить итерации от 0 до 99, используйте i < 100. Если от 0 до 100 включительно — i <= 100. Разницы в скорости нет.

Единственное, что действительно влияет на производительность циклов — это:

• Минимизация вызовов функций в условии (например, for (int i = 0; i < vec.size(); ++i) лучше заменить на for (size_t i = 0, end = vec.size(); i < end; ++i)).
• Использование префиксного инкремента ++i вместо постфиксного i++ (для итераторов).
• Разворачивание циклов (loop unrolling) — но это компилятор делает сам.

unsigned int n = 0;
for (unsigned int i = 0; i <= n; ++i) {
    // что-то делаем
}

std::vector<int> v = {1, 2, 3};
for (auto it = v.begin(); it <= v.end(); ++it) {  // Ошибка! 
    // ...
}