Тесты производительности (различных ядер)

[polachok]

Решил провести собственное расследование по мотивам http://www.linuxforum.ru/index.php?showtopic=10526
Железо: PIII-866 256 mb RAM
uname -a FreeBSD darkstar 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Oct 2 10:04:00 MSD 2005 root@darkstar:/usr/obj/usr/src/sys/MICROKERNEL i386

1. Ядро номер уно.
Codename: MICROKERNEL
Конфиг: MICROKERNEL.txt
Результат:
FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Sep 29 20:31:06 MSD 2005 roo
t@darkstar:/usr/obj/usr/src/sys/MICROKERNEL i386
Ubench CPU: 24984
Ubench MEM: 25636
--------------------
Ubench AVG: 25310
Примечание: убрал из ядра почти все что можно
Kldstat
Id Refs Address Size Name
1 21 0xc0400000 374a28 kernel
3 1 0xc0779000 5628 vesa.ko
4 1 0xc07d0000 55f4 snd_cmi.ko
5 10 0xc07d6000 15828 agp.ko
6 1 0xc07ec000 96bc sio.ko
7 1 0xc1365000 3000 daemon_saver.ko
8 1 0xc1c16000 69000 ltmdm.ko
9 1 0xc1e4c000 2000 cd9660_iconv.ko
10 1 0xc1e4e000 4000 libiconv.ko
11 1 0xc1e5a000 8000 cd9660.ko

2. Ядро номер два.
Codename: MICROKERNEL-WOP
Конфиг: MICROKERNEL-WOP.txt
Результат:
FreeBSD 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Oct 2 10:04:00 MSD 2005 roo
t@darkstar:/usr/obj/usr/src/sys/MICROKERNEL-WOP i386
Ubench CPU: 33039
Ubench MEM: 24361
--------------------
Ubench AVG: 28700
Примечание: то же , что и 1, но отключена опция PREEMPTION

метод тестирования: Unix Benchmark Utility v.0.3 в атерме.
запущенные приложения:
gaim
firefox
beep-media-player
aterm
ppp
fvwm
torsmo


конфиги:

[alv]

а варианты интерпретации?
напрашивающийся ответ - что сам по себе ubench (1999 года розлива, если не ошибаюсь) на современных конфигурациях врет, как сивый мерин
или как незабвенный Norton SysInfo

[polachok]

не стоит также забывать что моя конфигурация как раз тех времен. 2000-2001 год.
вывод: выкидываем из ядра PREEMPTION.
ожидаются еще тесты более монолитными ядрами.

[Bruce]

от preemption не отказываться - это всё, на самом деле, не так очевидно. если его отрубить - да, вычисления будут быстрее, но зато медленнее переключение процессов, а следовательно - весь гуй будет медленнее (на вид) работать. время отклика понизится и т.д. вот у меня стоит нитро патч - да, гуй стал быстрее, но вычисления - нет.

[zenwolf]

ubench не стоит верить - я погонял тоже на разных вариациях
freebsd и парочку линуксов - результаты мягко говоря неадеватные

[polachok]

а следовательно - весь гуй будет медленнее (на вид) работать. время отклика понизится и т.д

у меня aterm запускается при этом быстрее - а это мне важно.

вот у меня стоит нитро патч - да, гуй стал быстрее, но вычисления - нет.

нитро есть и для freebsd? вы ничего не путаете? тогда линк в студию!

PS сейчас сделаю тест с ядром от сегодня. (те были недельной давности) - в ядре изменений много.

об утилитах benchmarking'а - может попробовать unixbench?

[alv]

об утилитах benchmarking'а - может попробовать unixbench?

попробуй, потом расскажешь
про ubench я тут внимательно почитал - это тестик уровня norton si, так что каких таких попугаев он меряет - не очень понятно

[Bruce]

нитро есть и для freebsd? вы ничего не путаете? тогда линк в студию

я имел в виду для линукса. просто идея его в том, что многозадачность настраивается более гибко, чем в оригинале (т.е. вообще никак). ну если без preemt на самом деле быстрее пашет - я не против, у меня не так под линуксом.

[polachok]

дело в том что во FreeBSD PREEMPTION только для ядра, в этом его проблема, наверное. а суть его в том что выполняемый процесс может быть заменен процессом с большим приоритетом, даже если не его очередь.

вообще, по идее, так и должно быть, как Вы описываете, т.е. быстрее.

ядро номер 2 сегодняшнее, HZ=50
Ubench CPU: 37955
Ubench MEM: 25647
--------------------
Ubench AVG: 31801
вывод: изменения в SCHED_ULE пошли на пользу.

PS скоро будут результаты unixbench.

[Bruce]

а HZ нельзя сделать 1000? мне так больше понравилось (в линуксе)

[polachok]

можно попробую... я вот как раз и занимаюсь поиском оптимальной конфигурации ядра.

