Тестирование, сравнение Unix и Linux серверов
Гость 19 сентября, 2005 - 15:04
Если кто знает где можно посмотреть статистику тестирования работы различных дистрибутивов Unix и Linux серверов?
Расскажите чем я могу оценить производительность установленного gentoo, если
например если я соберу его с разными значениями флагов и т.п.?
»
- Для комментирования войдите или зарегистрируйтесь
Открываем ман
Открываем ман гсс. Считаем количество флагов, подходящих под наш камень. Вычисляем количество вариантов. Умножаем сие на количество дней, необходимых для пересборки. Думаю лет через 300 мы все это сможем сравнить.
Можно сказать emerge acovea. Такая программка. Флаги подбирает (за сутки). Можно просто написать -O3 -mmarch=.. msse (1 там или 2 или .. ) -m3dnow -mmmx -(особые фичи камня) получишь тоже самое. При этом не факт что эти флаги будут использоваться при сборке (например mplayery они по барабану ).
Вот что нарыл по тестам:
http://www.opennet.ru/prog/sml/42.shtml
PS
Особенностью задач оптимизации является невозможность найти идеального решения.
wi Спасибо за
wi Спасибо за ссылку!
Допустим такая задача: нужно собрать почтовый сервер(к примеру).
Если я отключу поддержку не нужных мне пакетов с помощью USE, это
как то повлияет на быстродействие этого почтового сервера или просто сборка пройдет быстрее?
Или вся оптимизация сводится к тому, что бы правильно указать под какой процессор собирается система?
PS
Извините, я новичек, поэтому есть вероятность, что не правильно формулирую вопросы.
Если важна скорость - все ненужное
Тут вот кто-то высказывался на тему, дескать Debian быстрее...
Тут все еще зависит от версий ПО... старое ПО обычно бустрее современного. я помню несколько лет назад на 486 с 16 мегами ядро собиралось ну часа два. а ныне - часов 20... gcc стал жутко продорливый... :) да и на 16 мегах вообще не реально жить. для консоли минимум надо 32 иметь. а для графики минимум 64.
Так вот... что касается скорости... поменьше серверов в памяти... опять таки держать только самое нужное... меньше свопинга - быстрее будет работать все.
Оптимизация конечно влияет... но думаю что между "-march=i386 -O2" и "-march=pentium4 -O2" разница будет практически незаметна. а как известно все бинарные дистры тоже не по -O0 точатся. :)
Хотя щас я это проверю. :)
сравнивал i386 и pentium3
разница в принципе существенная... 24% (ну правда на одной конкретно взятой задаче)
-O3 не сильно отличается от -O2 по скорости... ну может чуток выиграешь... а можно и проиграть. зато в расстоянии, всмысле в объеме точно проиграешь...
-Os проигрывает по скорости... примерно 25%, но почти столько же выигрывает по объему... (особенно на больших бинарях заметно) (а при активных операциях ввода вывода - проигрыш будет не столь ощутим, проигрывает то на числодроблении, зато экономия памяти на лицо. :) )
-ffast-math реально помогает на тех приложениях которые юзают FPU.
30% выигрыша по скорости можно получить.
А всяике mmx, sse и тд устанавливаются в соответствии с march. руками ставить их нет необходимости.
Собственно у
Собственно у линя прекрасный диспетчер задач. Неиспользуемые процессы отжирают как правило 0 процессорного времени. Поэтому степень их оптимизации как правило никого не интересует. У почтовика основная нагрузка придется на какойнить постфикс, спамассасин, кламав. Поставить, поработать,посмотреть загрузку. Ежели производительность не удовлетворяет (загрузка проца в рабочем режиме свыше 80), можно поковырять эти пакеты более пристально.
Отрубанием лишних юсов можно существенно ускорить работу приложения путем выбрасывания лишних проверок и ненужной функциональности. Более жестко - ручная сборка через configure пакета, либо правка ебилда (в том месте где он конфигурялку вызывает).
march действительно самая важная опция, заставляющая gcc юзать инструкции указанного проца. Она дает основной прирост производительности (процентов 20). Вообще -O3 как правило дает еще процентов 5-6 (он стразу тучу опций включает). Вылавливать остальное путем жонглирования опциями- неблагодарное занятие.
Кстати целая туча пакетов, судя по всему, игнорируют гентушные флаги. ИМХО правильно. Поскольку установка большинства флагов оптимизации - задача разработчика пакета, или дистрибьютера. Кто как не они исходники ковыряют.