Gentoo обрел популярность именно благодаря возможности оптимизировать всю систему, выжав из оборудования максимум. Гентушники сутками напролет ищут волшебную комбинацию gcc’шных флагов и пересобирают свой дистр, убунтовцы же в это время занимаются своими делами. Давай проверим, насколько эффективна оптимизация.

Зачем оптимизировать Linux?

Действительно, зачем нужно пересобирать систему? Ведь мощности современных компьютеров уже давно преодолели тот рубеж, когда нужно было выжать максимум из железа и ОС, чтобы посмотреть фильм или поиграть в игру. В начале 21 века я почти два года работал в source-based дистрибутивах Gentoo и затем — Crux. И только из-за того, что только полностью оптимизированная система позволяла нормально смотреть сжатое видео на компе с CPU Celeron 300A.

Подход, принятый во FreeBSD, вызывал тогда большой энтузиазм и, несомненно, дал еще один импульс развитию Linux. Но сегодня разница в производительности между дистрибутивами уже не так ощутима, многие стали переходить на более удобные в работе Debian и Ubuntu. Например, свой двухъядерный атлон я видел полностью нагруженным только два раза, и то в тех режимах, которые нельзя назвать штатными. Теперь для меня на первый план выходит удобство в развертывании системы и установке программ. Ждать, пока скомпилируется прога, уже тяжело. В Gentoo, кстати, тоже это понимают, и в настоящее время проект вообще не предлагает Stage 1 и Stage 2, использование которых в свое время позволяло максимально оптимизировать систему, но увеличивало время на установку, отнимало место на харде, и главное — увеличивало риск возникновения ошибки. Поэтому прирост производительности в 3-5%, которые давали Stage 1 и 2, по сравнению со Stage 3, стал многим неинтересен.

C другой стороны, пользовательские дистрибутивы сегодня выпускаются с двумя видами оптимизации: x86 и x64 (то есть фактически оптимизированный). Первый позиционируется как универсальный, подходящий под большинство систем, второй обеспечивает максимальную производительность. Имея на руках два и более компьютера с разными процессорами, удобнее вариант с x86 — так проще обновлять системы, создав локальный репозиторий. Но все равно некоторым юзверям проблема «неполной оптимизации» системы не дает спать спокойно, ведь из компа выжата «не вся производительность».

Поэтому, чтобы снять все вопросы, проведем небольшой тест производительности, в котором сравним два дистрибутива: пакетного Linux Mint 9 и source-based Calculate Linux Desktop 10.9 beta (CLD). Первый построен на Ubuntu и имеет несколько дополнительных приложений, которые делают работу более понятной новичку. Второй основан на Gentoo, полностью с ним совместим, причем сегодня его часто используют сами гентушники, чтобы быстро установить свой любимый дистрибутив (при желании из CLD легко делается «чистый» Gentoo).
Оба решения достаточно популярны среди пользователей, и стать первыми им мешает только отсутствие должного PR.

В Linux Mint посмотрим, как влияет на производительность оптимизация системы под i386 и amd64. Версия CLD 10.9 beta доступна пока только в i686 сборке — ее мы и будем тестить, немного поэкспериментировав с флагами оптимизации.

Linux Mint 9 «Isadora»

• Сайт проекта: linuxmint.com
• Дата выхода: 18 мая 2010
• Лицензия: GNU GPL
• Аппаратные платформы: x86_32, x86_64
• Основные компоненты: kernel 2.6.32, glibc 2.11.1, GCC 4.4.3, UDEV 151, HAL 0.5.14, X.Org 1.7.6, Compiz 0.8.4, GNOME 2.30.0, Mesa 7.7.1

Calculate Linux Desktop 10.9 beta

• Сайт проекта: calculate-linux.ru
• Дата выхода: 26 августа 2010
• Лицензия: GNU GPL
• Аппаратные платформы: x86_32, x86_64 (пока недоступна)
• Основные компоненты: kernel 2.6.34.4, glibc 2.11.2, GCC 4.4.3, UDEV 151, HAL 0.5.14, X.Org 1.7.7, Compiz 0.8.4, GNOME 2.30.0, Mesa 7.8.2

Все системы находились в одинаковых условиях, устанавливались в один и тот же раздел. В качестве видеодрайвера использовался стандартный из поставки X.Org. Конфигурация тестового компьютера: AMD Athlon 64 X2 Dual-Core 3600+/2 Гб ОЗУ/Seagate Barracuda ST3160815A/ATI Radeon X800 GTO. Бенчмарки будем снимать при помощи свободно распространяемого мультиплатформенного фреймворка Phoronix Test Suite 2.8 «Lyngen» (phoronix-test-suite.com), который удобен в использовании и содержит более 130 профилей тестов для самых разных подсистем. Для Debian/Ubuntu на сайте проекта доступен deb-пакет.

В портежах Gentoo также есть нужный ebuild, но более ранней версии, поэтому в CLD для установки будем использовать Generic Pаckage. Для его работы понадобится php cli, который мы поставим самостоятельно при помощи emerge. Список всех доступных тестов можно получить, введя команду «phoronix-test-suite list-tests», получить данные по тесту — «phoronix-test-suite info <test name>» (строка Test Type покажет тип теста) и, наконец, запустить тест — «phoronix-test-suite benchmark <test name>». После ввода последней команды будут автоматически скачаны и установлены необходимые для проведения теста зависимости и компоненты, затем будет проведен тест и выдан результат. Все файлы и результаты сохраняются в каталоге ~/.phoronix-test-suite. Учитывая, что для некоторых тестов общий размер файлов, которые необходимо скачать из инета, может достигать 1,5 Гб, после проведения всех замеров лучше их сохранить для повторного использования. Для этого выполни команду «phoronix-test-suite make-download-cache». Все скачанные файлы будут перемещены в подкаталог download-cache.

Результаты самих тестов сохраняются в подкаталоге test-result. При тестировании на другой системе следует перенести оба этих каталога.
Теперь тесты, которые были выбраны. Естественно, что все 133 прогонять не имело смысла (кроме того, некоторые из них требуют платных компонентов), поэтому мы остановились на 10 самых популярных (из VERIFIED, FREE). Приведу несколько тестов, нагружающих процессор: build-mplayer, john-the-ripper (Traditional DES), compress-gzip (сжатие 2 Гб файла) encode-flac, encode-ogg, mencoder (кодирование AVI to LAVC), openssl. Чтобы нагрузить еще и графическую подсистему, попробуем тест warsow (с разрешением 800x600), основой которого является одноименный FPS (warsow.net), и несколько OpenGL-тестов из qgears2. К слову, чтобы заработал qgears2 в CLD, потребовалось выполнить:

# emerge qt-opengl

Общая производительность системы замерялась при помощи теста phpbench, который проверял количество PHP-запросов. Phoronix Test Suite прогоняет тест 3-5 раз и выдает средний показатель и отклонение. В тех случаях, когда результат выбивался из общей картины, бенчмарк запускался повторно.

32 бита vs 64 бита

Большинство современных дистрибутивов Linux выпускается в двух вариантах сборки: под 32- и 64-битные процессоры. Первый по идеологии обеспечивает большую совместимость, второй — производительность. В случае 32-битного варианта в зависимости от конкретного дистрибутива встречаются сборки под i386, i486, i586 и i686, которые означают архитектуру процессора — чем ниже номер, тем больше совместимость. К слову, архитектура P6 (i686, Pentium Pro) представлена в конце 1995 года, и на меньших процессорах сегодня мало кто работает. Поэтому не совсем понятно, почему некоторые современные дистрибутивы до сих пор используют оптимизацию под младшие типы процессора i386-i586, тем более, что они уже не соответствуют минимальным системным требованиям (Крис разбирался с этим вопросом в статье «Подводные камни оптимизации», опубликованной в ][ от 04.2007 — прим.ред.) Кроме этого, в старших типах процессоров появились дополнительные инструкции (вроде MMX, SSE, 3DNow и т.д.), что теоретически увеличивает производительность при работе с мультимедиа.

Версия 32 бита Linux Mint 9 (как и Ubuntu) собрана с i386 оптимизацией, то есть самый-самый минимум. Стоит отметить, на сайте Ubuntu версия 32 бита отмечена как «Recommended for most users», 64-битная же наоборот: «Not recommended for daily desktop usage». И такое читаем при том, что современные ПК сплошь и рядом 64-битные. Смотрим результаты бенчмарков:

Linux Mint 9 (32bit)

• warsow - 2.57 FPS
• build-mplayer - 260.97 sec
• john-the-ripper - 950160333 Real C/S
• compress-gzip - 54.61 sec
• encode-flac - 25.70 sec
• encode-ogg - 36.87 sec
• mencoder (AVI to LAVC) - 54.27
• openssl - 11.90 Signs PS
• phpbench - 19573.00 Score

QGears2:

