Стоит ли ставить Gentoo ради ускорения? Оптимизация gentoo

Оптимизация сборки в Gentoo (make.conf)

Оптимизация сборки - одна из основных прелестей Gentoo, однако все описанное применимо к любому случаю компиляции ПО из исходных кодов. Все параметры сборки в Gentoo задаются в файле make.conf.

По сути нас интересует лишь переменная CFLAGS. CXXFLAGS должна быть равна CXXFLAGS="${CFLAGS}", а в MAKEOPTS лишь указывается число параллельно запускаемых процессов компиляции (обычно задают общее число ядер процессоров + 1).

Значение по умолчанию "-O2 -pipe". Параметр -O указывает на используемый уровень оптимизации. Второй уровень считается наиболее высоким безопасным, с третьим уровнем зачастую проявляется нестабильность работы. Параметр -pipe указывает gcc использовать каналы в памяти вместо временных файлов для обмена данными между разными стадиями компиляции. С значением по умолчанию бинарные файлы собираются под архитектуру generic, работают на различных моделях процессоров, но не используют преимущества той или иной модели.

Посмотреть безопасные наборы флагов оптимизаций для различных типов процессоров можно тут: http://en.gentoo-wiki.com/wiki/Safe_Cflags. Бинарники, собранные с указанными там флагами, должны без проблем работать на соответствующем процессоре и при этом использовать большую часть его преимуществ.

В gcc, начиная с версии 4.2, появился флаг -march=native. С этим флагом gcc автоматически определяет тип процессора, поддерживаемые возможности и использует их.

В общем случае для оптимизации нужно сделать следующее:

определить, что умеет ваш процессор: cat /proc/cpuinfo, обратить внимание на строку flags, в частности на mmx*, 3dnow*, sse*, cx*;
посмотреть, что будет использовать gcc с -march=native: gcc -march=native -O2 -Q --help=target -fverbose-asm;
прописать в make.conf -march=native и, возможно, еще некоторые -m*, не включаемые автоматически;
если ваш процессор поддерживает sse и, если у флага -mfpmath= не указано никакого значения, то пропишите в make.conf -mfpmath=sse;
посмотреть, какие оптимизации использует gcc: gcc -march=native -O2 -Q --help=optimizers -fverbose-asm;

если gcc не использует какие-либо оптимизации, включить их в make.conf. Включение некоторых оптимизаций может привести к неработоспособности бинарников, так что здесь стоит обратить внимание только на опцию -fomit-frame-pointer, ее включение безопасно, если вы не собираетесь заниматься отладкой.

В итоге, посмотрите, какие параметры будет использовать gcc с вашими оптимизациями:

gcc <your_options> -Q --help=target -fverbose-asm gcc <your_options> -Q --help=optimizers -fverbose-asm Без использования флага -fverbose-asm gcc показывает неверные данные. Это обсуждается тут: http://www.gentoo.ru/node/14818.

А этот скрипт покажет, что попадет в командную строку компилятора: gcc <your_options> -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'. Интерес представляет, пожалуй, только для разработчиков, но для полноты изложения привожу его здесь.

blog.peter23.com

Оптимизация компиляции GCC на примере Gentoo / Хабр

Оптимизация сборки — одна из основных прелестей Gentoo, однако все описанное применимо к любому случаю компиляции ПО из исходных кодов. Все параметры сборки в Gentoo задаются в файле make.conf. По сути нас интересует лишь переменная CFLAGS. CXXFLAGS должна быть равна CXXFLAGS="${CFLAGS}", а в MAKEOPTS лишь указывается число параллельно запускаемых процессов компиляции (обычно задают общее число ядер процессоров + 1). Значение по умолчанию "-O2 -pipe". Параметр -O указывает на используемый уровень оптимизации. Второй уровень считается наиболее высоким безопасным, с третьим уровнем зачастую проявляется нестабильность работы. Параметр -pipe указывает gcc использовать каналы в памяти вместо временных файлов для обмена данными между разными стадиями компиляции. С значением по умолчанию бинарные файлы собираются под архитектуру generic, работают на различных моделях процессоров, но не используют преимущества той или иной модели. Посмотреть безопасные наборы флагов оптимизаций для различных типов процессоров можно тут: http://en.gentoo-wiki.com/wiki/Safe_Cflags. Бинарники, собранные с указанными там флагами, должны без проблем работать на соответствующем процессоре и при этом использовать большую часть его преимуществ. В gcc, начиная с версии 4.2, появился флаг -march=native. С этим флагом gcc автоматически определяет тип процессора, поддерживаемые возможности и использует их. В общем случае для оптимизации нужно сделать следующее:

