Разница в производительности развертывания цикла C++ (проект Euler)

Использование || означает, что как только одно из них истинно, остальные условия не вычисляются. Это будет эквивалентно циклу:

    for (int j = 2; j <= 20; j++)
    {
        if ( i % j != 0){
            isDivisible = false;
            break;
        }
    }

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

EDIT О новой разнице в производительности:
Существует множество оптимизированных способов проверки делимости чисел на константы, например, для N любую степень 2 можно заменить на i % N != 0 на i & (N-1), существуют и другие, и не столь очевидны.
Компилятор знает множество этих маленьких хитростей и во втором блоке кода, вероятно, способен оптимизировать большинство, если не все эти проверки делимости (поскольку они написаны непосредственно вами), в то время как в первом коде блоке, он должен решить сначала развернуть циклы, а затем заменить переменную цикла константами, прежде чем можно будет даже рассуждать о разных проверках.
Возможно, это различие способствует лучшей оптимизации кода в блоке 2, чем в блоке 1.

3 580 000 против 970 000 — это не только накладные расходы на цикл...

В вашем последнем ядре, похоже, вы намеревались сохранить блок Up, Down и Square между другим циклом, но эти блоки являются «краткими» локальными, поэтому данные, которые они содержат, не распределяются между ветвями. К сожалению, ваш подход не сработает, даже если они будут разделены между ветвями.

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

Вам, вероятно, следует решить эту проблему с помощью существующих параллельных примитивов, таких как суммы префиксов, которые уже были оптимизированы. Например, в CUB или Thrust.