[polachok]

та же конфигурация, тест unixbench
BYTE UNIX Benchmarks (Version 4.1.0)
System -- darkstar
Start Benchmark Run: воскресенье, 2 октября 2005 г. 20:01:12 (MSD)
5 interactive users.
20:01 up 38 mins, 4 users, load averages: 0,23 0,31 0,43
-r-xr-xr-x 1 root wheel 109484 21 сен 23:36 /bin/sh
/bin/sh: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamica
lly linked (uses shared libs), stripped
/dev/ad0s2f 10666198 6318480 3494424 64% /usr
Dhrystone 2 using register variables 1469371,5 lps (10,0 secs, 10 samples)
Double-Precision Whetstone 523,6 MWIPS (10,0 secs, 10 samples)
System Call Overhead 205945,1 lps (10,0 secs, 10 samples)
Pipe Throughput 230559,4 lps (10,0 secs, 10 samples)
Pipe-based Context Switching 54789,1 lps (10,0 secs, 10 samples)
Process Creation 2079,0 lps (30,0 secs, 3 samples)
Execl Throughput 422,8 lps (29,7 secs, 3 samples)
File Read 1024 bufsize 2000 maxblocks 146144,0 KBps (30,0 secs, 3 samples)
File Write 1024 bufsize 2000 maxblocks 34061,0 KBps (30,0 secs, 3 samples)
File Copy 1024 bufsize 2000 maxblocks 29784,0 KBps (30,0 secs, 3 samples)
File Read 256 bufsize 500 maxblocks 45182,0 KBps (30,0 secs, 3 samples)
File Write 256 bufsize 500 maxblocks 22794,0 KBps (30,0 secs, 3 samples)
File Copy 4096 bufsize 8000 maxblocks 31016,0 KBps (30,0 secs, 3 samples)
Shell Scripts (1 concurrent) 529,0 lpm (60,0 secs, 3 samples)
Shell Scripts (8 concurrent) 91,3 lpm (60,1 secs, 3 samples)
Shell Scripts (16 concurrent) 50,0 lpm (60,0 secs, 3 samples)
Arithmetic Test (type = short) 199432,2 lps (10,0 secs, 3 samples)
Arithmetic Test (type = int) 201465,8 lps (10,0 secs, 3 samples)
Arithmetic Test (type = long) 194009,5 lps (10,0 secs, 3 samples)
Arithmetic Test (type = float) 233309,4 lps (10,0 secs, 3 samples)
Arithmetic Test (type = double) 216354,3 lps (10,0 secs, 3 samples)
Arithoh 3358094,7 lps (10,0 secs, 3 samples)
C Compiler Throughput 412,0 lpm (60,0 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places 32191,0 lpm (30,0 secs, 3 samples)
Recursion Test--Tower of Hanoi 27637,6 lps (20,0 secs, 3 samples)
INDEX VALUES
TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700,0 1469371,5 125,9
Double-Precision Whetstone 55,0 523,6 95,2
Execl Throughput 43,0 422,8 98,3
File Copy 1024 bufsize 2000 maxblocks 3960,0 29784,0 75,2
File Copy 256 bufsize 500 maxblocks 1655,0 13676,0 82,6
File Copy 4096 bufsize 8000 maxblocks 5800,0 31016,0 53,5
Pipe Throughput 12440,0 230559,4 185,3
Pipe-based Context Switching 4000,0 54789,1 137,0
Process Creation 126,0 2079,0 165,0
Shell Scripts (8 concurrent) 6,0 91,3 152,2
System Call Overhead 15000,0 205945,1 137,3
=========
FINAL SCORE 111,9

[polachok]

мдя, чего меряет ubench я и сам перестал понимать - сегодня показывает Ubench AVG: 46179.9
(ядро по рекомендациям Bitterman - HZ=1000, PREEMPTION)

[Bruce]

ага, стало всё в два раза быстрее . я бы лучше на основе компиляции чего-нибудь тесты делал. там, kdelibs или что-то в этом роде.

[EdiG]

а почему бы не воспользываться
nbench или libmicro

[polachok]

нет уж, спасибо! во первых, KDE не люблю. во-вторых, лениво просто! на моей машине kdelibs полдня компилиться будет.

[Bruce]

ну, у меня ненамного быстрее, но часов за 5 соберётся. типа, time make - и на разных ядрах погонять. вопрос-то в принципе, важный. можно кого-нибудь припахать к этому. или одолжить у кого тачку вторую.

[polachok]

вопрос-то в принципе, важный.

к тому же интересный в практическом смысле. некоторое время помучившись с этим делом (думаю kdelibs можно заменить например buildworld) можно получить интересные результаты, кои можно будет использовать впоследствии.
только вот кто согласится заниматься такой скучной, но общественно-полезной работой?

Ну что товарищи, кто одолжит мне вторую тачку?

[alv]

думаю kdelibs можно заменить например buildworld
Ну что товарищи, кто одолжит мне вторую тачку?

думаю - нельзя: отростки дерева для i386 и amd64 - разные
тоже на это напоролся
а на самом деле, тест должен занимать не более получаса - с учетом троекратного повторения на предмет статистики/воспроизводимости

только вот кто согласится заниматься такой скучной, но общественно-полезной работой?

работой - не знаю, а вот just for fun - некоторые время от времени балуются

PS причем на тачках с P-166, P-II/266 и так далее :-)

[polachok]

ну это уж совсем занятие не для слабонервных... насчет amd64:

Код: Выделить всё

[polachok@darkstar ~]# find /usr/src/ -name amd64                 [tty05-19:29]
/usr/src/sys/amd64
/usr/src/sys/amd64/amd64
/usr/src/sys/contrib/dev/nve/amd64
/usr/src/usr.bin/xlint/arch/amd64
/usr/src/gnu/usr.bin/gdb/arch/amd64
/usr/src/lib/csu/amd64
/usr/src/lib/libc/amd64
/usr/src/lib/libc_r/arch/amd64
/usr/src/lib/libpthread/arch/amd64
/usr/src/lib/libpthread/arch/amd64/amd64
/usr/src/lib/libthr/arch/amd64
/usr/src/lib/libthr/arch/amd64/amd64
/usr/src/lib/libthread_db/arch/amd64
/usr/src/lib/msun/amd64
/usr/src/libexec/rtld-elf/amd64
/usr/src/release/doc/en_US.ISO8859-1/hardware/amd64
/usr/src/release/doc/en_US.ISO8859-1/installation/amd64
/usr/src/release/doc/en_US.ISO8859-1/relnotes/amd64
/usr/src/release/doc/ja_JP.eucJP/hardware/amd64
/usr/src/release/doc/ja_JP.eucJP/relnotes/amd64
/usr/src/release/doc/ru_RU.KOI8-R/hardware/amd64
/usr/src/release/doc/ru_RU.KOI8-R/installation/amd64
/usr/src/release/doc/ru_RU.KOI8-R/relnotes/amd64
/usr/src/release/doc/zh_CN.GB2312/hardware/amd64
/usr/src/release/doc/zh_CN.GB2312/installation/amd64
/usr/src/release/doc/zh_CN.GB2312/relnotes/amd64
/usr/src/release/amd64

откуда очевидно что различия только в разделах /sys, /release (которые при buildworld и вовсе не компиляются) ну и в сишной либе (что важнее). так что больших различий (а тем более "веток") не ощущаю. где моя ошибка?

[Bruce]

так, не совсем в тему, но на моей тачке ubench выдаёт средний где-то 45000. что вроде бы даже и многовато

прошу не тестить с buildworld - у меня linux так что разницу мне оценить не получится. лучше на чём нибудь более популярном. полчаса может собираться mplayer. ну или ещё что-нибудь такое.

распаковка дерева портов - это больше нагрузка на жёсткий, чем чистый проц. поэтому компиляция справедливей. можно ещё попробовать под freebsd собирать ядро линукса . при всём включенном (всё равно его не ставить, а собираться должно).

[alv]

2polachok
все правильно - это моя ошибка, разные ветки (причем очень разные) только для /usr/src/sys, юзерленд, за исключением отмеченных деталей, одинаков
но долго, однако - make buildworld

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

отнюдь - распаковка/упаковка (особенно упаковка) дерева потров на mfs/tmpfs - практически только камень, без участия диска

можно ещё попробовать под freebsd собирать ядро линукса . при всём включенном (всё равно его не ставить, а собираться должно).

не должно (в смыцсле не обязано) - libc и хидеры совсем разные
разве что в chroot (который linux compatible) - но тут уж все становится совсем невоспроизводимым

[polachok]

не... ядро линукса собирается только в эмуляции (собирал сам). не пойдет.
да и вообще, я думаю результаты полученные для FreeBSD не всегда могут быть применимы к linux.

[Bruce]

отнюдь - распаковка/упаковка (особенно упаковка) дерева потров на mfs/tmpfs - практически только камень

тьфу, показалось . если так - то да. если на жёсткий распаковывать (если озухи хватит ) - то на него неслабая нагрузка будет, т.к. файлов вроде бы много.

я думаю результаты полученные для FreeBSD не всегда могут быть применимы к linux.

это чтобы лишний раз меня убедить в том, что нужно слезть с того, что уже и так прекрасно работает . планирую устроить в воскресение freebsd-сешн ( ), посмотрю, чего как. тот же ubench, наконец, на моём проце сколько даст

[zenwolf]

да неверте вы ubench ,выдаёт всякую фигню ,непредставительный
тест будет