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

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

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

Агрессивные алгоритмы оптимизации (за которые обычно отвечает ключ -O3), или, правильнее сказать, «пессимизации», зачастую дают результат, прямо противоположный ожидаемому. Увлеченные «продразверсткой» циклов и функций, они ощутимо увеличивают объем программного кода, что, в конечном счете, только снижает производительность. А глюки оптимизации? Впрочем, о глюках мы уже говорили.

Не нужно гнаться за прогрессом (а то ведь догонишь), но и не превращай верность традициям в религиозный фанатизм. Глупо отказываться от «лишней» производительности, если компилятор дает ее даром. Создатели GCC говорят о 30% превосходстве версии 3.0 над 2.95, однако далеко не все разработчики с этим согласны. Большинство вообще не обнаруживает никакого увеличения производительности, а некоторые даже отмечают замедление. Ничего удивительного! Алгоритмы оптимизации в GCC 3.x претерпели большие изменения. Одни появились, другие исчезли, так что в целом ситуация осталась неизменной. Только вот про поддержку новых процессоров не надо. С планированием кода они справляются сами (учет особенностей их поведения дает считанные проценты производительности, да и то на чисто вычислительных задачах), а новые векторные регистры и команды просто так не задействуешь. Одной перекомпиляции здесь недостаточно. Программный код должен использовать эти возможности явно. Эффективно векторизовать код не умеют даже суперкомпьютерные компиляторы. Во всяком случае, пока. Или, точнее, уже.

А что насчет сравнения 32-разрядного кода с 64-разрядным? Пользователь думает: 64 намного круче, чем 32, а следовательно, и быстрее! Начинающий программист: ну может, и не быстрее (все равно все тормозит ввод/вывод), но что не медленнее - это точно! А вот и нет. Бывалые программисты над этим только посмеиваются. Медленнее! Еще как медленнее! 32-разрядный код по сравнению с 16-разрядным в среднем потребляет в 2-2,5 раза больше памяти. 64-разрядный код - это вообще монстр, разваливающийся под собственной тяжестью. А ведь размер кэш-буферов и пропускная способность системной шины не безграничны! Широкая разрядность дает выигрыш лишь в узком кругу весьма специфических приложений, большей частью научных. Скажи, часто тебе приходится сталкиваться с числами порядка 18.446.744.073.709.551.615? Тогда с какой стати ждать ускорения?