внезапно

bzip gzip p7zip lame mencoder

Это заметно только на отдельных приложениях. Причём можно наоптимизировать производительность как в плюс, так и в минус.

А вот разница общей производительности будет скорей всего на уровне погрешности измерения.

И чем меньше CLAGS в make.conf, тем быстрее будет система.

Вот и интересно измерить эту погрешность) Как, например, измерить разницу в скорости работы отдельных приложений, например скорость запуска firefox или скорость работы того же окуляра в кедах?

>>bzip gzip p7zip lame mencoder

эти программы изначально дают субъективную оценку.

>И чем меньше CLAGS в make.conf, тем быстрее будет система.

Т.е. CLAGS=«» обеспечит максимальную производительность?

С чего вдруг?

> измерить разницу в скорости работы отдельных приложений, например *скорость ***запуска*** firefox*

Скорость запуска и скорость работы вообще перпендикулярны.
Хочешь быстрее запускать, делай прелинк, прелоад и т.д. Выставляй правильный LDFLAGS.
Некоторые ещё по скорости загрузки системы о её быстродействии судят, бггг.

> CLAGS=«»

Видимо чем меньше LAGS при сборке С-кода, тем быстрее маш.код. :D

Конечно. Смело делай, потом отпишешься о получившемся.

>делай прелинк, прелоад

Это уже из разряда вредных советов.

ну а как тогда измерить? просто хочется для себя понять, что при такой-то сборке системы и таких-то параметрах основная масса приложений работает на, скажем, 20% быстрее, а не «Вау, на гента все летает» или наоборот.

>при такой-то сборке системы и таких-то параметрах основная масса приложений работает на, скажем, 20% быстрее

Двадцать процентов прироста ты получишь на некоторых единичных пакетах типа архиваторов и кодировщиков видео/аудио, при условии что правильно подберёшь CFLAGS.

>ну а как тогда измерить?

Натыкать в коде { gettimeofday(); printf(); }.

как мне эти 20% увидеть? суть вопроса именно в объективности тестирования!

>суть вопроса ... в объективности

Так чем тест софтинами в первом посте необъективен?

>как мне эти 20% увидеть?

time bla-bla-bla

>Двадцать процентов прироста ты получишь на некоторых единичных пакетах типа архиваторов и кодировщиков видео/аудио, при условии что правильно подберёшь CFLAGS.

Кроме того еще прирост заметен на слабых на сегодняшний день машинах.
P.S. Гемора с компиляцией получишь много.
P.P.S Если проц Интеловский то стоит посмотреть в сторону их компилятора.

>Кроме того еще прирост заметен на слабых на сегодняшний день машинах.

Наоборот, больше всего прироста на более-менее современных камнях.

>>Так чем тест софтинами в первом посте необъективен?

Предположим я получил 20% прироста в скорости скажем для gzip. Что это мне говорит? а говорит только то, что у меня быстрее стал работать gzip. Возникает вопрос - это у меня так классно gzip собран или что-то другое?

>это у меня так классно gzip собран

Да.

> как мне эти 20% увидеть?

Запусти mplayer с фильмом. Если фильм закончился на 20% времени раньше, то считай свой объективный выигрыш ты увидел. :D

Если серьёзно, то сейчас железо настолько быстрое, что этим можно не заморачиваться, а ориентироваться на стабильность+безопасность приложений.

Я например на глаз уже давно не замечаю разницы у оперы, фокса и хрома. Потому что лимитирует другой фактор — жирность канала, а не быстродействие процессора и видеосистемы.

Запусти atop, пособирай статистику с его помощью. Увидишь на что приходится максимальная загрузка процессора. Если оптимизировать на быстродействие именно эти процессы, то средневзвешенное быстродействие системы увеличится.
Смысла в оптимизации программы, которую ты запускаешь пять минут в месяц нет. Особенно, если оптимизация может снизить стабильность.

>Если серьёзно, то сейчас железо настолько быстрое, что этим можно не заморачиваться, а ориентироваться на стабильность+безопасность приложений.

