Подбери себе компилер

Крис Касперски ака мыщъх

Хакер, номер #075, стр. 075-102-1

Гонки на вымирание, девяносто пятые выживают

Среди компиляторов хороших и разных, как выбрать единственно правильный свой? Не верь ни советам друзей, ни рекламным листовкам, ни даже этой статье. Но все-таки ее прочитай. Так ты узнаешь сильные и слабые стороны популярных компиляторов и найдешь сравнительные тесты их быстродействия.

Введение

Сравнение компиляторов - бесперспективное дело. Религиозные войны. Фанатизм. Бенчмарки. Объективных критериев оценки ни у кого нет, да и не может быть по определению. Всегда найдутся условия, при которых твой компилятор уделает всех остальных. Комплексные тесты все только запутывают. Отображаемая ими «среднегодовая температура» не имеет ничего общего ни с тропической жарой, ни с арктическими морозами. Может, человеку целочисленное приложение компилировать надо, а основной вклад в комплексный тест дают плавающие операции.

Адепты максимальной оптимизации, собирающие все пакеты вручную, испытывают большие трудности с выбором «единственно правильного» компилятора. Многообразие версий GCC их угнетает, а тут еще мощный конкурент в лице Intel нарисовался. Основным системным компилятором большинство дистрибутивов Линуха назначают GCC 2.95. В портах лежит GCC 3.2/GCC 3.3. Более свежие версии приходится добывать в интернете самостоятельно.

Возникает естественный вопрос: оправдывает ли себя переход с GCC 2.95 на GCC 3.x или, может быть, лучше эмигрировать на другой компилятор? Если говорить кратко, на вкус и цвет товарищей нет. GCC 2.95 - это максимальная совместимость и быстрота компиляции. ICC 8.x - наивысшая производительность откомпилированного кода. GCC 3.x - рекордсмен по оптимизации векторных приложений под Атлон и другие процессоры фирмы AMD. А теперь обо всем этом и многом другом поподробнее.

Два лагеря - пользователи и программисты

Требования, предъявляемые программистами к компилятору, совсем не те, что у пользователей. Лозунг "Время трансляции имеет значение!" отвергается пользовательским сообществом как маразм, не требующий объяснения. В самом деле, какой процент своего времени тратит на перекомпиляцию рядовой линуксоид? А программист? Пользователю глубоко начхать, час или два оно будет компилироваться. Главное, чтобы получился хороший машинный код. Все остальное несущественно. Программисты же на первое место выдвигают именно скорость трансляции, а к быстродействию собственной продукции они, в общем-то, равнодушны, даже если им же на ней и работать.

Достоинство GCC 2.95 в его быстроте. Версии 3.x компилируют программы чуть ли не в два раза медленнее, а ведь время - это не только деньги, но и срыв всех сроков разработки. Обновить компьютер? Но многие и так работают на самом мощном железе, которое только доступно, да и не будет никто просто так выкладывать деньги только затем, чтобы перейти на новую версию GCC, когда и старая еще неплохо работает.

К новомодным, а значит, еще не обкатанным алгоритмам агрессивной оптимизации программисты относятся весьма настороженно, можно даже сказать, скептически. Ведь за мизерное увеличение производительности зачастую приходится расплачиваться потерей работоспособности программы. Рассмотрим следующий код: for (a = 0; a < func(); a++). Очевидно, что функция func() инвариантна по отношению к циклу и с математической точки зрения может быть вынесена за его пределы. Однако перед этим оптимизатор должен проанализировать ее тело - вдруг там присутствуют побочные эффекты типа вызова printf, модификации статической/глобальной переменной, обращения к портам ввода/вывода, передачи управления по указателю и т.д., и не факт, что транслятор это заметит. Использование оптимизации в GCC 3.x напоминает хождение по минному полю - такое количество ошибок скрывается в компиляторе.

Содержание  Вперед на стр. 075-102-2
ttfb: 800.47702789307 ms