LINUX.ORG.RU

Тесты производительности


0

1

Вот с установкой генты мне стало интересно, на сколько она быстрее или может где-то медленнее работает параллельно установленного арча. Субъективно, гента быстрее, но хочется увидеть в процентном соотношении проведя тестирование систем. Кто знает, как можно протестировать системы?

★★

Последнее исправление: Berluskoni (всего исправлений: 1)

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

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

Lumi ★★★★★
()
Ответ на: комментарий от Lumi

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

Berluskoni ★★
() автор топика
Ответ на: комментарий от CTAPK

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

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

madcore ★★★★★
()
Ответ на: комментарий от Berluskoni

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

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

Lumi ★★★★★
()
Ответ на: комментарий от madcore

> CLAGS=«»

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

Lumi ★★★★★
()
Ответ на: комментарий от madcore

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

CTAPK
()
Ответ на: комментарий от Lumi

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

Berluskoni ★★
() автор топика
Ответ на: комментарий от Berluskoni

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

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

CTAPK
()
Ответ на: комментарий от Berluskoni

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

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

anon_666
()
Ответ на: комментарий от CTAPK

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

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

pinachet ★★★★★
()
Ответ на: комментарий от pinachet

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

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

CTAPK
()
Ответ на: комментарий от anon_666

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

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

Berluskoni ★★
() автор топика
Ответ на: комментарий от Berluskoni

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

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

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

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

Lumi ★★★★★
()
Ответ на: комментарий от Berluskoni

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

Lumi ★★★★★
()
Ответ на: комментарий от Lumi

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

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

Berluskoni ★★
() автор топика
Ответ на: комментарий от Berluskoni

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

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

Lumi ★★★★★
()
Ответ на: комментарий от anonymous

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

CTAPK
()

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

Zhbert ★★★★★
()
Ответ на: комментарий от megabaks

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

CTAPK
()
Ответ на: комментарий от CTAPK

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

megabaks ★★★★
()
Ответ на: комментарий от megabaks

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

Ладно.

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

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

CTAPK
()
Ответ на: комментарий от CTAPK

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

megabaks ★★★★
()
Ответ на: комментарий от CTAPK

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

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

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

megabaks ★★★★
()
Ответ на: комментарий от CTAPK
[ megabaks@desktop ] ~ $ ls -lh .compose-cache/
итого 300K
-rw------- 1 megabaks 1018 296K Фев 27 15:28 l4_024_313cb605_00280cc0
[ megabaks@desktop ] ~ $ 

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

megabaks ★★★★
()
Ответ на: комментарий от CTAPK

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

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

pinachet ★★★★★
()
Ответ на: комментарий от Berluskoni

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

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

pinachet ★★★★★
()

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

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

gena2x ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.