[Troll]

Сравнительный анализ компиляторов С++

Игорь Тимошенко, "Комиздат"

К сожалению, выбор компилятора часто обусловлен, опять-таки, идеологией и соображениями вроде "его все используют". Конечно, среда разработки Microsoft Visual C++ несколько более удобна, чем у портированного gcc - но это ведь вовсе не значит, что релиз своего продукта вы должны компилировать с использованием MSVC++. Используйте оболочку, компилируйте промежуточные версии на MSVC++ (кстати, время компиляции у него гораздо меньше, чем у gcc), но релиз можно собрать с использованием другого компилятора, например от Intel. И, в зависимости от компилятора, можно получить прирост в производительности на 10% просто так, на ровном месте. Но какой "правильный" компилятор выбрать, чтобы он сгенерировал максимально быстрый код? К сожалению, однозначного ответа на этот вопрос нет - одни компиляторы лучше оптимизируют виртуальные вызовы, другие - лучше работают с памятью.

Попробуем определить, кто в чем силен среди компиляторов для платформы Wintel (x86-процессор + Win32 ОС). В забеге принимают участие компиляторы Microsoft Visual C++ 6.0, Intel C++ Compiler 4.5, Borland Builder 6.0, MinGW (портированный gcc) 3.2.

Порядок тестирования

Как проверить, насколько эффективный код генерирует компилятор? Очень просто: нужно выбрать несколько наиболее часто употребляемых конструкций языка и алгоритмов - и измерить время их выполнения после компиляции различными компиляторами. Для более точного определения времени необходимо набрать статистику и выполнить каждую конструкцию некоторое количество раз.

Вроде все просто - но тут начинают возникать определенные проблемы. Провести тестирование некоторых конструкций (например, обращение к полю объекта) не удастся из-за оптимизации на уровне компилятора: строки типа for (unsigned i=0;i<10000000;i++) dummy = obj->dummyField; все компиляторы просто выбросили из конечного бинарного кода.

Вторым неприятным моментом является то, что в результаты всех тестов неявно вошло время выполнения самого цикла "for", в котором происходит набор статистики. В некоторых реализациях оно может быть очень даже существенным (например, два такта на одну итерацию пустого for для gcc). Измерить "чистое" время выполнения пустого цикла удалось не для всех компиляторов - VC++ и Intel Compiler выполняют достаточно хорошую "раскрутку" кода и исключают из конечного кода все пустые циклы, inline-вызовы пустых методов и т.д. Даже конструкцию вида for (unsigned i=0;i<16;i++) dummy++; VC++ реализовал как dummy += 16;.

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

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

Для измерения времени выполнения тестов использовался счетчик машинных тактов, доступный по команде процессора RDTSC, что позволило не только сравнить время выполнения большого количества однотипных операций, но и получить приближенное время выполнения операции в тактах (вторая величина является более показательной и удобной для сравнения). Все тесты проводились на Pentium III (700 МГц), параметры компиляции были установлены в "-O2 -6" (оптимизация по скорости + оптимизация под набор команд Pentium Pro). Кроме того, для Borland Builder была добавлена опция --fast-call - передача параметров через регистры (Intel Compiler, MSVC++ и gcc автоматически используют передачу параметров через регистры при использовании оптимизации по скорости).

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

Тестирование скорости работы основных конструкций языка

Первый тест очень даже прост, он заключается в измерении скорости прямого вызова (member call), виртуального вызова (virtual call), вызова статик-метода (данная операция полностью аналогична вызову обыкновенной функции), создания объекта и удаления объекта с виртуальным деструктором (create object), создания/удаления объекта с inline-конструктором и деструктором (create inline object), создание template'ного объекта (create template object). Результаты теста приведены в таблице 1.
Таблица 1. Результаты тестирования скорости работы основных конструкций языка
VC++ Intel Compiler Bulder C++ MinGW (gcc)
virtual call 140 (9) 134 (9) 139 (9) 183 (12)
member call 124 (8) !34 (9) 103 (7) 154 (10)
static call 121 (8) 113 (7) 109 (7) 118 (8)
create object 606 (424) 663 (443) 459 (321) 619 (433)
create inline object 579 (405) 600 (420) 343 (240) 590 (413)
create temlate object 580 (405) 599 (419) 349 (244) 579 (405)
Первая цифра - это полное время, затраченное на тест (в миллисекундах); цифра в скобках - количество тактов на одну команду.

