Linux Gazette на русском | Выпуск #119 |
Тираж 8387 экз.
"Жажда скорости..."
Здравствуйте! Вашему вниманию предлагается статья, описывающая
сколько ещё строк-в-секунду можно выжать из GCC, если поиграть соответствующими
ключами.
Я - один из счастливых обладателей процессора Pentium 3 866Mhz.
Всё было прекрасно, жизнь била ключом [Примерно 45-го размера. :-) Прим.ред.], пока я не прочитал статью с freashmeat
на тему оптимизации GCC [После этого ключ заменил обух. :-) Прим.ред.]. Статья заставила меня
призадуматься вот над каким вопросом: насколько
быстрее gcc будет компилировать ядро, если его самого [gcc] немного
оптимизировать? Недолго думая, я приступил к делу. Для начала я
решил засечь время, затрачиваемое на компиляцию ядра без
оптимизации. Думаю, что большинство пользователей Линукс рано или
поздно приходят к тому, чтобы собрать своё ядро, так что
надеюсь мой тест окажется кому-нибудь полезным. Итак, условия теста
таковы:
Сделать 10 контрольных компиляций ядра и таким образом
вычислить среднее время.
Сборка обычным gcc.
Сборка оптимизированным gcc.
Версия ядра - самая последняя из стабильной ветки.
На данный момент это версия 2.4.20.
Версия GCC тоже самая последняя из стабильных.
На данный момент это версия 3.2.2.
И вот результаты, полученные при сборке неоптимизированным
компилятором (configure;make;make install)
Среднее время, вычисленное из 10 запусков 'make bzImage':
12.42 минут (762 секунды)
Для оптимизации компилятора я использовал следующие ключи:
Если вам любопытно узнать как это сделать, то почитайте FAQ в
архиве с gcc. Я например, поступил следующим образом:
./configure ; make BOOT_CFLAGS="ключи оптимизации" bootstrap ; make install
Среднее время, вычисленное из 10 запусков 10 'make bzImage'
9.31 минут (571 секунд)
Вообще я скомпилировал практически всё, чем я пользуюсь на своей
Линукс-машине. Если кому интересно, то для управления
установленными пакетами я пользуюсь менеджером relink.
По результатам теста видно, что мы получаем прирост в скорости
компиляции на 33% (3:11 минуты, или на 191 секунду быстрее). Это
может показаться не ахти каким результатом, но при сборке
больших программ (например QT или Mozilla) эта разница будет уже
существенна. Замер времени для теста я сделал при помощи следующего
несложного скрипта:
cd /usr/src/Linux
for i in seq 1 10
do
make dep
make clean
/usr/bin/time bzImage 2>> /home/war/log
done
А вот сведения о затраченном времени и средней загрузке
процессора для каждой сборки:
Обратите внимание, что для оптимизации я применил не самый
лучший метод (использовал -fomit-frame-pointer), в частности для
отладки. Тем не менее, моей целью было увеличение
производительности компилятора, поэтому об остальном я не особо
заботился.
Команда переводчиков: Владимир Меренков, Александр Михайлов, Иван Песин, Сергей
Скороходов, Александр Саввин, Роман Шумихин, Александр Куприн,
Андрей Киселев, Игорь Яровинский, Юрий Прушинский
Со всеми предложениями, идеями и комментариями обращайтесь к
Александру Куприну (lgrus@lrn.ru). Убедительная
просьба: указывайте сразу, не возражаете ли Вы против публикации
Ваших отзывов в рассылке.