Сравнение получилось странное, потому что самая медленная часть получившегося кода у всех компиляторов - инструкция деления. Её производительность не сильно зависит от того, кто её скомпилировал. На моём процессоре под g++ если использовать профилировщик, останавливающий последнюю программу 100 раз в секунду, то 89% остановок попадают на инструкцию сразу после деления (у остановки небольшая погрешность, конечно). У других программ делений выполняется ровно столько же, поэтому можно вычесть что-нибудь, и разница в производительности сразу станет заметнее.
У меня программа от clang++ работает с той же скоростью, что и от g++. Когда я нашёл причину этого несоответствия, моей радости не было предела: похоже, это очередная победа AMD над Intel! Машинный код от g++ (и от pypy3) выполняет честное 64-битное деление, а clang++ сначала проверяет, влезает ли делитель в 32 бита, и выполняет 32-битное деление, если это возможно (а тут числа маленькие и это возможно всегда). Видимо, мой процессор интеллектуально анализирует делитель и автоматически выбирает самый быстрый алгоритм для каждой ситуации. Clang, похоже, знает это и не вставляет ненужную проверку при использовании -march=znver1.
C++ без оптимизации работает очень плохо, потому что с -O0 компиляторы сохраняют результаты всех операций на стек, а операторы инкремента, разыменования и сравнения итераторов вызываются на каждой итерации как полноценные функции.
Сравнение получилось странное, потому что самая медленная часть получившегося кода у всех компиляторов - инструкция деления. Её производительность не сильно зависит от того, кто её скомпилировал. На моём процессоре под g++ если использовать профилировщик, останавливающий последнюю программу 100 раз в секунду, то 89% остановок попадают на инструкцию сразу после деления (у остановки небольшая погрешность, конечно). У других программ делений выполняется ровно столько же, поэтому можно вычесть что-нибудь, и разница в производительности сразу станет заметнее.
У меня программа от clang++ работает с той же скоростью, что и от g++. Когда я нашёл причину этого несоответствия, моей радости не было предела: похоже, это очередная победа AMD над Intel! Машинный код от g++ (и от pypy3) выполняет честное 64-битное деление, а clang++ сначала проверяет, влезает ли делитель в 32 бита, и выполняет 32-битное деление, если это возможно (а тут числа маленькие и это возможно всегда). Видимо, мой процессор интеллектуально анализирует делитель и автоматически выбирает самый быстрый алгоритм для каждой ситуации. Clang, похоже, знает это и не вставляет ненужную проверку при использовании -march=znver1.
C++ без оптимизации работает очень плохо, потому что с -O0 компиляторы сохраняют результаты всех операций на стек, а операторы инкремента, разыменования и сравнения итераторов вызываются на каждой итерации как полноценные функции.