Результаты получились очень даже интересными: первое место занял Borland Builder, а вот gcc на вызове методов, особенно виртуальных, показал существенное отставание. По всей видимости - из-за бурного развития COM'а, где все вызовы виртуальные, разработчикам "родных" компиляторов под Win32 пришлось максимально оптимизировать эти типы вызовов. Другим интересным фактом является то, что хорошо оптимизировать создание объекта с inline-конструктором и деструктором смог, опять-таки, только Builder.

Конечно, у MSVC++ также наблюдается небольшой прирост производительности, но объясняется это тем, что MSVC++ очень хорошо "раскручивает" код и все заглушки просто выбрасывает. То есть в тесте с inline-вызовами MSVC++ определил, что вызываемый метод является пустым, и исключил его вызов. После исключения вызова пустого метода у него остался пустой цикл, который компилятор также выбросил.

Borland же в случае использования inline-конструктора делает inline не только вызов метода "Конструктор", но и выделение памяти под объект. То же самое делает Builder относительно деструктора. Любопытно отметить, что с шаблонами Builder работает точно так же, как с inline-методами, чего совершенно не скажешь о других компиляторах.

Тестирование STL

STL, как известно, входит в ISO стандарт C++ и содержит очень много полезного и превосходно реализованного кода, использование которого существенно облегчает жизнь программистам. Конечно, MCVC++, gcc и Builder используют различные реализации STL - и результаты тестирования будут сильно зависеть от эффективности реализации тех или иных алгоритмов, а не от качества самого компилятора. Но, так как STL входит в ISO-стандарт, тестирование этой библиотеки просто неотделимо от тестирования самого компилятора.

Проводилось тестирование только наиболее часто используемых классов STL: string, vector, map, sort. При тестировании string'а измерялась скорость конкатенации; для vector'а же - время добавления элемента (удаление не тестировалось, так как это просто тестирование realloc'а, которое будет проведено ниже); для map'а измерялось время добавления элемента и скорость поиска необходимого ключа; для sort'а - время сортировки. Так как Microsoft не рекомендует использовать STL в VC++, для сравнения было добавлено тестирование конкатенации строк на основе родного класса VC++ для работы со строками CString и, чтобы уж совсем никого не обидеть, то и родного класса Builder'а - AnsiString. Результаты, опять же, оказались очень даже интересными (см. табл. 2)
Таблица 2. Результаты тестирования STL
VC++ Intel Compiler Bulder C++ MinGW (gcc)
string add 8 (572) 11 (837) 3 (244) 2 (199)
AnsiString - - 11 (832) -
Cstring 106 (7476) 104 (7331) - -
sort 157 (10994) 156 (10943) 387 (27132) 226 (15848)
vector insert 110 (77) 96 (67) 63 (44) 56 (39)
map insert 1311 (1836) 1455 (2037) 848 (1148) 448 (627)
map find 181 (127) 4 (3) 418 (293) 199 (139)
Согласно результатам, не рекомендованный STL string работает в 12 раз быстрее, чем родной CString Microsoft! Как тут в очередной раз не задуматься о практичности рекомендаций Microsoft... А вот просто потрясающий результат на поиске от Intel Compiler это результат оптимизации "ничего не делающего кода" - поиск как таковой он просто выбросил из конечного бинарного кода. Не менее интересен результат gcc - во всех тестах, связанных с выделением памяти, gcc оказался на первом месте.

Тестирование менеджера памяти

Как известно, при выделении памяти malloc редко обращается напрямую к системе - и использует вместо этого свою внутреннюю структуру для динамического выделения памяти и изменения размера уже выделенного блока. Скорость работы этого внутреннего менеджера может весьма существенно влиять на скорость работы всего приложения. Тестирование менеджера памяти было разбито на две части: в первой измерялась скорость работы пары malloc/free, а во второй - malloc/realloc, причем realloc должен был выделить вдвое больший объем памяти, чем malloc.