distruktor 02.02.2010 19:16
Я Фанатег! — Тест скорости "пересобранного" ядра
Принцип прост, пересобираем ядро с оптимизацией под свою машину с предварительной командой time, после чего делаем холостую сборку этого же ядра, с все той же командой time и делимся временем первой и второй сборки, желательно со скринами результата, что и будет покажет прирост производительности. Ну и естественно, результаты можно разбить по принципу примерной мощности тестовых машин. А лучшие результаты можно будет поощрить как то. Как? А это и предлагаем в комментариях... Ну и я не знал в какой топик вставить и решил что это увлечение для истинных красноглазиков :)
Похожие
Поделиться
predator 02.02.2010 19:23 #
+ 1 -
я че-то непонял, а разве время первой и второй сборки не должны совпадать? использование distcc или ccache позволительно? =)
distruktor
Первая сборка производится в системе с запущенным стандартным ядром, вторая после загрузки в оптимизированном ядре... Производить лучше в init 3 без дополнительных ускорений (не встроенных в ядро)...
неужели настолько можно оптимизировать ядро, что компилиться будет быстрее? наверно имеется ввиду использование какого-нибудь zen-source, а?
И ещё вопрос: если запустить make с nice -20 этот параметр передастся дочерним процессам(тобишь gcc)?
И ещё вопрос: если запустить make с nice -20 этот параметр передастся дочерним процессам(тобишь gcc)?
Компилиться будет быстрее как правило на небольшой период времени около 10-20 секунд, особенно при многопроцессорной конфигурации и в несколько потоков...
warchief
В общем вот результат на моей конфигурации: сборка 2.6.32.8 на ядре, из коробки, 2.6.31.19 длилась 35 минут, даже при exprot CONCURRENCY_LEVEL=5 процессор не был загружен на 100% и работал в режиме ondemand на частоте 1,6 вместо 2,4Ггц.
Сейчас собрал 2.6.32.8 на 2.6.32.8 вот результат: real 10m34.011s
user 26m4.153s
sys 4m29.765s
Отчего такая разница я не знаю о.О
Сейчас собрал 2.6.32.8 на 2.6.32.8 вот результат: real 10m34.011s
user 26m4.153s
sys 4m29.765s
Отчего такая разница я не знаю о.О
Jazz
Лучше rm -rf /*
Конфиги у всех разные. Процессор, жёсткий диск (а вдруг у кого скоростной SSD от Intel? :), набор читов тоже.
ТС! Прогуляйся. А это — очень странный способ убить время.
Конфиги у всех разные. Процессор, жёсткий диск (а вдруг у кого скоростной SSD от Intel? :), набор читов тоже.
ТС! Прогуляйся. А это — очень странный способ убить время.
snowemo
да хотя бы для интереса до чего можно довести систему. узнать возможности.
booley
exelens
Лучше rm -rf /*
не нужно показывать такие команды.
У Всех уровень знаний разный.
лучше сразу показывать патч Бармина. мужик долго изучал вопрос решения самых распространенных проблем в юниксподобных, и мы благодарны ему за это :)
Ну я сомневаюсь что тут есть люди которые еще не знают таких команд :) Поэтому то что их подкидывают, это больше говорит о уровне тех кто такие советы дает...
Оптимизировать ядро, чтобы что-то быстрее компилялось? Странно... А я обычно компилятор конфигурил с его опциями. Ну и libc и т.д.
digiwhite
Username
HTaeD
devl547
Давай соберу тебе make allnoconfig -j8 на tmpfs.
Не заработает, зато быстро.
Не заработает, зато быстро.
вот собрал 6.32(удалять из него уже почти? нечего), правда уже на несколько настроенном ядре(компиляция текущего ядра проводилась на серийном ядре и помоему заняла около 40 минут, правда там был cocurrency_lever=4 a сейчас 5). Как выйдет 6.33 я соберу его на этом 6.32. Посмотрим, что получится, а пока вот результат:
real 12m23.342s
user 30m22.528s
sys 5m26.117s
Интересно, если сделать раздел в оперативной памяти и там ядро/или просто что-то большое насколько скорость будет выше? о.О
real 12m23.342s
user 30m22.528s
sys 5m26.117s
Интересно, если сделать раздел в оперативной памяти и там ядро/или просто что-то большое насколько скорость будет выше? о.О