• CPU-based Raster - Test: Gears - 24.49 FPS
• XRender Extension - Test: Gears - 42.32 FPS
• OpenGL - Test: Gears - 67.68 FPS

Linux Mint 9 (64bit)

• warsow - 2.60 FPS
• build-mplayer - 194 sec
• john-the-ripper - 928921000 Real C/S
• compress-gzip - 55.17 sec
• encode-flac - 14.57 sec
• encode-ogg - 25.39 sec
• mencoder (AVI to LAVC) - 53.24 sec
• openssl - 37.75 Signs PS
• phpbench - 28621 Score

QGears2:

• CPU-based Raster - Test: Gears - 25.64 FPS
• XRender Extension - Test: Gears - 48.72 FPS
• OpenGL - Test: Gears - 87.56 FPS

Прекрасно видно преимущество 64-битной системы над ее 32-битным собратом. Практически во всех процессорных тестах выигрыш составляет 2-8%. Общая производительность системы в PHPBench вообще выросла на 46%. Единственный тест, где 64-битная система уступила 32 битам — это перебор пароля в John the Ripper. Возможно, код JTR настолько вылизан, что оптимизация под 64 бита его только ухудшает. Интересно теперь посмотреть, как покажет себя CLD, который со своей i686-оптимизацией теоретически должен находиться посередине.

Calculate Linux Desktop 10.9 beta (без оптимизации)

• warsow - 2.60 FPS
• build-mplayer - 68.85 sec
• john-the-ripper - 949247333 Real C/S
• compress-gzip - 55.83 sec
• encode-flac - 15.87 sec
• encode-ogg - 32.80 sec
• mencoder (AVI to LAVC) - 53.10 sec
• openssl - 11.8 SPS
• phpbench - 24907 Score

QGears2:

• CPU-based Raster - Test: Gears - 25.30 FPS
• XRender Extension - Test: Gears - 53.86 FPS
• OpenGL - Test: Gears - 135.79 FPS

Результат интересен и неоднозначен. Так, в тесте по сборке MPlayer 32-битная версия CLD «сделала» 64-битную версию Linux Mint в 3 раза. В тесте по кодированию WAV-файла в FLAC CLD лишь немного уступил 64-битному Linux Mint, но при кодировании в OGG преимущество 64-битной системы очевидно. Все это наталкивает на еще один вывод — на результирующую производительность влияет и само приложение.

В тесте OpenSSL, в котором генерируются ключи, 32-битные системы однозначно проиграли 64-битным. В PHPBench 32-битный CLD уступил 64-битной системе 25%, опередив почти на столько же 32-битный Linux Mint.

Количество FPS в Warsow уперлось, скорее всего, в производительность графической подсистемы, которую обеспечивал свободный видеодрайвер Mesa. Зато в OpenGL тесте QGears2 CLD взял верх, возможно, это заслуга более новой версии Mesa.

Как видишь, произведенные замеры показывают, что подход Gentoo имеет смысл, и для конкретной задачи следует подбирать свой дистрибутив. Следуя статистике, можно предположить, что 64-битная версия CLD покажет большую производительность, чем Linux Mint x64. Теперь самое время разобраться, какой прирост дает использование флагов оптимизации.

Оптимизируем CLD

В отличие от пакетных дистрибутивов, source-based дают в руки пользователя полный арсенал средств оптимизации, которую можно производить по двум направлениям — сборка под конкретную марку процессора и установка дополнительных параметров. Первый случай понятен (через параметры «-march» или «-mtune» задается нужный тип процессора; если в качестве аргумента подставить native, то возможности системы будут определены автоматически по /proc/cpuinfo), мы его разобрали выше, и прирост, как видишь, он дает.

Второй вариант оптимизации интересней и, как правило, вызывает много споров, так как единого мнения, что лучше/хуже, на форумах не встретишь. При дефолтовой сборке системы, то есть без каких-либо параметров оптимизации, компилятор обеспечивает меньшее время сборки, максимальную совместимость и возможность отладки программ. Так GCC поддерживает пять уровней оптимизации: от «-O0» (без оптимизации) до «-O3» (максимальная оптимизация) и «-Qs» (оптимизация по размеру). Активация любых параметров оптимизации теоретически позволяет добиться большей производительности программ, уменьшить размер кода, но за счет увеличения времени компиляции и отказа от добавления отладочной информации. Оптимальным считается вариант «-O2», вариант «-O3» используют редко.