От задачи зависит. Я недавно doxygen'ом код парсил, весом в 400М... 2е суток работало(( а могло наверно быстрее, если бы doxygen был собран под 2х ядерный проц(это догадка). В htop'e было явно видно - используется 1 ядро.

Неправда. Или ты о -Ox?

>это у меня так классно gzip собран

Да(внезапно).

Нет. Я о тучах всяких floop-* и ftree-*.

> а могло наверно быстрее, если бы doxygen был собран под 2х ядерный проц(это догадка)

Нет. Не будет он параллелиться.

floop-parallelize-all?

Пакеты с этим флагом либо не собираются, либо не работают.

Не знаю, как там с приложениями, но, судя по отзвывам, кеды в ней летают, тогда как в той же конфигурации и на том же железе в арче подтормаживают.

хорош уже херню пороть!

1. Ты сам говорил, что preload не пойми как работает и профита от него нуль. Мой опыт, в принципе, это подтверждает. 2. Prelink как будто ускоряет запуск приложений, однако ощутимого прироста я ни разу не видел. Зато проблем от него достаточно. Ты сам же тут плакал, что обновление glibc ломает всю систему, пролопаченную прелинком. Так что, в общем и целом, обе эти приблуды - чуйня полная.

1. согласен
2. дело не в прелинке, а в глибц было - причём только в одном релизе
прелинк даёт ощутимый профит как в скорости запуска софта, так и в потреблении памяти
и да - я не плакал - ибо я 2.13 никогда и не ставил себе - мне вовремя доложили о косяке
итого - прелинк няшка

>дело не в прелинке, а в глибц было - причём только в одном релизе

Ладно.

прелинк даёт ощутимый профит как в скорости запуска софта, так и в потреблении памяти

Ничего такого не ощущал.

Секундомер

как быть с демонами?

ну, а я ощутил - и не я один
так же есть маленький хак иксолиб по поводу локалей
mkdir ~/.compose-cache
да - 100500% профита ты не увидишь, маленький сцуко, но он есть
и такими маленькими твиками в итоге получается довольно шустрая системка
скажем либа jpeg с использованием SIMD даёт профит.
либе без SIMD надо 150% времени на отрисовку картинки *.jpg, если за 100 взять время необходимое либе с SIMD
казалось бы - на отрисовку картинки уходит ничтожно малое кол-во времени, но на обычной либе отрисовка жопегов проиходит с примерно той же скоростью, что и пнг
НО! с турбо-либой жопеги так быстро отрисовываются, что пнг выглядит полным дерьмом

bootchart (или как-то так)?

>mkdir ~/.compose-cache

Это в tmpfs засунуть надо? Что там хранится?

либа jpeg с использованием SIMD

turbojpeg уже стабилен?

давно стабилен

Это в tmpfs засунуть надо? Что там хранится?

это надо от юзера сделать в терминале

[ megabaks@desktop ] ~ $ ls -lh .compose-cache/
итого 300K
-rw------- 1 megabaks 1018 296K Фев 27 15:28 l4_024_313cb605_00280cc0
[ megabaks@desktop ] ~ $ 

результат распарсивания кучи строк кода, который происходит при запуске каждой софтины
с этим твиком сие происходит один раз

>Наоборот, больше всего прироста на более-менее современных камнях.

Ну там зависит от флагов.Я по крайней мере на старых больше ускорение видел,но опять таки оно было небольщим(10-30%)
Кроме того современные процы намного лучше оптимизируют свое выполнение.

>>оно было небольщим(10-30%)

на глаз?

>на глаз?

Большинство,да.
P.S Щас может рассказ стал другим.Ибо замеры делал года 3 назад.

какие именно замеры? можно подробнее?

>какие именно замеры? можно подробнее?

Ну просто оценка загрузки приложений,скорость браузера.Но это все на глаз.Щас все детали не вспомню
По оптимизации лучше у silvy спроси

По-нормальному это делается так (и выяснятся заодно 'это gzip или glibc стало быстрее?') берётся система gentoo и эталон и запускается _oprofile_. в нём смотрится для конкретного бинарника разделение по функциям. Обычно видно где быстрее где медленнее.

выглядит примерно так: http://www.bsdmn.com/openmoko/glamo/oprofile/mplayerfbdev.png