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).

Результаты Томаша оказались настолько обескураживающими, что вызвали довольно интенсивное обсуждение на opennet.ru и на Линуксфоруме. Напомню вкратце, что, согласно Томашу, с точки зрения суммарного (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-битной версиями (тогда - одной ветки) была примерно такой же...

Обновлено: 12.03.2015