FreeBSD для AMD64 против BSD для i386: еще раз о быстродействии

Алексей Федорчук
20 сентября 2005 г

Поводом к сочинению этой заметки послужило сообщение Томаша Борштнара в списке рассылки DragonFlyBSD, посвященное измерению сравнительного быстродействия этой ОС с FreeBSD различных веток (4.11, 5.4, 6.0Beta) в сборках для архитектур i386 и AMD64 (как известно, DragonFly существует только в сборке для i386, хотя и способна работать на 64-битных машинах). Измерения проводились на машине AMD64/939 3000+ с 2GB RAM (dual-channel), а в качестве пузомерки была выбрана программа ubench, измеряющая быстродействие процессора (CPU) и подсистемы памяти (MEM).

Результаты Томаша казались обескураживающими — с точки зрения суммарного (AVG) быстродействия операционки расположились следующим образом (табл. 1, снизу вверх):

Табл. 1. Результаты измерений Томаша Борштнара (в сокращении)

ОС	AVG
FreeBSD 6.0 (i386)	78551
FreeBSD 5.4 (i386)	94296
FreeBSD 4.11 (i386)	94296
FreeBSD 6.0 (amd64)	101448
DragonFly Preview (i386)	106030

Кроме рекордных показателей DragonFlyBSD, обращает на себя внимание провал FreeBSD 5.4 (i386) в процессорных операциях (CPU=59062) при ураганном быстродействии памяти (MEM=98040), тогда как все остальные версии FreeBSD и DragonFly демонстрируют более сходные показатели CPU и MEM. Характерен также полный упадок умолчальной (с включенной отладкой malloc) FreeBSD 6.0 для i386 (из моей таблицы исключено).

К сожалению, из текста Томаша не всегда ясно, при какой конфигурации ядра для каждой ветки и операционки проводились измерения — собственно, это и вызвало наибольшее количество вопросов. И потому я, располагая сходной конфигурацией и близким набором установленных систем, решил повторить его тесты.

Измерения проводились на машине с процессором AMD64 3200+ (реальная тактовая частота — 2 Гц) и 1 Гбайт памяти (два модуля по 512 Мбайт, работающие в двухканальном режиме). В наличии у меня имелись:

• FreeBSD 6.0 Beta 2 for AMD64, с пересобранным ядром (в нем были исключены все отсутствующие устройства и отладочные опции) и «миром», флаги компиляции — -O2 -march=athlon64;
• DesktopBSD, являющая собой внутри самую обычную FreeBSD 5.4, в установке по умолчанию;
• один из промежуточных снапшотов DragonFlyBSD-RELEASE (условный номер версии — 1.2.5), также с умолчальным (то есть включающем отладочную информацию) ядром и «миром».

В качестве «аршина» выступила утилита ubench-0.32, собранная из порта (для AMD64), установленная из бинарника (для FreeBSD i386) и собранная вручную (для DragonFlyBSD). Для каждой из систем измерения проводились трижды, после чего подсчитывались средние арифметические показателей CPU, MEM и AVG. Результаты можно видеть в таблице 2.

Табл. 2 Сравнительное быстродействие FreeBSD (AMD64 и i386) и DragonFlyBSD

Ubench	FreeBSD 6 AMD64	FreeBSD 5.4 i386	DragonFly i386
CPU	113219	63925	84157
Mem	115692	141338	58639
AVG	114456	102631	71398

Еще более наглядно полученные результаты предстают на диаграмме (рис. 1).

Рис. 1. Результаты измерений утилитой ubench

Можно видеть, что тут DragonFly весьма далека от рекордного быстродействия по обеим позициям, лишь по CPU несколько опережая FreeBSD 5.4 (i386). Которая опять демонстрирует более чем двухкратный разрыв между CPU и MEM. Результаты же FreeBSD 6.0 более ровные, что и обеспечивает ей суммарное первое место.

Конечно, можно предположить, что оптимизация ядра прибавила бы DragonFly некоторое количество «попугаев». Однако и для FreeBSD for AMD64 мы имеем дело с бета-версией операционной системы — в релизе, освобожденном от отладочного балласта, ее быстродействие также может возрасти. Так что в данный момент говорить о решительном превосходстве «стрекозы» над своей прародительницей с точки зрения быстродействия не приходится. Впрочем, к этому вопросу я надеюсь еще вернуться — после выхода следующей версии DragonFly.

А пока хотелось бы еще раз обратиться к вопросу сравнительного быстродействия 32- и 64-разрядной версий FreeBSD. Ибо предыдущее, основанное на сравнении времени сборки ядра, было не вполне корректным: ведь ядра этих версий представляют собой отдельные (и весьма различные) ветки в дереве исходников, так что в каждом случае компилировался разный, как по объему, так и по содержанию, код.

Следующий пришедший мне в голову «малозатратный» (с точки зрения временных затрат) тест — это распаковка и упаковка в компрессированный архив достаточно объемистого каталога. Таковым выступило дерево портов FreeBSD. Чтобы снять влияние дисковой подсистемы, процедура эта осуществлялась в файловой системе mfs, подмонтированной в специальный каталог. К сожалению, выполнить ее под управлением DragonFly не удалось. Так что далее пойдет речь только о сравнении FreeBSD 5.4 for i386 и FreeBSD for AMD64.

Итак, в каталог /tmp/test монтирую файловую систему mfs, копирую в него тарбалл дерева портов FreeBSD (от 13 сентября 2005 г., объемом около 28 Мбайт), далее, засекая время командой date, распаковываю его

$ tar xzf ports.tar.gz

А затем получившийся каталог обратно запаковываю, но уже с использованием утилиты bzip2:

$ tar cjf ports.tar.bz2 ports/

Как обычно, процедуру повторяю трижды, с размонтированием каталога в промежутках, подсчитываю среднее, результаты свожу в таблицу (табл. 3).

Arch/Zip	FreeBSD 6 AMD64	FreeBSD 5.4 i386
untar/ungzip	12	91
tar/bzip2	47	69

Правда, с распаковкой тарбалла не все проходит гладко: если под управлением FreeBSD 6 for AMD64 эта процедура проходит почти мгновенно, за 11 секунд, то под for FreeBSD 5.4 i386 она растягивается почти на полторы минуты — почти столько же, сколько заняла бы при распаковке в обычную файловую систему на дисковом разделе (см. соответствующий материал). Объяснения этому я пока не нашел, и потому из дальнейшего рассмотрения этот тест исключаю.

Тем более, что тест за-tar’ивания и за-bzip’ливания достаточно показателен (рис. 2), демонстрируя 30-процентное превосходство 64-битной версии FreeBSD над 32-битной предшественницей.

Рис. 2. Сравнительное быстродействие на операции архивирования/компрессии

Конечно, для пущей количественной корректности его следовало бы выполнить под управлением версий одной и той же ветки, но качественно это вряд ли изменили бы картину. Ведь и на компиляции ядра разница между 32- и 64-битной версиями (тогда — одной ветки) была примерно такой же…