Тест Си компиляторов под Windows

    После многочисленных споров на тему «Какой компилятор лучше генерирует код», появилась идея провести самому испытания. Основной целью испытания была проверка скорости работы программы с оптимизацией по скорости. Результат тестирования: среднее арифметическое время выполнения тестовой функции в миллисекундах (1/1000 сек). т.е. чем меньше тем лучше.

    В тестировании участвовали:
    • Intel C++ Compiler Pro 11.1.054;
    • GCC 4.5.0 (MinGW);
    • MS C/C++ Compiler 15.00.21022.08 (VS 2008);
    • CodeGear C++ Builder 11.0 (C++Builder 2007);
    • Tiny C Compiler 0.9.25.
    Железо для теста:
    • Компьютер: CPU Intel E5200 (2-ядерный) 2.5 Ггц + 2 Гб ОЗУ;
    • Ноутбук: CPU AMD Athlon QL-62 (2-ядерный) 2 Ггц + 3 Гб ОЗУ.
    ОС для теста:

    MS Windows XP SP3 Eng x32 на ноутбуке и на компьютере (с одного диска устанавливались и один и тот же SP3 ставился).

    Варианты компиляции:
    1. Отключена любая оптимизация;
    2. Включена вся возможная оптимизация.
    Ограничения на тестирование:
    • Исходный код тестовой программы не изменяется в зависимости от компилятора;
    • Тестовая функция не использует функции системы, т.е. только вычислительные операции, все функции связанные с вызовом системных функций вызываются до и после замера времени;
    • Не используются библиотеки распараллеливания типа OpenMP;
    • Вычисления производятся только в одном потоке;
    • Компьютер не загружен больше никакими другими программами, только запущенная Windows + Notepad + тестовая программа;
    • Для тестов не использовалась VCL, MFC, CLR, ATL;
    • Код программ компилировался именно как С код, а не С++;
    • Для Tiny C Compiler использовался только 1 вариант компиляции, потому что он не поддерживает оптимизацию на уровне кода. Из документации: Оптимизация кода ограничена вычислением константных выражений на этапе компиляции, заменой операций умножения и деления операциями сдвига где это возможно, а также некоторыми другими действиями. Оптимизация переходов не производится, так как это потребовало бы организацию промежуточного кода в более абстрактном виде.
    Метод тестирования:
    1. Выделение памяти для буферов;
    2. Получение UserTime текущего потока через GetThreadTimes;
    3. Выполнение тестовой функции;
    4. Получение UserTime текущего потока через GetThreadTimes;
    5. Получение разницы во времени с точностью до миллисекунд (1/1000 сек);
    6. Повторение последних 4-х действий 10 раз;
    7. Вычисление среднего арифметического значения времени.
    Алгоритм вычислительной функции:
    1. Инициализация ключевой последовательности для алгоритма шифрования RC4;
    2. Инициализация ключевой последовательности для алгоритма шифрования AES-128;
    3. Заполнение первого тестового буфера данными полученными из генератора RC4;
    4. Вычисление CRC32 для первого тестового буфера;
    5. Шифрование первого тестового буфера алгоритмом AES-128, блоками по 128 бит, с помещением результата во второй тестовый буфер;
    6. Заполнение первого тестового буфера данными полученными из генератора RC4, т.е. первоначальные данные затираются полностью;
    7. Расшифровка второго тестового буфера с помещением результата в первый тестовый буфер;
    8. Подсчет CRC32 для расшифрованного первого тестового буфера;
    9. Сравнение CRC до шифрование и после.
    Параметры теста:
    • Кол-во данных для шифрования — 1600 килобайт (102400 блоков);
    • Кол-во тестовых итераций для вычисления среднего арифметического значения времени — 10.
    Результаты тестирования:
    Intel C++ Compiler Pro 11.1.054
    • Ноутбук без оптимизации: 6301 мс;
    • Ноутбук с оптимизацией: 971 мс;
    • Компьютер без оптимизации: 4541 мс;
    • Компьютер с оптимизацией: 867 мс.
    GCC 4.5.0 (MinGW)
    • Ноутбук без оптимизации: 6568 мс;
    • Ноутбук с оптимизацией: 1691 мс;
    • Компьютер без оптимизации: 4979 мс;
    • Компьютер с оптимизацией: 1521 мс.
    MS C/C++ Compiler 15.00.21022.08 (VS 2008)
    • Ноутбук без оптимизации: 5149 мс;
    • Ноутбук с оптимизацией: 1574 мс;
    • Компьютер без оптимизации: 3740 мс;
    • Компьютер с оптимизацией: 1290 мс.
    CodeGear C++ Builder 11.0 (C++Builder 2007)
    • Ноутбук без оптимизации: 4982 мс;
    • Ноутбук с оптимизацией: 3854 мс;
    • Компьютер без оптимизации: 4006 мс;
    • Компьютер с оптимизацией: 3185 мс.
    Tiny C Compiler 0.9.25
    • Ноутбук: 6275 мс;
    • Компьютер: 4606 мс.
    Более наглядно:График времени выполнения кода:imageГрафик скорости выполнения кода относительно лидера теста (лидер теста — 100%)image

    Итоги:
    По результатам тестирования на оптимизацию по скорости, компиляторы занимают следующие места:
    1. Intel C++ Compiler Pro 11.1.054;
    2. MS C/C++ Compiler 15.00.21022.08 (VS 2008);
    3. GCC 4.5.0 (MinGW);
    4. CodeGear C++ Builder 11.0 (C++Builder 2007);
    5. Tiny C Compiler 0.9.25.
    Как видно, ребята из Intel хорошо постарались (на 32% код работал быстрее чем у ближайшего соперника) и их код имеет отличную оптимизацию не зависимо от того что он работает на Intel или AMD процессоре.

    В тоже время С++ Builder показал себя не с лучшей стороны (отставание в 2 раза), что свидетельствует о чуть другой специфики его применения.

    Ну а про Tiny C Compiler 0.9.25 и речи не может быть, потому что он вообще не поддерживает оптимизацию переходов, вот и выходит, что скорость выполнения программы находится на уровне с другими компиляторами без оптимизации при компиляции.

    Конечно С++ Builder оказался чуть староват потому что не нашел я у себя более свежей версии. Хотя мне кажется, там мало что изменилось в этом плане.

    Заключение
    По результатам тестирования нельзя судить о компиляторе, что он хорош или плох, потому что каждому своё применение, а можно лишь говорить о том, какой их них подойдет для создания программных продуктов связанных с вычислительными операциями.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 12

    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        +3
        > Конечно С++ Builder оказался чуть староват
        Ага, а MS VS 2008 совсем новая штука? :) Брали бы уже от 2010-й студии компилятор.

        К тому же глупо сравнивать С++ компиляторы на абстрактных тестах. В первую очередь важна поддержка фич языка, потом скорость компиляции. И вот где-то между ними должна быть оптимизация. Какой мне толк от супербыстрого компилятора, который далеко не всё умеет? Шифрование это, конечно, хорошо, но всё же недостаточно в рамках MFC/CLR/…
          0
          Ну так тут тест именно на возможность оптимизации по скорости. Если так учитывать, то можно тестировать на что угодно, от скорости разработки софта, до размера.
            +1
            в 2010 почти все изменения касавшиесе компилятора обошли стороной С/С++, про него похоже в MS начинают медленно, но верно забывать. Потому т.к. сами занимаемся разработкой на плюсах пришлось отказаться от 2010, т.к. просто не поддерживал необходимый софт/библиотеки и тд.
              +2
              Ошибочное мнение. Судя по личным впечатлениям в частности компилятор стал шустрее. Далее, в 2010-й студии как раз наоборот вспомнили о С++, например в 2008-й нововведений было существенно меньше. Так же, насколько я знаю, внесли много новинок в виду нового стандарта и переработали существующий STL. Всё это есть в блоге на msdn: msdn.microsoft.com/en-us/library/dd547188.aspx раздел «Visual C++ Development», а так же поиск С++ по странице покажет много новинок.

              darkslesh: на самом деле как раз оптимизация и является тем сферическим понятием в тестах, которые в реальной жизни играют слабую роль. Например, разработчики серьёзных криптосистем либо другого софта, завязанного на тонны вычислений, вряд ли будут доверять компилятору оптимизацию, а сделают это сами по мере сил. В больших же приложениях намного более важны другие вещи, более высокоуровневые, потому как оптимизацией займутся опять же отдельно. Ну а для широкого сегмента «среднего» класса оптимизацией, судя по опыту, никто и не занимается, либо знаний не хватает, либо бюджетов, да и в софте «средней руки» никто и не думает об этом, частоты и память стоит дешевле.
              Потому тесты на оптимизацию это такая себе сферическая писькомерка, которая в реальной жизни зависит от очень многих параметров и очень часто оптимизаторы дают сбой, чем несказанно «веселят» ожидавших чуда программистов.
            +4
            Думаю, было бы полезно добавить командные строки запуска для каждого компилятора, потому что не вполне очевидно, что для вас означает «включена вся возможная оптимизация».
              +1
              Нужно учитывать, что в разных компиляторах функции импортируются по-разному. Компилятор из MS Visual Studio 6.0 напрямую юзает Win32 API, а gcc импортирует функции из msvcrt.dll.
                +4
                Если под «Включена вся возможная оптимизация» вы имели ввиду gcc -O3 -funroll-all-loops, то очевидно, почему GCC проиграл MS C++.

                Командные строки компиляторов и код в студию.
                  +3
                  Ох… Мне вот жутко узнать что такое «2. Включена вся возможная оптимизация.»

                  Для gcc и icc полно флагов подходящих под это определение. Да и в студии для сишного кода тоже много всего интересного по оптимизации есть. Причём не всегда очевидно какие флаги для каких задач использовать.

                  + я не вижу самого тестируемого кода, чтобы можно было о чём-то говорить.

                  p.s. ИМХО, Статья не о чём. Если честно, сложилось впечатление, что школьные каникулы у кого-то затянулись.
                    +2
                    > Включена вся возможная оптимизация.

                    Давайте я угадаю первые 50 параметров в GCC:
                    -fauto-inc-dec -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fguess-branch-probability -fif-conversion2 -fif-conversion -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fsplit-wide-types -ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time -fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fexpensive-optimizations -fgcse -fgcse-lm -finline-small-functions -findirect-inlining -fipa-sra -foptimize-sibling-calls -fpartial-inlining -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fschedule-insns -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -ftree-switch-conversion -ftree-pre -ftree-vrp -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -fipa-cp-clone -fzero-initialized-in-bss
                      0
                      А что старый добрый Watcom уже не котируется? :)

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое