Так дает ли что-нибудь переход к 64-разрядности в плане быстродействия? Этот вопрос мучил меня с того самого момента, как я обзавелся машиной на AMD64. И в попытке ответа на него я провел такое небольшое расследование.
Как известно, FreeBSD текущей ветки (а ею пока остается 6-я, бета) существует в реализации для обеих платформ - и i386, 32-битной, и AMD64, 64-битной по определению (конечно, есть ее версии и для более иных платформ, но к предмету исследования это отношения не имеет). Причем это не просто сборки с соответствующими процессорно-зависимыми флагами, а именно самостоятельные ветви в дереве исходников. Так что чего проще - поставить на наличную 64-битную машину и тот, и другой вариант это операционки, и выполнить какой-либо тест на процессорное быстродействие.
Сказано - сделано: устанавливаю на конфигурацию, описанную в одной из предыдущих заметок, оба варианта FreeBSD 6.0 beta 1, текущей на тот момент времени - в базовой установке, не выполняя никаких оптимизационных мероприятий типа пересборки ядра и мира.
В качестве теста быстродействия не придумал ничего лучше, чем сборку ядра GENERIC - процесс, продолжительность которого преимущественно определяется быстродействием "камня". Для минимизации влияния дисковой подсистемы (а в соответствующей заметке мы видели, что таковое может быть значительным) в каталог /usr/obj, предназначенный для промежуточных продуктов компиляции, монтирую mfs - файловую систему в оперативной памяти (Memory File System):
$ mdmfs -s 1024m md /usr/obj
Лимит на объем mfs (1024 Мбайт) взят с очень большим запасом, реально под сборку ядра будет задействовано чуть больше 200 Мбайт. И - вперед, на Харьков:
$ cd /usr/src
$ make buildkrnel
с выводом команды date до и после сборки в файл для результатов. Для фиксирования времени можно было бы воспользоваться и командой time - но так уж исторически сложилось, что до сих пор в этом качестве я использовал именно date.
В обеих системах процедура выполняется трижды, с размонтированием каталога /usr/obj после каждого раза, по результатам вычисляется среднее арифметическое, которое помещается в таблицу.
Таблица. Среднее время сборки ядра GENERIC
|
AMD64
|
i386
|
AMD64-opt
|
|
678
|
905
|
642
|
Результаты, должен сказать, оказались для меня несколько неожиданными: в варианте для i386 ядро собиралось в среднем за 15 минут, в системе для AMD64 - примерно за 11. То есть выигрыш в быстродействии при переходе на 64-разрядную ОС составил почти 30% (что наглядно видно на диаграмме)
Рисунок. Сравнительное быстродействие 32- и 64-разрядного вариантов FreeBSD при компиляции ядра
Возникает вопрос - а нельзя ли еще улучшить показатели быстродействия за счет дополнительной оптимизации? Ведь по умолчанию базовая система во FreeBSD собирается с флагом -O1. Тогда как ныне, с переходом на gcc версии 3.4.X, можно использовать и более жесткие флаги (по некоторым сведениям, вплоть до -O3). Проверяю: ядро и "мир" 64-битной версии пересобирается с
- исключением ненужных (мне) опций ядра: SCSI- и RAID-контроллеров, лишних сетевых адаптеров, неиспользуемых файловых систем;
- исключением из "мира" лишних компонентов, подобных Kerberos;
- флагами оптимизации
CPUTYPE=athlon64
CFLAGS= -O2 -pipe
COPTFLAGS= -O2 -pipe
После чего троекратно повторяю сборку ядра GENERIC. Результат не впечатляет - среднее время компиляции снижается до 10 минут с небольшим (табл., рис.), то есть полученный выигрыш не достигает даже 10%. Чего, впрочем, и следовало ожидать: все мои предшествующие измерения показывали, что наибольший прирост быстродействия достигается при переходе от -O0 (то есть отсутствия всякой оптимизации) к -O1. Далее кое-какие крохи можно выжать флагом -O2, а вот флаг -O3 в некоторых случаях может привести к снижению скорости.
Тем не менее, вывод для счастливых обладателей машин с процессором AMD64 очевиден: использование родной 64-битной версии FreeBSD дает значимый прирост производительности (хотя, конечно, на реальных пользовательских задачах он до 30% не дотянет).
Обсудить материал, а также поделиться своими впечатлениями от 64-битных машинах и системах для них можно здесь.
