Перевод статьи «Все любят тесты производительности» с haiku–os.org
--–

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

Чем постоянно заняты разработчики Haiku, так это сборкой системы, поэтому для нас наиболее интересен будет тест скорости сборки. Так же это весьма информативный тест общего уровня производительности системы. Он дает представление о различных относящихся к ядру процессов, таких как эффективность блокирующих примитивов, конкуренции в ядре, планировка задач для нескольких процессоров, ветвление и запуск процессов, и в какой–то степени, производительности файловой системы и кеширования. В процессе сборке Haiku основная утилита сборки jam многократно ветвит себя для запуска таких утилит сборки как GCC, линкер, mimeset и других полезных программ. Адресное пространство jam'а вырастает примерно до 500 Мб после парсинга всех файлов в дереве и клонирования этого адресного пространства, когда jam ветвит различные подпроцессы для сборки индивидуальных целей, создавая значительную нагрузку на ядро и его низкоуровневые системные службы. Другие аспекты операционной системы, такие как графический пользовательский интерфейс, не сильно влияют на результаты тестов, кроме разве что плохо реализованного терминала с медленным рендерингом и прокруткой, но и это я считаю несущественным для всех тестируемых платформ.

Очевидно, что тестирование всех ОС следовует проводить на одном железе, так как это позволяет закрыть глаза на некоторые малозаметные, но важные детали, которые могут дать нечестное преимущество одной или нескольким тестируемым системам. Планируя схему разбивки диска на разделы я смог сделать тесты более менее честными, расположив исходные тексты и генерируемые файлы в одном и том же месте. Для тестов я использовал жесткий диск WD VelociRaptor на 150 Гб. Это довольно быстрый диск (среднее время поиска 4.5 мс), но потоковая производительность в реальности зависит от того откуда считываются и куда пишутся данные. Для всех тестов я использовал раздел в начале диска (для исходных кодов и генерируемых данных). Остальные части тестового железа:
— ASUS P5Q (Intel P55 chipset) с SATA–контроллером JMicron в режиме AHCI;
— Core2Duo E4300 CPU 1.8 GHz;
— 2 x 1 Гб DDR2 RAM 800 MHz;
— NVidia Geforce 7200, с родными драйверами на всех тестируемых платформах.

Протестированные платформы

Я решил использовать наиболее часто используемые системы для сборки Haiku, включая Линукс в лице openSUSE 11.2, а также FreeBSD 8.0, OpenSolaris 2009.06, Haiku r35024 и ZETA 1.2. В реальности ZETA для этих целей уже почти не используется, однако же было очень интересно сравнить ее производительность по отношению к Haiku, учитывая всеобщие ожидания что в Haiku возродится наследие BeOS, которое возможно уже более широко реализовано в форме ZETA. К несчастью у меня не нашлось системы способной запустить BeOS R5. Даже для запуска ZETA мне пришлось перевести SATA контроллер в режим совместимости IDE. Так что мне не удалось определить действительно ли ZETA медленнее чем BeOS R5. Судя по моему многолетнему опыту работы с BeOS R5, а позднее и с ZETA в качестве основной ОС, я сильно в этом сомневаюсь.

Файловые системы

Для Линукса я использовал ReiserFS 3.6, так как похоже что это быстрейшая система для сборки Haiku. Так же это единственная линуховая система имеющая поддержку xattr достаточную для того, чтобы сборочный процесс Haiku мог хранить многие специфичные файловые атрибуты. Для FreeBSD была использована стандартная UFS2, единственная среди небеосных ФС имеющая адекватную поддержку файловых атрибутов. Файловая система openSolaris ZFS также поддерживает xattr, но наша сборочная система не имеет поддержки xattr на openSolaris'е на данный момент. Сравнив тест ZFS против более старой UFS на Солярисе, особенно в аспекте компилирования, которые показал преимущество ZFS, я заключил, что повторный тест на openSolaris с UFS будет только лишней тратой времени. Поддержка xattr в ext4 для сборки Haiku до сих пор неполноценна, так как существуют ограничения на максимальный размер атрибута. Несмотря на это я попытался повторить тест на openSUSE с ext4, но это вызвало в конце концов переполнение диска, даже после того как я удалил исходный код сборочных инструментов. Для Haiku и Зеты я использовал тот раздел о котором говорил раньше, отформатированный в BFS без индексов. Говорят, что индексные атрибуты оказывают плохое влияние на производительность, так как индексация встроена в саму файловую систему и обновление индексов файловых имен и других индексов во время процесса сборки происходит постоянно.

Использование раздела BFS без индексов позволило сравнить изначальный дизайн тестируемых файловых систем, даже несмотря на то невозможно точно оценить степень их влияния на общую производительность. Так как и Линукс, и FreeBSD, и насколько я знаю openSolaris не индексируют атрибуты в процессе сборки, сравнение в этом случае выходит более менее честное.

Конфигурация сборки Haiku

