Главная

Тест скорости сборки Haiku в разных операционных системах

Перевод статьи «Все любят тесты производительности» с 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

Буду

Буду не оригинален, но спасибо за перевод. Одно замечание — лексика классического русского языка не имеет столь сильной склонности к анальной фиксации как у англосаксов и прочих немцев. Потому выражения «про задницу» несколько режут глаз на общем литературно ровном фоне статьи. Я бы заменял их на более привычные русскому уху «оставить с носом», «показать хвост» и т.п. Ещё раз спасибо, и успехов! :)

Спасибо

Спасибо за замечание. У меня возникло похожее чувство несоответствия этих выражений всему тексту, но я был слегка уставший и, возможно, просто таким образом пошутил =)

Под Линуксом

Под Линуксом значительное ускорение (раза в два) даёт использование tmpfs. Каталог, куда собираем Хайку делаем в tmpfs ( mount -o tmpfs tmpfs -size=1584M /wip/haiku/ ), копируем туда buildtools и haiku из SVN. Собираем (по–возможности, в отдельный каталог, см. export HAIKU_OUTPUT_DIR=/wip/haiku/obj_build ).
Построенный каталог /wip/haiku из tmpfs копируем куда–нибудь на hdd, чтобы потом при новой пересборке сделать заново tmpfs и скопировать назад.
Ещё можно делать SVN update в один каталог, из него rsync–ом синхронизируем в копию с собранным на hdd. Тогда jam соберёт не полностью чистый образ, с нуля (clean) — а только по изменившимся файлам. Соответвтвенно, надо бы проверить вручную, что haiku/configure, haiku/scripts/build_crosstools_gcc* не очищают каталоги перед сборкой. Хотя это не очень надёжно, сборка с clean как–то надёжнее.

mount -t tmpfs tmpfs -o

mount -t tmpfs tmpfs -o size=1584M /tmpfs–dir, конечно же. Размер подобрать вручную, чтобы всё поместилось (сборка кросстулчейна, емнип, просит >2 Гб, но потом частично объектники чистятся, бинарники остаются).

В конечном

В конечном итоге эти оптимизации нужны для ускорения реальной работы пользователя Haiku.
Так вот после прочтения оригинала этой статьи несколько дней назад, я заметил что вышла версия набора тестов производительности проца и памяти geekbench для haiku.
И решил проверить им 3 ОС.
Тест запускался на одном и том же компе C2D c 4GB памяти.
Вот общие баллы теста:
Windows XP SP2 — 3126
MAC OS 10.6.2 — 3770
Haiku r35081 — 4500
Как такое может быть? Правда, Geekbench для WIN/MAC был 2.1.4, а для Haiku 2.1.5b1, но они не меняют алгоритмы настолько радикально между версиями.

HaikuOS гибрид

HaikuOS гибрид 4–2 R35012

проц интел Е7300 двухголовый 2,6 гигагерцевый, память 2 гига 800 мегагерцевая на шине 266

тест результат 4348

Тот же комп

Тот же комп после разгона по шине до 300, память до 900, проц до 3 гигагерц

тест 4801

Поправка

Поправка и подробные результаты:
Windows XP SP2 — 3126
MAC OS 10.6.2 — 3770
Haiku r35081 — 4353

Посмотрим на отдельные тесты

Processor integer performance:
Windows XP SP2 — 3673
MAC OS 10.6.2 — 2939
Haiku r35081 — 2813

Processor floating point performance:
Windows XP SP2 — 3069
MAC OS 10.6.2 — 5408
Haiku r35081 — 7463

Memory performance:
Windows XP SP2 — 2407
MAC OS 10.6.2 — 2918
Haiku r35081 — 2454

Memory bandwidth performance:
Windows XP SP2 — 2859
MAC OS 10.6.2 — 2650
Haiku r35081 — 2662

Как видим, во всех тестах haiku наравне или немного отстает, за исключением теста Processor floating point performance, который и дает ей преимущество в итоговом результате.

Тогда рассмотрим подробнее тест — Processor floating point performance:

Mandelbrot single–threaded scalar:
Windows XP SP2 — 1791,, 1.19 Gflops
MAC OS 10.6.2 — 1953,, 1.30 Gflops
Haiku r35081 — 1954

Mandelbrot multi–threaded scalar:
Windows XP SP2 — 3615,, 2.37 Gflops
MAC OS 10.6.2 — 3874,, 2.54 Gflops
Haiku r35081 — 3967

