Оптимизация сборки пакета
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
Оптимизация сборки пакета - 2010-01-31 22:47:09.923333
|
|
|
oneTrouble
Сообщений: 31
Оценки: 0
Присоединился: 2009-02-27 23:46:41.190000
|
Система Ubuntu 9.10 Karmic.
Задача сравнить время исполнения дефолтной сборки пакета с оптимизированной. Все стандартные пакеты для сборки установлены. Также стоит cmake.
Пакет для сборки не важен, но ищу простенькую прогу для сборки без проблем:)
Проблема в использовании CFLAGS. Поискав в гугле накопал что юзать так - CFLAGS="-O2 -march=prescott -mmmx -msse2 -pipe" make
пробовал и так ./configure CFLAGS="-O2 -march=prescott -mmmx -msse2 -pipe"
в обоих случаях выводит огромные логи и в конце концов ошибку. Экспериментировал на пакетах qutim0.2 и abiword2.6.8. Но видимо не самые простые для сборки пакеты выбрал.
Подскажите как правильно юзать CFLAGS и какие ключи нужно указывать при сборки для уменьшения времени исполнения программы?
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-01-31 23:52:02.853333
|
|
|
The Professor
Сообщений: 179
Оценки: 0
Присоединился: 2008-01-04 03:01:42.476666
|
CFLAGS – это переменная окружения (environment variable). Она показывает, как именно компилятор языка C должен собирать исходный код. Подробней здесь. Обычно указывают уровень оптимизации -O* (латинская O, вместо * пишется цифирка 1, 2 или 3, или буква s) и тип архитектуры процессора -march=* (вместо * пишется слово, типа i386, alpha, sparc, pentium3 и т.п.).
Сборка пакета с оптимизацией, установка и замер времени выглядит примерно так:CFLAGS="-O3 -march=[процессор/архитектура] -прочие_опции"; export CFLAGS
./configure --prefix=/путь --прочие_опции
make
make install #не запускать, не разобравшись до конца
time /путь/имя_программыПуть желательно выбирать нестандартный, чтобы не перезаписать существующую программу. Или вообще не инсталировать, а запускать из source tree.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-01 00:07:48.953333
|
|
|
oneTrouble
Сообщений: 31
Оценки: 0
Присоединился: 2009-02-27 23:46:41.190000
|
Спасибо за ответ. Буду пробовать.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-02 01:11:07.130000
|
|
|
oneTrouble
Сообщений: 31
Оценки: 0
Присоединился: 2009-02-27 23:46:41.190000
|
Собрал пакет pidgin 2.6.5.
Дефолтная сборка
real 1m 36.192s
user 0m 0.820s
sys 0m 0.240s
После оптимизации c CFLAGS="O3 -march=native -msse -msse2" :
real 0m 53.047s
user 0m 0.592s
sys 0m 0.180s
То есть улучшение присутствует). Я только не могу разобраться в значениях real, user, sys. Что они означают?
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-02 10:26:41.830000
|
|
|
The Professor
Сообщений: 179
Оценки: 0
Присоединился: 2008-01-04 03:01:42.476666
|
quote:
ORIGINAL: oneTrouble
Я только не могу разобраться в значениях real, user, sys. Что они означают? Для начала примите мои поздравления. Вы научились оптимизировать прикладные программы.
Краткое объяснение терминов real, user и sys:
- real – фактическое время от запуска программы до завершения (если "одновременно" выполняется много процессов, то real будет выше, ибо очередь)
- user – время, которое процессор потратил на исполнение программы (user-space)
- sys – время, которое процессор потратил на исполнение части программы, связанной с ядром (kernel-space). Или наоборот, которое процессор потратил на исполение команд ядра, связанных с программой. Что суть одно и тоже.
Общее время, затраченное процессором на выполнение всего, что связано с вашей прикладной программой, рассчитывается как сумма user и sys.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-02 11:35:17.706666
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: oneTrouble
Собрал пакет pidgin 2.6.5.
Дефолтная сборка
real 1m 36.192s
user 0m 0.820s
sys 0m 0.240s
После оптимизации c CFLAGS="O3 -march=native -msse -msse2" :
real 0m 53.047s
user 0m 0.592s
sys 0m 0.180s
То есть улучшение присутствует). Я только не могу разобраться в значениях real, user, sys. Что они означают?
Эммм. Не хочется огорчать но всё же истина важнее… У меня есть подозрение что налицо ухудшение. Смотри, pidgin во второй раз отработал в два раза меньше времени (real меньше). Надо ожидать что и user и sys время будут тоже в два раза меньше. Но это не так.
Я бы на твоём месте не использовал -O3 – эта опция тупо врубает все оптимизации по скорости, но как написано в мануале к gcc вовсе не факт что программа от этого станет быстрее, поскольку она просто может стать толще, и на этом потеряет больше. Надо использовать -O2, стОит использовать всякие -m опции (которые у тебя вроде есть) и к ней имеет смысл присобачить ряд -f… опций.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-02 11:38:30.370000
|
|
|
The Joker
Сообщений: 3485
Оценки: 99
Присоединился: 2008-10-07 16:22:13.730000
|
А что значит "отработал"? Он сам умер?
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-02 12:46:18.430000
|
|
|
oneTrouble
Сообщений: 31
Оценки: 0
Присоединился: 2009-02-27 23:46:41.190000
|
нет. пиджин не умирал. я его сам отрубал для получения результатов time. Видимо надо добиться одинакового значения real
для нормального сравнения улучшения
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-04 16:26:32.256666
|
|
|
oneTrouble
Сообщений: 31
Оценки: 0
Присоединился: 2009-02-27 23:46:41.190000
|
Еще один вопрос, возможно глупый, но я не догоняю. Как после экспортирования CFLAGS с параметрами оптимизации собирать дефолтные сборки? То есть при стандартном - ./configure && make && make install пакеты будут автоматически собираться с CFLAGS ? то есть CFLAGS так и остается в окружении?
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-04 18:02:00.800000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
Переменные окружения живут лишь в том процессе, который их выставил и передаются в дочерние процессы при старте этих дочерних процессов. Если ты в командной строке сказал export CFLAGS="…", то все ./configure которые ты после этого запустишь, будут использовать эти CFLAGS (им интерпретатор командной строки bash передаст при запуске). Но если ты запустишь ещё один терминал, там будет другой процесс bash, который вовсе не потомок первого, и переменные окружения естественно не унаследовал. И если ты во втором bash запустишь ./configure, то твои CFLAGS, понятно дело, никак не повлияют.
Можно вписать export CFLAGS="…" в ~/.bash_profile, тогда каждый запускаемый bash будет их использовать и передавать всем дочерним процессам. Можно вписать в /etc/profile, тогда все пользователи будут иметь твои CFLAGS в окружении.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-04 21:22:08.523333
|
|
|
oRb
Сообщений: 4044
Оценки: 597
Присоединился: 2007-03-28 18:45:06.630000
|
Как-то включать/выключать прогу, используя time - не тест. Надо что-нить по серьезней. Единственное что вспоминается - это один хабраюзер тестил сборки firefox'а. Вот там уже можно с помощью каких-нибудь тестов (js, рендер страниц, еtс) сравнить билды.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-05 06:04:17.126666
|
|
|
The Joker
Сообщений: 3485
Оценки: 99
Присоединился: 2008-10-07 16:22:13.730000
|
А я о чём спрашивал ТСа? time меряет время работы программы от старта до завершения. Я могу оставить вашего пигжина на трое суток и потом кричать по всем форумам, что он зверски тормозит.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-06 16:05:58.050000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: oRb
Как-то включать/выключать прогу, используя time - не тест. Надо что-нить по серьезней.
Угу. Напрашивается собирать билды с опцией -pg. И если речь идёт о пидгине, то гонять каждую сборку по паре недель, для набора статистики. Ну или, можно сократить время, но придётся с пидгина флудить нипадеццки, и принимать горы флуда. А потом ещё анализировать результаты профайлинга, пытаясь учесть то, что -pg вообще-то несколько изменяет поведение компилятора, и полученные результаты не совсем соответствуют действительности. С этим тоже можно бороться, расставляя в коде подсказки профайлеру, какие функции надо профилировать, а какие – нет. Если речь идёт о пидгине, то пару недель в измерение производительности убить можно не глядя. А если взяться всерьёз, то я думаю можно и больше.
Но на самом деле проблема не в выборе инструмента измерения, а в выборе программы для оптимизации. icq-клиент, сильно неудачен тем, что он при нормальных условиях не тормозит нисколько. Пиджин можно целиком переписать на python'е, perl'е или ещё чём-нибудь в том роде, и не заметить разницы.
|
|
|
|
|
RE: Оптимизация сборки пакета - 2010-02-06 22:39:35.323333
|
|
|
oneTrouble
Сообщений: 31
Оценки: 0
Присоединился: 2009-02-27 23:46:41.190000
|
Изначальная задача заключалась в том чтобы показать работу с CFLAGS. Никаких серьезных тестов производительности делать не собирался, да и не смог бы. Тему можно по идее закрывать, так как ответы получены. Спасибо всем!
|
|
|
|
|
|
