Доброго времени суток!Недавно в списках рассылки freebsd.org появилась ссылка на страницу с результатами сравнительного тестирования FreeBSD 5.3 и NetBSD 2.0, на звание лучшей серверной ОС в плане производительности. Отмечу, что в общем зачете победа досталась NetBSD. Похоже, впервые за всю историю. Ссылка прилагается.
http://www.feyrer.de/NetBSD/gmcgarry/Удивительнее всего то, что NetBSD обошла FreeBSD не на alpha или sparc64, а на i386! А еще если учесть, что 2-й ветке NetBSD только месяц со времени официального релиза, а 5-й ветке FreeBSD уже около 2-х лет, то состояние FreeBSD 5.x меня лично не очень радует... А NetBSD, наконец-то, становится ОС не только для "убогих и обездоленных".
>http://www.feyrer.de/NetBSD/gmcgarry/Если почитать внимательно "вводную" а заодно и весь thread на freebsd.org то становится более понятно почему получены именно такие результаты.
Hint:
"The benchmark hardware was an Asus P4-800SE mainboard, Intel 3GHz P4 processor (1MB L2 cache) and 1GB RAM. Both NetBSD 2.0 and FreeBSD 5.3 default installations were used for the benchmarks. No custom kernels were used and no kernel tuning beyond the default installation was performed."
Между прочим, не было сказано ничего о том, какое ядро NetBSD использовалось: обычное или MP. FreeBSD 5.3 идет по умолчанию с MP. A процессор ведь поддерживает HTT, так что это уже не UP, как утверждал в том интервью Скотт Лонг. Надо бы уточнить.Я, конечно, приветствую улучшение поддержки MP-систем, но только если это не отражается негативно на UP-системах. А проектировать ОС изначально под MP, а затем минимизировать потери для UP -- это не очень красиво, и ведет к чрезмерному утяжелению ядра и неизбежной потере производительности, что и доказывает FreeBSD 5.x. К тому же, содержимое /bin и /sbin там теперь динамическое, а не статическое, а это приводит к деградации производительности против некоторой экономии памяти.
>Между прочим, не было сказано ничего о том, какое ядро NetBSD использовалось:
>обычное или MP. FreeBSD 5.3 идет по умолчанию с MP. A
>процессор ведь поддерживает HTT, так что это уже не UP, как
>утверждал в том интервью Скотт Лонг. Надо бы уточнить.
Уточняю ;-) Для HT нужна поддержка SMP в ядре. OpenBSD по умолчанию с UP-ядром. Итого: сравниваем гвозди с яблоками (чтобы более ёмко не сказать)>Я, конечно, приветствую улучшение поддержки MP-систем, но только если это не отражается
>негативно на UP-системах. А проектировать ОС изначально под MP, а затем
>минимизировать потери для UP -- это не очень красиво, и
>ведет к чрезмерному утяжелению ядра и неизбежной потере производительности, что и
>доказывает FreeBSD 5.x.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/introdu...
Потом читаем интервью ещё раз на тему schedule.
И вообще мне например интересно сколько людей используют GENERIC? ;-)>К тому же, содержимое /bin и /sbin там
>теперь динамическое, а не статическое, а это приводит к деградации производительности
>против некоторой экономии памяти.
Смешно. Пересобери статически, проверь и результаты в студию ;-)
"Зри в корень " - http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-desig...
>Уточняю ;-) Для HT нужна поддержка SMP в ядре. OpenBSD по умолчанию
>с UP-ядром. Итого: сравниваем гвозди с яблоками (чтобы более ёмко не
>сказать)
С другой стороны, HTT далеко до обычного 2-way SMP. Я как-то долго не мог понять, почему оно так тормозит; оказалось, что с врубленным HTT половина как первого, так и второго кэша ушла ко 2-му "логическому" камню, от которого как ни крутил, никакого толку не получил :( Фактически, я попросту вырубил половину кэша!>http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/introdu...
>Потом читаем интервью ещё раз на тему schedule.
>И вообще мне например интересно сколько людей используют GENERIC? ;-)
Немногие, да и то пока не научатся сами ядра собирать :)>
>>К тому же, содержимое /bin и /sbin там
>>теперь динамическое, а не статическое, а это приводит к деградации производительности
>>против некоторой экономии памяти.
>Смешно. Пересобери статически, проверь и результаты в студию ;-)
>"Зри в корень " - http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-desig...
Дык а я чего делал? У меня динамический sh скрипты щелкал на добрую треть времени дольше, чем статический. Факт.
>>Уточняю ;-) Для HT нужна поддержка SMP в ядре. OpenBSD по умолчанию
>>с UP-ядром. Итого: сравниваем гвозди с яблоками (чтобы более ёмко не
>>сказать)
>С другой стороны, HTT далеко до обычного 2-way SMP. Я как-то долго не мог >понять, почему оно так тормозит; оказалось, что с врубленным HTT половина >как первого, так и второго кэша ушла ко 2-му "логическому" камню, от >которого как ни крутил, никакого толку не получил :( Фактически, я >попросту вырубил половину кэша!
Сорри за ошибку - не OpenBSD а NetBSD.>>>К тому же, содержимое /bin и /sbin там
>>>теперь динамическое, а не статическое, а это приводит к деградации производительности
>>>против некоторой экономии памяти.
>>Смешно. Пересобери статически, проверь и результаты в студию ;-)
>>"Зри в корень " - http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-desig...
>Дык а я чего делал? У меня динамический sh скрипты щелкал на
>добрую треть времени дольше, чем статический. Факт.
Не знаю как остальные, а слову "Факт" не подтверждённому данными я не сильно доверяю. Чисто из интереса сам попробую пересобрать что-нибудь статически и под утро результаты выложу. По design небольшая потеря производительности возможна только при повторных вызовах и сильно загруженной памяти. Сам использую RELENG_5_3 как developer workstation (X + много сервисов) и уменьшения производительности по сравнению со старой RELENG_4_8(последнее из 4.х что я использовал для workstation) не ощущаю.
По серверам другая картина - 5.х дала ощутимое увеличение производительности на MP системах.
>Не знаю как остальные, а слову "Факт" не подтверждённому данными я не
>сильно доверяю. Чисто из интереса сам попробую пересобрать что-нибудь статически и
>под утро результаты выложу. По design небольшая потеря производительности возможна только
>при повторных вызовах и сильно загруженной памяти.
Не знаю насколько обьективно использовать cat и date для такой проверки, но они мне первые попались на глаза :-)Preface:
RELENG_5_3 (5.3-RELEASE-p5), 2.00GHz Cel, 256Mb;
Custom kernel, сервисы и Хы запущены;
Бинари собирались с LDFLAGS+= -O2 -s;
для static - LDFLAGS+= -O2 -s -static;
Для простоты запускалось через перл и /usr/bin/time.
Для cat взят /var/db/pkg/pkgdb.db (как достаточно большой и не влазящий в кэш ), для date - конвертация даты из man.
STDIN перенаправлялся в /dev/null (чтобы не считать время нужное перлу на чтение из потока)Results:
100 iterations [./cat -v /var/db/pkg/pkgdb.db]
-------------------
Dynamic: 129.11 49.99 6.51
Static: 167.31 50.24 7.310000 iterations [./date -j -f "%a %b %d %T %Z %Y" "`./date`" "+%s"]
-------------------
Dynamic: 61.7699999999997 0 0
Static: 19.2600000000001 0 0Чем можно обьяснить такой разброс - я не знаю. Наверно стоит проверить в двух отдельных jail и задатся сразу более сложной конструкцией.
Интересный расклад. По логике, статический экзешник не может быть медленнее динамического. Кстати, припоминаю, что до 5.1 корень был статическим, у меня из-за этого апгрейд на 5.2.1 завалился: места не хватило. Пришлось срочно загружаться с другого харда, и откатываться.Мои тесты были связаны с регулярным резервным копированием по сети, с некоторой сортировкой и выборкой, ничего особенного. Все-таки непонятно, для чего потребовалось переводить корень на динамику?