определить, что умеет ваш процессор: cat /proc/cpuinfo, обратить внимание на строку flags, в частности на mmx*, 3dnow*, sse*, cx*;
посмотреть, что будет использовать gcc с -march=native: gcc -march=native -O2 -Q --help=target -fverbose-asm;
прописать в make.conf -march=native и, возможно, еще некоторые -m*, не включаемые автоматически;
если ваш процессор поддерживает sse и, если у флага -mfpmath= не указано никакого значения, то пропишите в make.conf -mfpmath=sse;
посмотреть, какие оптимизации использует gcc: gcc -march=native -O2 -Q --help=optimizers -fverbose-asm;
если gcc не использует какие-либо оптимизации, включить их в make.conf. Включение некоторых оптимизаций может привести к неработоспособности бинарников, так что здесь стоит обратить внимание только на опцию -fomit-frame-pointer, ее включение безопасно, если вы не собираетесь заниматься отладкой.

В итоге, посмотрите, какие параметры будет использовать gcc с вашими оптимизациями:gcc <your_options> -Q --help=target -fverbose-asmgcc <your_options> -Q --help=optimizers -fverbose-asmБез использования флага -fverbose-asm gcc показывает неверные данные. Это обсуждается тут: http://www.gentoo.ru/node/14818. А этот скрипт покажет, что попадет в командную строку компилятора: gcc <your_options> -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'. Интерес представляет, пожалуй, только для разработчиков.

habr.com

LikeUnix

Оптимизируем процесс компиляции пакетов в gentoo linux.Я приведу свой пример, настройка оптимизации, вы можете взять мой пример как базовый и доработать под свои нужды.

cat /etc/make.conf

CFLAGS=»-march=core2 —O2 —pipe»Так как я решил использовать 64битный код, то выбрал core2.Уровень оптимизации —O2 , На этом уровне применяются все виды оптимизации, которые не требуют вычисления оптимального выбора между размером и скоростью кода

CXXFLAGS=»${CFLAGS}»Я отставил неизменной.

CHOST=»x86_64-pc-linux-gnu»Указываем что за процессор и в коком бите будет система 32 ли 64.

MAKEOPTS=»-j9″Обычно эту опцию путают с количеством процессоров (ядер) , это чуть не так, тут всего лишь указывается число параллельно запускаемых процессов компиляции.

Цифровой параметр выбирается от количество процессоров(ядер) формула расчета загадочной цифры 9 такова, у меня 4-х ядерный процессор. значит 4*2+1 получиться 9, но сильноповышать не стоит, некоторые пакеты не соберутся.

FEATURES=»parallel-fetch»Это функция дает прирост в компиляции, пока происходит сборка одного пакета, уже качался следующий.

GENTOO_MIRRORS=»http://mirror.yandex.ru/gentoo-distfiles»указываем репозитарий, зеркало в сети.

SYNC=»rsync://rsync-ru.greenmice.info/gentoo-portage»Эта переменная указывает на сервер rsync (сервер удаленной синхронизации) дерева портов.

DISTDIR=»/distfiles»Директория с исходными кодами пакетов, у меня вынесено на отдельный диск, ибо не засорять корень.

ACCEPT_KEYWORDS=»amd64″Этот параметр указывает портажам из какой ветки брать пакеты, в данном случаем из стабильной. доступные опции (x86 /~x86 amd64/~amd64). то есть если параметр ~ то значит пакеты будут все идти из нестабильной ветки (тестовой).

FEATURES=»ccache» # активацииCCACHE_DIR=»/var/tmp/ccache» # директория храненияCCACHE_SIZE=»2G» # размер~По умолчанию компилятор не обращает внимания на ранее скомпилированные файлы и производит полную перекомпиляцию всего приложения во время повторного запуска процесса сборки.Ccache – это кэширующий препроцессор, который позволяет избежать повторной компиляции уже скомпилированных ранее файлов.В Gentoo Linux достаточно набрать команду emerge ccache. Во Freebsd по сложнее, но это другая статейка.Проверяем реальный кэш после 5-й пересборки мира.CCACHE_DIR=»/var/tmp/ccache» ccache —s

CC=»gcc»CXX=»g++»Указываем какие компиляторы использовать.

EMERGE_DEFAULT_OPTS=»-v —keep-going»Настройки компиляции пакетов

FEATURES=»collision-protect»Разруливает ситуации когда один и тот же файл ставят разные пакеты. FEATURES=»metadata-transfer«повышает скорость просмотр зависимостей основного дереваVIDEO_CARDS=»nvidia» #можно указать ati radeonДумаю можно и не объяснять, если вы взялись за установку gentoo linux , то поймете.ALSA_CARDS=»hda-intelтакже указываем звуковую карточку.

HTTP_PROXY=»http://user:[email protected]:port»FTP_PROXY=»http://user:[email protected]:port»RSYNC_PROXY=»http://user:[email protected]:port»Указываем проксю по умолчанию.Или указываем в файле/etc/env.d/99local

INPUT_DEVICES=»mouse keyboard evdev»