Dot Product single–threaded scalar:
Windows XP SP2 — 1183,, 571.5 Mflops
MAC OS 10.6.2 — 3578,, 1.73 Gflops
Haiku r35081 — 3575

Dot Product multi–threaded scalar:
Windows XP SP2 — 2479,, 1.13 Gflops
MAC OS 10.6.2 — 7419,, 3.38 Gflops
Haiku r35081 — 7569

LU Decomposition single–threaded scalar:
Windows XP SP2 — 2303,, 2.05 Gflops
MAC OS 10.6.2 — 750,, 667.7 Mflops
Haiku r35081 — 2032

LU Decomposition multi–threaded scalar:
Windows XP SP2 — 4573,, 4.01 Gflops
MAC OS 10.6.2 — 1492,, 1.31 Gflops
Haiku r35081 — 3673

Primality Test single–threaded scalar:
Windows XP SP2 — 3507,, 523.8 Mflops
MAC OS 10.6.2 — 4226,, 631.3 Mflops
Haiku r35081 — 2449

Primality Test multi–threaded scalar:
Windows XP SP2 — 5327,, 988.6 Mflops
MAC OS 10.6.2 — 6315,, 1.17 Gflops
Haiku r35081 — 3824

Sharpen Image single–threaded scalar:
Windows XP SP2 — 580,, 1.36 Mpixels/sec
MAC OS 10.6.2 — 5475,, 12.8 Mpixels/sec
Haiku r35081 — 8457

Sharpen Image multi–threaded scalar:
Windows XP SP2 — 1162,, 2.68 Mpixels/sec
MAC OS 10.6.2 — 10822,, 24.9 Mpixels/sec
Haiku r35081 — 17085

Blur Image single–threaded scalar:
Windows XP SP2 — 2380,, 1.88 Mpixels/sec
MAC OS 10.6.2 — 6897,, 5.46 Mpixels/sec
Haiku r35081 — 11568

Blur Image multi–threaded scalar:
Windows XP SP2 — 4735,, 3.72 Mpixels/sec
MAC OS 10.6.2 — 13508,, 10.6 Mpixels/sec
Haiku r35081 — 23404

Теперь видно, что MAC OS неправдоподобно быстрее Windows, а Haiku неправдоподобно быстрее MAC OS в операциях Sharpen Image и Blur Image. Что в ядре может дать такое преимущество или может быть глюк тестового алгоритма?

L1/L2 cache locality

L1/L2 cache locality

Вывод: 1.

Вывод:

1. портируем на Haiku Photoshop
2. делаем обзор–сравнение производительности с Photoshop'ом на MacOS
3. ???
4. PROFIT !!!

Говорят,

Говорят, что был Photoshop для BeOS. Какой–то из стареньких. Adobe, мол, подготовила всё к выбросу продукта на рынок, а Be, Inc. её обломала.

А жаль. Судя

А жаль. Судя по этим данным, Haiku даже в альфе (!) с нормально написанным софтом по скорости обработки мультимедиа–данных порвет в лоскуты не только Windows, a и Mac. Я, конечно, немного утрирую, но немного же, правда ? :)

Ключевое слово

Ключевое слово «с нормально написанным софтом». Возможно, программы под другие ОС не настолько изящны, но они отлаживаются годами, сотнями человеколет. А софт под Haiku в основном пишется энтузиастами в свободное время. Неправильно сконструированный цикл одним махом сметёт все достоинства и преимущества Haiku на уровне операционки.

Это так, риторический стон в сторону.

Дело не только

Дело не только в софте.. Даже gcc4 сам по себе генерирует очень странный код (аллокатор регистров — нереально больное место)

Хм… По–моему

Хм… По–моему gcc4 с опцией -O2 очень хорошо оптимизирует код. А можно какой–нибудь простенький пример?

Вот тебе и на,

Вот тебе и на, а бешка бы дала совсем другой результат в плане мультипроцессорных вычислений…

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Allowed HTML tags: <a> <em> <i> <img> <strong> <b> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Подробнее о форматировании

CAPTCHA
Введите перечисленные символы, чтобы мы убедились, что вы не робот. Не требуется для зарегистрированных пользователей.
9
x
3
5
q
V
Enter the code without spaces and pay attention to upper/lower case.