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

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

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

Со времен GCC 2.95 поддержка плюсов претерпела существенные изменения. В основном положительные. Контроль за ошибками ужесточился. Это хорошо, хотя внешние верификаторы кода типа LINT еще никто не отменял, и во многих случаях они предпочтительнее. А вот с классическим Си появились проблемы. Оптимисты верят, что он компилируется не хуже, чем вчера. Пессимисты же закидывают их дизассемблерными листингами, убеждающими, что новые версии GCC генерируют более громоздкий и менее эффективный код, а часть конструкций не компилируется вообще!

Объем программ, компилируемых только теми версиями компиляторов, под которыми они разрабатывались, в действительности очень велик. И неважно, где зарыта ошибка - в листинге программы или компиляторе, - пользователям от этого не становится легче. Древний GCC 2.95 поддерживается большинством производителей и генерирует достаточно качественный даже по сегодняшним меркам код. Поэтому-то составители нормальных дистрибутивов и устанавливают его основным системным компилятором по умолчанию, оттесняя всех конкурентов в порты.

По утверждению фирмы Intel, ICC практически полностью совместим с GCC. Он нормально компилирует линуховое ядро версии 2.4, однако спотыкается на 2.6, требуя специальных заплаток. Одна правит исходный код ядра, другая - сам компилятор. Прикладное программное обеспечение без напильника и ритуальных танцев с бубном также не обходится.

В общем, слабонервным товарищам на эффективность лучше забить. Оставь GCC 2.95 основным системным компилятором и никуда от него не уходи.

Качество оптимизации или мегагерцы, спрессованные в стрелу времени

Компилировать надо компилятором, а оптимизировать - головой. Оптимизирующий компилятор увеличивает скорость программы главным образом за счет того, что выбивает из нее весь пух. Чем качественнее исходный код, тем меньший выигрыш дает оптимизатор, которому остается всего лишь заменять деление умножением, а умножение логическими сдвигами и планировать потоки команд. «Четверки» и первые модели Пней имели довольно запутанный ритуал спаривания, и для достижения наивысшей производительности машинные инструкции приходилось радикально переупорядочивать, причем расчет оптимальной последовательности представлял собой весьма нетривиальную задачу, из-за чего качество оптимизации разнилось от одного компилятора к другому. Но с появлением Pentium Pro/AMD K5 эта проблема сразу стала неактуальной - процессоры поумнели настолько, что научились переупорядочивать машинные команды самостоятельно, и интеллектуальность оптимизирующих компиляторов отошла на второй план.

Не стоит, право же, гнаться за новыми версиями оптимизаторов. Эта технология достигла своего насыщения уже в середине девяностых, и никаких прорывов с тех пор не происходило. Поддержка мультимедийных SSE/3DNow!-команд воздействует только на мультимедийные и отчасти математические приложения, а всем остальным от нее ни жарко, ни холодно. Кривую от рождения программу оптимизатор все равно не исправит, а грамотно спроектированный код равномерно распределяет нагрузку по всем функциональным узлам, и без острой необходимости лучше его не ускорять. Возьмем сетевое приложение. Оптимизация программного кода увеличивает количество обрабатываемых запросов, что, в свою очередь, увеличивает нагрузку на сеть, и общая производительность не только не возрастет, но может даже упасть.