Указываем устройства подключенные к компьютеру типа : мышки, клавиатуры, джойстики и т.д.

LIRC_DEVICES=»asusdh»Если у вас есть пульт ДУ , то можно указать флаг вашего пульта. Что бы при установки lirc библиотек он подтянул нужный вам драйвер.

LINGUAS=»ru en»указываем поддержку языка у системы. я указал два, потому, что в некоторых пакетах нету поддержки Русского языка.

FETCHCOMMAND=»/usr/bin/getdelta.sh \${URI}»этот параметр дает вам экономию трафика, но для этого нужно еще установить пакет getdeltap.

USE=»-gnome samba —cups bash-completion unicode 7zip xorg esd xvmc dxr3 audiofile vidix aalib vcd hal xvid lua bzip2 dbus» и т.д.Ставим глобальные использованные флаги системы, это нам понадобиться при установки пакетов. Потому что у каждого пакета есть зависимости, и в зависимости от выбранного профиля, некоторые будут закрыты, вот тут мы их и открывает.Можно конечно и подойти к этому вопросу с другой стороны, отдельно на каждый пакет выставить в определенные зависимости, может вам к примеру к пакету mc не нужно поддержки samba.Все это будет проделываться в специальной директории, /etc/portage/ , но это уже другая история.

source /usr/local/portage/layman/make.confPORTDIR_OVERLAY=»/usr/local/portage»если мы захотим использовать сторонние репозитарии, то нам нужно создать директории и файлы в них, очередность строк ВАЖНА!!!

ACCEPT_LICENSE=»AdobeFlash-10,1 Nero-EULA-US AdobeFlash-10 skype-eula dlj-1,1″этот параметр я как понял новый тип маскировки пакетов, типа что мы разрешаем припроентарное ПО на нашей машине. Можно также отдельно создать файл отдельно с лицензиями./etc/portage/package.license .

APACHE2_MODULES=»actions alias auth_basic auth_digest» и т.д.Можно также указать специальные модули для апача.

likeunix.ru

Оптимизация Gentoo | .hole

————-Автостарт————-