Кроме этого, доступен ряд флагов оптимизации, которые уточняют поведение компилятора (например, «-fomit-frame-pointer», «-ffastmath », «-funroll-loops»). Чтобы узнать, какие из них можно указать в CFLAGS, следует ввести команду:

$ gcc -Q --help=optimizers | grep enabled

Все подробности по параметрам компилятора можно найти в «man gcc» или онлайновой документации GCC (gcc.gnu.org/onlinedocs/).
В Gentoo флаги, которые использует при сборке система Portage, хранятся в файле /etc/make.conf. Синтаксис файла весьма прост. Так переменная CHOST указывает на архитектуру, CFLAGS — на флаги сборки и тип процессора. При помощи MAKEOPTS задается количество потоков компиляции, нормальным считается число, равное количеству процессоров плюс один (хотя это не всегда идеальный вариант). Язык пакетов указывается при помощи LINGUAS. Разработчики CLD предложили в make.conf свой вариант параметров оптимизации, который оптимален для большинства случаев (подробнее смотри в документе «Оптимизация системы» — calculate-linux.ru/main/ru/optimization_of_system). Нам остается лишь снять комменты в конфиге и скорректировать опции:

# cat /etc/make.conf
/usr/share/calculate/templates/install/merge/
portage/make.conf
LINGUAS="en ru"
ACCEPT_LICENSE="*"
source /var/lib/layman/make.conf
CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j3"
EMERGE_DEFAULT_OPTS="--jobs=4"
Далее пересобираем:

emerge -e world

И повторяем тесты.

Calculate Linux Desktop 10.9 beta (с оптимизацией)

• warsow - 2.60 FPS
• build-mplayer - 68.14 sec
• john-the-ripper - 949691333 Real C/S
• compress-gzip - 52.10 sec
• encode-flac - 15.92 sec
• encode-ogg - 32.44 sec
• mencoder (AVI to LAVC) - 50.59 sec
• openssl - 11.8 SPS
• phpbench - 24511 Score

QGears2:

• CPU-based Raster - Test: Gears - 25.35 FPS
• XRender Extension - Test: Gears - 53.78 FPS
• OpenGL - Test: Gears - 142.39 FPS

Как видим из результатов, однозначного вывода от использования такой оптимизации сделать нельзя. В чем-то получили совсем небольшой прирост (build-mplayer, john-the-ripper, compress-gzip, encode-ogg, mencoder, QGears2), где-то практически столько же проиграли (encodeflac, phpbench). Хотя все, что есть, вполне укладывается в погрешность, которая есть у любого теста. Зато ресурсы и время, затраченные на пересборку системы, можно было бы использовать более продуктивно.

Выводы

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

Links

• Сайт Phoronix Test Suite — phoronix-testsuite.com
• Параметры оптимизации GCC — gcc.gnu.org/onlinedocs
• Флаги, рекомендуемые гентушниками: en.gentoo — wiki.com/wiki/Safe_Cflags/Intel, en.gentoo-wiki.com/wiki/Safe_Cflags/AMD
• Оптимизация CLD — calculate-linux.ru/main/ru/optimization_of_system

Оптимизация Ubuntu/Debian

Если пользователи Gentoo говорят о возможности пересборки системы на каждом форуме, то убунтийцы и дебианщики об этом скромно умалчивают, считая эту операцию как минимум нецелесообразной. Хотя, при желании, произвести ее самостоятельно не намного сложнее, чем в Gentoo.

Проверяем, что у нас в /etc/apt/sources.list подключены репозитории исходников, такие записи начинаются с deb-src. В Linux Mint по умолчанию загрузка исходников отключена. Обновляем список репозиториев «apt-get update» и ставим пакет apt-build:

$ sudo apt-get install apt-build

В процессе установки будет задан вопрос об уровне оптимизации и типе процессора. Впоследствии изменить настройки можно командой «dpkg-reconfigure apt-build».

Теперь для установки приложений вместо apt-get и aptitude используем apt-build, параметры которого не отличаются. Так, чтобы установить программу, вводим сначала «apt-build update», затем «apt-build install название_пакета». Чтобы проапгрейдить все пакеты, вводим «aptbuild upgrade», а команда «apt-build world» пересоберет систему. Ключ «--force-yes» позволит полностью автоматизировать весь процесс.

Хотя при первом запуске прога попросит тебя прочитать файл /usr/share/doc/apt-build/README.Debian, в нем найдешь ответы на все вопросы. В частности, нужно создать список установленных пакетов командой:

$ sudo dpkg --get-selections | awk '{if ($2 == "install") print $1}'> /etc/apt/apt-build.list