Во избежание проблем с тем, что ZETA устарела в качестве системы для сборки, я использовал достаточно старое дерево исходных кодов Haiku ревизии 28969. Так как именно эта ревизия другими платформами больше не поддерживается, мне пришлось сравнить Зету и Haiku индивидуально, в то время как для сравнения Haiku, Линукса, FreeBSD и openSolaris'а я использовал более новую ревизию исходников под номером r34844. В качестве компилятора на всех платформах использовался GCC 2.95.3, так как на всех из них он был собран прямо из репозитория Haiku как кросс–компилятор. Соответствующие системные компиляторы на openSolaris, Linux и FreeBSD в нашем случае не равноценны, хоть они и используются для сборки некоторых сборочных инструментов, которые могут запускаться на тестовой системе. Влияние от использования различных версий компиляторов должно быть минимально. Немного нечестно по отношению к Линуксу, FreeBSD и openSolaris'у то, что конфигурация таких инструментов, как mimeset, keymap, xres и других использует Be API и линкуется с помощью libbe. На этих трех системах линковка происходит с помощью минимального фейка libbe, содержащего лишь минимально необходимую функциональность, требуемую этими инструментами. На Haiku и Зета и используется настоящая libbe и каждый вызов любого из этих инструментов проходит через статическую инициализацию кода в библиотеке, в отличие от других тестируемых систем. В остальном же я собирал образ Haiku используя два задания (jobs) без всяких дополнительных изменений UserBuildCOnfig.

Переходим к результатам

$ time jam -q -j2 haiku–image

FreeBSD 8.0:
real 11m53.918s
user 17m11.611s
sys 2m39.864s
(713.9 seconds)

Linux 2.6.31:
real 13m32.431s
user 17m10.099s
sys 2m49.717s
(812.4 seconds)

OpenSolaris 2009.06:
real 14m20.792s
user 18m36.871s
sys 5m39.549s
(860.8 seconds)

Haiku r35024:
real 17m18.436s
user 27m22.108s
sys 5m0.447s
(1038.4 seconds)

Сравнение Haiku r35024 и ZETA 1.2 (компилирование ревизии r28969):

ZETA 1.2 (с запущенным StatCacheServer для ускорения поиска файлов jam'ом):
real 86m54.680s
user 22m8.017s
sys 80m48.841s
(5214.7 seconds)

Haiku r35024:
real 13m0.474s
user 20m30.814s
sys 3m36.103s
(780.5 seconds)

Выводы

Как видно, FreeBSD 8.0 в этом конкретном тестировании надрал всем задницу. В нем параллельное выполнение задач на 2–х процессорной системе оптимизировано лучше остальных тестируемых систем. Выигрыш по сравнению с Линуксом — в 1.14 раза, а по сравнению с openSolaris — в 1.21 раза. Похоже что парни из FreeBSD проделали неплохую работу по эффективному устранению блокировок в их гигантском ядре.

Следует также отметить, что Инго сумел существенно ускорить Haiku. Как и ожидалось, она отстает по отношению к конкурентам: в 1.45 раза медленнее FreeBSD, в 1.28 раза медленнее Линукса и в 1.21 раза медленнее openSolaris'а. По крайней мере в этом тестировании я нахожу этот факт захватывающим, учитывая насколько хорошо развиты и оптимизированы эти системы. Большие корпорации вкладывают огромные деньги для того чтобы сделать эти системы быстрыми. Также радует, что Haiku серьезно надрала задницу Зете. Вау, быстрее в целых 6.68 раза? App_server в Зете возможно до сих пор и проворнее чем в Haiku, но мальчишка из ядра Haiku уделывает на несколько кругов мальчонку из Зеты! Также в ранних обсуждения было упомянуто, что в задачах компилирования дизайн BFS сродни узкому горлышку бутылки. Но мне кажется, что только не в этом случае. По крайней мере не это является причиной того, что Зета так сильно отстала. Из того, что я узнал в различных IRC–каналах и читая другие тесты, тип файловой системы вероятно не самый важный фактор в этом конкретном тесте. Оптимизации, сделанные Инго в ядре Haiku наводят на мысль, что уменьшение времени ожидания в важных блокировках ядра (конфликтах), а также эффективные алгоритмы в ядре оказали сильнейшее влияние. Работа, проделанная Инго и Акселем по исследованию ядра и созданию графических аналитических инструментов себя полностью окупила. Хорошо также то, что Инго знает что делает, когда применяет оптимизации. Из разговора с ним стало ясно, что до сих пор существует много возможностей по оптимизации в ядре всякой всячины и уменьшения конфликтов при блокировках. Инго в данный момент использует 8–ми ядерную машины для разработки, и так как ядро Haiku не масштабируется также хорошо, как другие платформы, результаты тестирования сильно отличаются на 8–ядерной машине по сравнению с 2–х ядерной, оставляя Haiku далеко позади других систем. Я очень радуюсь работе, проделанной Инго и мне будет очень интересно наблюдать как Haiku размеренно догоняет других, становясь достойной платформой для компилирования самой себя.

Оригинал на haiku–os.org