При установке/обновлении KDE прописывает в автостарт ( /usr/share/autostart) кучу многим не нужных вещей, удаляем ненужные /usr/share/autostart/*.desktopТак же можно заглянуть в~/.config/autostart и ~/.kde4/Autostart

————-Prelink————-

Операция динамического связывания программы с опорными библиотеками всегда происходит одинаково, так что можно сделать это раз и навсегда так:# prelink -avfmRВ результате софт будет запускаться быстрее, также уменьшает аппетиты софта относительно памяти.Запускать каждый раз после установки/обновлении/переустановки софта, чтобы все программы были предварительно связаны.Но если что, можно отменить все так:# prelink -ua

————-Ccache————-

Программа ccache – это кэширующий препроцессор, который позволяет избежать повторной компиляции уже скомпилированных ранее файлов. Он генерирует хеш для каждого компилируемого файла, поэтому если с момента предыдущей компиляции файл остается неизменным, его повторная обработка не производится, а используется уже ранее скомпилированный объектный файл. Ccache позволяет существенно поднять скорость повторной компиляции приложения.Для активации ccache в Gentoo достаточно выполнить два простых действия:

1. Установить ccache:# emerge -av ccache

2. Отредактировать файл /etc/make.conf:# vi /etc/make.conf

FEATURES="ccache" #Активируем ccache CCACHE_DIR="/var/tmp/ccache/" # Место хранения кэша CCACHE_SIZE="4G" # Размер кэша

3. Дать права на запись куда понадобится ccache:# chmod 4755 ccache

После выполнения этих действий все порты будут собираться с использованием ccache. Чтобы активировать ccache во время сборки ядра с помощью genkernel, следует использовать следующую команду:# genkernel --kernel-cc=/usr/lib/ccache/bin/gcc --menuconfig all

————-SQLite————-

Для ускорения процесса расчёта зависимостей можно научить portage работать со SQLite1. пакет dev-lang/python должен быть собран с USE флагом sqlite2. создаём файл /etc/portage/modules если он ещё не создандобавляем в него строку

portdbapi.auxdbmodule = cache.sqlite.database

3. # vi make.conf

FEATURES=" ... metadata-transfer"

4. пересоздаём кэш# rm -rf /var/cache/edb/dep && emerge --metadata5. если нужно чтобы eix тоже использовал sqlite то его тоже надо пересобрать с USE флагом sqlite6. для того чтобы eix использовал sqlite и для оверлеев добавляем в /etc/eixrc строки

PORTDIR_CACHE_METHOD='sqlite' OVERLAY_CACHE_METHOD='sqlite'

если не пользуетесь eix-remote update то последнюю строку лучше заменить на

OVERLAY_CACHE_METHOD='parse'

7. пересоздаём кэш eix# eix-update

————-Консоли————-

При дефолтных настройках в Linux запускается 6 виртуальных консолей,переключаться между которыми можно по Alt+Fn или Ctrl+Alt+Fn но обычно их столько не нужно.

Лишние консоли убираются через правку /etc/inittabВ нём находим строки похожие на эти

# TERMINALS c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:2345:respawn:/sbin/agetty 38400 tty2 linux #c3:2345:respawn:/sbin/agetty 38400 tty3 linux #c4:2345:respawn:/sbin/agetty 38400 tty4 linux #c5:2345:respawn:/sbin/agetty 38400 tty5 linux #c6:2345:respawn:/sbin/agetty 38400 tty6 linux

сХ — номер консоли12345 — уровни на которых эти консоли стартуютчтобы убрать лишние — коментируем строки (ставим вначале # ) начиная снизу

————-Оптимизация Chromium c SQLite————-

$ find ~/.config/chromium/ -type f -exec file {} \; | grep "SQLite 3.x" | cut -d":" -f1 | while read line;do sqlite3 "$line" "VACUUM; REINDEX;" ;done

Выжато с блога http://optimization.hardlinux.ru , там еще много ништяков.

hole.group.ws

gentoo-user-ru - CFLAGS, оптимизация

Hi!

Краткое описание что подразумевается под "Hardened Gentoo" и что оно даёт. Hardened Gentoo это просто объединение нескольких разных, часто независимых друг от друга, проектов:

- Hardened toolchain - специальные патчи на gcc/glibc/binutils: * SSP - добавляет в бинарник защиту от переполнения буфера, т.е. прога откомпилированная с SSP сама проверяет что у неё не переполнили буфер и киляет сама себя если обнаруживает переполнение (как следствие бага в самой программе или попытки её взломать эксплойтом). * PIE - не увеличивает защищённость сам по себе, но приводит к генерации более гибкого кода, благодаря чему его можно будет защитить на уровне ядра через PaX. PIE и SSP не зависят друг от друга, и их можно использовать вместе и по отдельности (по сути, после компиляции hardened toolchain можно будет через gcc-config переключаться между всеми вариантами - PIE+SSP, только PIE, только SSP, ничего (т.е. обычный gcc) - например, если какая-то прога не будет компилироваться. - Патчи на ядро. Их бывает много, и разных, :) но в Gentoo есть поддержка только четырёх из них - PaX, SeLinux, GrSecurity и RSBAC. Функциональность они добавляют трех типов: 1) Защита от переполнения буфера (а-ля SSP но со стороны ядра и другими методами, так что они друг друга дополняют): PaX. Например, PaX позволяет запретить выполнение кода в страницах памяти с данными (софтварная реализация NX-бита, которые появился только в 64-битных процах Intel) - PaX просто кильнёт процесс если он попытается нарушить эту защиту; при загрузке программы в память грузит все её функции по случайным адресам, чтобы эксплойту было очень сложно узнать на какой адрес передавать управление (это становится возможным благодаря компиляции с PIE). 2) Отключение потенциально опасных "фич" ядра: GrSecurity, RSBAC. Пример: запрет выполнять mount внутри chroot - чтобы хакер взломавший chroot-нутый демон и получивший root-а не смог выйти из chroot. 3) Ограничение прав процессов и юзеров, в т.ч. (я бы даже сказал - в основном) юзера root: SeLinux, GrSecurity/RBAC, RSBAC. Здесь идея в том, что админу (вам :)) нужно подготовить список с указанием какие проги/юзеры что имеют право делать. Пример: можно ограничить root-овый процесс apache из всех прав root-а только возможностью садиться на 80-й порт и читать файлы в /etc/apache2/. В этом случае даже если его и взломают, и хакер получит "root", то ЭТОТ "root" сможет делать только вышеперечисленные операции... хакер будет крайне разочарован. :) Эти три "фичи" тоже друг не зависят одна от другой. Но сами патчи - SeLinux, GrSecurity и RSBAC обычно между собой не совместимы и нужно использовать только один из них. Впрочем, в Gentoo сумели объединить SeLinux и GrSecurity вместе. Часть GrSecurity, которая занимается третьей фичей (ограничением прав) называется RBAC, и её использовать вместе с SeLinux нельзя - или-или. Итого, варианты есть, например, следующие: - PaX + GrSecurity - PaX + GrSecurity (без RBAC) + SeLinux - PaX + SeLinux - PaX + RSBAC - ... etc ... Я выбрал первый (PaX+GrSecurity) т.к. во-первых настройка SeLinux обещает быть кошмаром, в отличие от GrSecurity/RBAC; во-вторых на мой взгляд поддержка RSBAC в Gentoo ещё сыровата; и в-третьих ну понравился мне GrSecurity, понравился. :))

Итого, процесс выглядит следующим: - переключаемся на hardened toolchain и пересобираем им всю систему, чтобы все бинарники использовали PIE и SSP (после этого система становится защищена SSP) - устанавливаем hardened-sources (они содержат патчи PaX + GrSecurity + SeLinux + допольнительные от Gentoo) и компилируем их с поддержкой PaX, GrSecurity и GrSecurity/RBAC - перегружаемся с новым ядром (после этого система становится защищена ещё и PaX+PIE и GrSecurity) - некоторое время настраиваем и отлаживаем ограничения доступа (после чего система становится защищена ещё и GrSecurity/RBAC)

Ожидаемые проблемы: - не всё может скомпилироваться с PIE+SSP - возможно отдельные пакеты нужно будет патчить или компилировать без одной или обоих из них (мне пока потребовалось через gcc-config переключаться на vanilla gcc только для компиляции X-ов чтобы они работали с ATI-дровами) - не всё может нормально работать, т.к. некоторые программы (обычно упоминают X-ы и java) используют выполнение динамически сгенерированного кода для вполне легальных целей, а теперь при попытке это делать они будут киляться либо SSP либо PIE+PaX - для этих программ нужно будет индивидуально отключать часть защит PaX (для этого есть специальные утилиты, например paxctl) и/или компилировать их без SSP - не всё может работать из-за ограничений "фич" ядра GrSecurity - в этом случае нужно будет часть защит GrSecurity отключать (глобально, в make menuconfig) - настроить ограничения прав доступа может оказаться не просто, и в любой момент когда какая-нить прога сделает что-то, что мы при настройке её прав не учли - она будет прибита ядром... и придётся эти правила в срочном порядке фиксить

Ну что, поехали... :)

Слишком сильная оптимизация (-O3) вместе с hardened toolchain может приводить к разным глюкам и сбоям компиляции, поэтому нужно в /etc/make.conf заменить -O3 на -O2.

Переходим на hardened-профайл. (Теоретически вместо этого можно было просто добавить в USE-флаги: "hardened pie ssp".)

ln -snf ../usr/portage/profiles/hardened/x86/2.6/ /etc/make.profile После переключения профайла на hardened/x86/2.6/ выключилось несколько нужных мне USE-флагов, которые в обычных профайлах включены автоматически - я их дописал в make.conf: avi encode gtk2 jpeg mpeg oss quicktime spell truetype xv bitmap-fonts truetype-fonts type1-fonts

Компиляция hardened-toolchain и пересборка им всех остальных пакетов:

emerge binutils gcc glibc emerge -e world dispatch-conf

Далее, нужно поставить ещё несколько пакетов:

emerge paxtest paxctl gradm

paxtest можно было поставить и раньше, до перехода на hardened toolchain. Эта утилитка пытается делать разные опасные операции (типа переполнения стека с выполнением кода), которые обычно выполняют эксплойты. Если система защищена, то все её попытки будут пресечены, о чём она и сообщит. В общем, можно её погонять до установки hardened toolchain, после а так-же после перезагрузки с ядром где включён PaX, по приколу. :)

paxtest как свою зависимость так-же установит прогу chpax - это вроде старый способ управлять PaX, вместо которого лучше использовать paxctl. Но некоторые проги, распространяемые без исходников, скомпилированы так, что paxctl с ними работать не может, и приходится юзать chpax.

Ну а gradm нужен для настройки RBAC в GrSecurity - тех самых ограничений прав для процессов и юзеров.

Что касается настроек ядра. Я для начала настроил всё так, как описано в доке Gentoo и GrSecurity - при этом не все защиты включены, но большинство софта при таких настройках будет работать. В процессе разбора с настройками возникло несколько теоретических предположений:

Если загрузить hardened ядро ДО перекомпилирования системы, то могут возникнуть проблемы если включена эта опция:

PaX -> Non-executable pages -> Disallow ELF text relocations

На сервере, где нет X-ов, можно дополнительно включить: (не забыть перед этим проверить, что от этого не перестало работать что-то кроме X-ов, в частности hwclock): Grsecurity -> Address Space Protection -> Disable privileged I/O

Кроме того, ещё есть предположение, что некоторые ограничения chroot могут помешать операциям типа инсталляции Gentoo (которая идёт внутри chroot) или попытке починки системы (если, например, для этого загрузиться с CD с таким hardened ядром):

Grsecurity -> Filesystem Protections -> Deny mounts Grsecurity -> Filesystem Protections -> Deny double-chroots Grsecurity -> Filesystem Protections -> Deny (f)chmod +s Grsecurity -> Filesystem Protections -> Deny mknod

-- WBR, Alex. -- [hidden email] mailing list

gentoo.2317880.n4.nabble.com

Стоит ли ставить Gentoo ради ускорения?

Возможно из вас кто-то когда-то слышал: «Планирую поставить себе Gentoo, он будет лучше использовать возможности моего процессора и будет выжимать из него максимум». Чтож, давайте разберёмся…

Какие вообще бывают оптимизации под процессор

В основном под этим подразумевают использование дополнительных наборов инструкций типа: MMX, SSE, AES и AVX при компиляции приложений. Однако, если копнуть глубоко, существуют и другие оптимизации и не только для приложений.Я выделил следующие группы оптимизаций:

Оптимизации кода
- Оптимизации кода при компиляции под дополнительные наборы инструкций x86: MMX, SSE, AES, ATA, AVX и др.
- Оптимизации кода при его статическом анализе во время компиляции: разворачивание хвостовых рекурсий, убирание неиспользуемых участков кода, игнорирование бессмысленных условий и др.
- Оптимизации для лучшего попадания в кеш процессора.
Оптимизации кода на уровне ядра: криптографических методы из Cryptographic API.

Оптимизации под дополнительные наборы инструкций лучше всего освещены на странице: Intel 386 and AMD x86-64 GCC Options. Начиная с Pentium MMX нам стал доступен MMX, потом AMD сделала 3DNow!, потом в Pentium III появилось SSE, и пошло поехало. Intel Haswell, который порадовал нас в этом году, поддерживается: MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2 и F16C.Работа с вещественными числами (FPU) тоже косвенно относится к дополнительным наборам инструкций, ибо компилятор для этого может использовать SSE. Это быстрее x87 инструкций и не блокирует MMX. Ешё немного об этом будет ниже.

Следует отметить ещё одну важную особенность. Когда вслух упоминаются аббревиатуры SSE, MMX и AES, то очень часто у людей, знакомых с этими понятиями, всплывает в голове картинка, повествующая о нелёгкой жизни Си-программистов, которые ассемблерными вставками «пилят» поддержку этих инструкций в своём софте. А на самом деле существует аж 3 способа использования этих наборов инструкций: автоматически компилятором при статическом анализе кода, вручную с помощью специальных функций компилятора и вручную ассемблерными вставками (например: How to optimize code for MMX processors). В каких именно случаях GCC автоматически использует наборы инструкций, если они разрешены, — не понятно, но в руководстве четко сказано, что такие случаи есть (будем надеяться в комментариях напишут).

Оптимизации кода при статическом анализе лучше всего освещены на странице Options That Control Optimization. Возможностей очень много, но дабы не запутаться, они сгруппированы в мета флаги: O0, O1, O2, O3. Больше информации по этим флагам можно найти ниже в прилинкованных статьях.

Оптимизации для лучшего попадания в кеш процессора. Быстро объяснить не получится, поэтому я отсылаю читателя в другую статью: Пузырьки, кэши и предсказатели переходов. Я лишь скажу, что для анализа мест, которые можно оптимизировать программисты могут использовать Intel VTune Performance Analyzer и AMD CodeAnalyst. И, вроде как, ICC Intel C++ compiler умеет делать такие оптимизации в некоторых случаях автоматически, а как дела с этим у GCC сегодня, надеюсь знающие люди дополнят в комментариях.

Оптимизации кода на уровне ядра. Позволяют ускорять функции в Cryptographic API Framework, такие как шифрование AES, Twofish и другие, используя дополнительные наборы инструкций, такие как: SSE, AVX, AES. Эти функции могут использоваться в других модулях ядра, а также вызываться снаружи из приложений.

С теорией разобрались, перейдём к тому, как это используется.

Если у вас Ubuntu

gcc -dumpmachine

На 32-битной Ubuntu 12.04 LTS Server мы увидим i686-linux-gnu, а на 64-битной — мы должны увидеть x86_64-linux-gnu.Предположим у вас 32-битный Pentium 4, вам доступны MMX, SSE и SSE2, но они не использовались при генерации пакетов, так как эти же пакеты должны работать на Intel Celeron, где есть только MMX, и возможно даже на Pentium Pro, где нет даже MMX. Дополнительные наборы инструкций будут задействованы только в пакетах, которые сами на лету определяют процессор и включают более быстрый алгоритм для данного процессора. Хорошая новость состоит в том, что это происходит почти во всех мультимедия пакетах.Также не ясно с какими оптимизациями кода собиралась 32-битная Ubuntu. Если посмотреть вывод GCC, то есть немного из -O1, и из -O2 и из -O3. Если пакеты для Ubuntu под конкретную версию принято собрать на самой системе с опциями компиляции по умолчанию, то видимо они собираются не самым оптимальным (из рациональных) способом.Ну и наконец, функции в kernel Cryptographic API используются не оптимизированные. Оптимизированные функции под дополнительные наборы инструкций присутствуют в системе только в виде модулей, и только для i586 и AES (для VIA Nano), но не подгружены по умолчанию. Также не понятно, что из 586 можно использовать для оптимизаций.

В Ubuntu 12.04 64-bit дела гораздо лучше. Во-первых: gcc по умолчанию для 64-битных систем использует расширения: MMX, SSE, SSE2, поэтому код может быть несколько оптимизирован. Во-вторых для x86-64 по умолчанию -mfpmath=sse, что ускоряет арифметику для вещественных чисел. Оптимизированные функции kernel Cryptographic API под дополнительные наборы инструкций присутствуют в системе в модулях, но не подгружены по умолчанию. По крайней мере их можно включить.Ну и наконец, gcc собирает пакеты с тем же странным набором оптимизаций, что и для Ubuntu 32-битной.

Если у вас Gentoo

Помимо глобальных флагов, существуют также локальные флаги, которые задействуют дополнительные инструкции для некоторых приложений. Такие как: 3dnowext, ssse3, sse4, sse4_1, avx, avx128fma, avx256 и aes-ni. Всё что у вас поддерживается лучше тоже выставить.

Современный stage3 под amd64 по умолчанию выставляет: bindist, mmx, sse, sse2. К несчастью bindist отключает дополнительные инструкции в некоторых пакетах для их переносимости. Если вам нужен bindist, используйте дополнительно cpudetection, чтобы нивелировать недостатки bindist флага в некоторых приложениях.

В каких же пакетах Gentoo можно получить прирост?

app-arch/libzpaqapp-emulation/bochsmedia-libs/freeverb3 (audio)media-libs/libpostproc (video)media-libs/libvpx (video VP8)media-plugins/vdr-softdevice (video)media-sound/mpg123media-video/ffmpegmedia-video/libavmedia-video/mplayermedia-video/mplayer2media-video/vlcnet-libs/cyasslnet-misc/bfgminer (bitcoin)sci-biology/raxmlsci-libs/fftwsci-chemistry/gromacssys-fs/loop-aesx11-libs/pixman

Дополнительно флаг orc, который и так выставлен по умолчанию, помогает задействовать дополнительные инструкции процессора в:media-libs/gstreamer (audio+video)

Дополнительно флаг cpudetection, который не выставлен по умолчанию, помогает задействовать дополнительные инструкции процессора на лету в:media-sound/jack-audio-connection-kitmedia-video/ffmpegmedia-video/libavmedia-video/mplayermedia-video/mplayer2sci-libs/mpir

Выводы

В 32-битных системах наибольший прирост от Gentoo можно получить на процессорах последних моделей.
В 64-битных системах прирост от Gentoo можно получить только за счёт использования более новых версий компилятора и оптимизации -O2.
Даже Gentoo, даже после чтения официальной документации не мешает поднастроить.
Не Gentoo тоже можно ускорить.

Дополнительный материал

Материал по ICC

Автор: gnomeby

Источник

www.pvsm.ru

Стоит ли ставить Gentoo ради ускорения? / СоХабр

Какие вообще бывают оптимизации под процессор

В основном под этим подразумевают использование дополнительных наборов инструкций типа: MMX, SSE, AES и AVX при компиляции приложений. Однако, если копнуть глубоко, существуют и другие оптимизации и не только для приложений. Я выделил следующие группы оптимизаций:

Оптимизации кода
- Оптимизации кода при компиляции под дополнительные наборы инструкций x86: MMX, SSE, AES, ATA, AVX и др.
- Оптимизации кода при его статическом анализе во время компиляции: разворачивание хвостовых рекурсий, убирание неиспользуемых участков кода, игнорирование бессмысленных условий и др.
- Оптимизации для лучшего попадания в кеш процессора.
Оптимизации кода на уровне ядра: криптографических методы из Cryptographic API.

Оптимизации под дополнительные наборы инструкций лучше всего освещены на странице: Intel 386 and AMD x86-64 GCC Options. Начиная с Pentium MMX нам стал доступен MMX, потом AMD сделала 3DNow!, потом в Pentium III появилось SSE, и пошло поехало. Intel Haswell, который порадовал нас в этом году, поддерживается: MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2 и F16C. Работа с вещественными числами (FPU) тоже косвенно относится к дополнительным наборам инструкций, ибо компилятор для этого может использовать SSE. Это быстрее x87 инструкций и не блокирует MMX. Ешё немного об этом будет ниже.

Оптимизации кода при статическом анализе лучше всего освещены на странице Options That Control Optimization. Возможностей очень много, но дабы не запутаться, они сгруппированы в мета флаги: O0, O1, O2, O3, Ofast. Больше информации по этим флагам можно найти ниже в прилинкованных статьях.

С теорией разобрались, перейдём к тому, как это используется.

Если у вас Ubuntu

Предположим вы сидите на Ubuntu. В зависимости от разрядности операционной системы у вас на выбор пакеты с суффиксом i386 или amd64 (пример). i386 вовсе не означает, что пакет будет работать на любом процессоре, начиная от 386, он просто обозначает, что целевое назначение пакета — 32-битная платформа x86. В свою очередь amd64 означает поддержку 64-битной платформы x86-64. Мы можем это легко проверить, если наберём в консоли:gcc -dumpmachine На 32-битной Ubuntu 12.04 LTS Server мы увидим i686-linux-gnu, а на 64-битной — мы должны увидеть x86_64-linux-gnu. Предположим у вас 32-битный Pentium 4, вам доступны MMX, SSE и SSE2, но они не использовались при генерации пакетов, так как эти же пакеты должны работать на Intel Celeron, где есть только MMX, и возможно даже на Pentium Pro, где нет даже MMX. Дополнительные наборы инструкций будут задействованы только в пакетах, которые сами на лету определяют процессор и включают более быстрый алгоритм для данного процессора. Хорошая новость состоит в том, что это происходит почти во всех мультимедиа пакетах. Также не ясно с какими оптимизациями кода собиралась 32-битная Ubuntu. Если посмотреть вывод GCC, то есть немного из -O1, и из -O2 и из -O3. Если пакеты для Ubuntu под конкретную версию принято собрать на самой системе с опциями компиляции по умолчанию, то видимо они собираются не самым оптимальным (из рациональных) способом. Ну и наконец, функции в kernel Cryptographic API используются не оптимизированные. Оптимизированные функции под дополнительные наборы инструкций присутствуют в системе только в виде модулей, и только для i586 и AES (для VIA Nano), но не подгружены по умолчанию. Также не понятно, что из 586 можно использовать для оптимизаций.

В Ubuntu 12.04 64-bit дела гораздо лучше. Во-первых: gcc по умолчанию для 64-битных систем использует расширения: MMX, SSE, SSE2, поэтому код может быть несколько оптимизирован. Во-вторых для x86-64 по умолчанию -mfpmath=sse, что ускоряет арифметику для вещественных чисел. Оптимизированные функции kernel Cryptographic API под дополнительные наборы инструкций присутствуют в системе в модулях, но не подгружены по умолчанию. По крайней мере их можно включить. Ну и наконец, gcc собирает пакеты с тем же странным набором оптимизаций, что и для Ubuntu 32-битной.

Если у вас Gentoo

То скорее всего вы читали эту страницу из руководства. А значит вы выставили себе -O2 и -march=native (или правильный процессор). Но скорее всего вы во-первых: не заходили в Cryptographic API при настройке ядра и не ускорили себе некоторые инструкции, а как минимум стоит ускорить AES. Во-вторых: вы скорее всего не выставили USE-флаги для дополнительных инструкций процессора из тех, что вам доступны: 3dnow, mmx, sse, sse2, sse3. Или выставили не все из них. А это значит, что для приложений намеренно выносящих активацию оптимизаций в USE-флаги, вы остались без дополнительного ускорения. Помимо глобальных флагов, существуют также локальные флаги, которые задействуют дополнительные инструкции для некоторых приложений. Такие как: 3dnowext, ssse3, sse4, sse4_1, avx, avx128fma, avx256 и aes-ni. Всё что у вас поддерживается лучше тоже выставить. Современный stage3 под amd64 по умолчанию выставляет: bindist, mmx, sse, sse2. К несчастью bindist отключает дополнительные инструкции в некоторых пакетах для их переносимости. Если вам нужен bindist, используйте дополнительно cpudetection, чтобы нивелировать недостатки bindist флага в некоторых приложениях.В каких же пакетах Gentoo можно получить прирост? app-arch/libzpaq app-emulation/bochs media-libs/freeverb3 (audio) media-libs/libpostproc (video) media-libs/libvpx (video VP8) media-plugins/vdr-softdevice (video) media-sound/mpg123 media-video/ffmpeg media-video/libav media-video/mplayer media-video/mplayer2 media-video/vlc net-libs/cyassl net-misc/bfgminer (bitcoin) sci-biology/raxml sci-libs/fftw sci-chemistry/gromacs sys-fs/loop-aes x11-libs/pixman

Дополнительно флаг cpudetection, который не выставлен по умолчанию, помогает задействовать дополнительные инструкции процессора на лету в: media-sound/jack-audio-connection-kit media-video/ffmpeg media-video/libav media-video/mplayer media-video/mplayer2 sci-libs/mpir

Выводы

В 32-битных системах наибольший прирост от Gentoo можно получить на процессорах последних моделей.
В 64-битных системах прирост от Gentoo можно получить только за счёт использования более новых версий компилятора и оптимизации -O2.
Даже Gentoo, даже после чтения официальной документации не мешает поднастроить.
Не Gentoo тоже можно ускорить.

Дополнительный материал

Материал по ICC

Добавочка: Пользователь kekekeks поделился рецептом как можно пересобрать некоторые пакеты для Ubuntu с оптимизацией.

sohabr.net