Возможно из вас кто-то когда-то слышал: «Планирую поставить себе 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
Предположим вы сидите на 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
Дополнительно флаг orc, который и так выставлен по умолчанию, помогает задействовать дополнительные инструкции процессора в:
media-libs/gstreamer (audio+video)
Дополнительно флаг 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 тоже можно ускорить.
Дополнительный материал
- Оптимальные опции для x86 GCC
- GCC x86, как уменьшить размер кода
- Оптимизация компиляции GCC на примере Gentoo
- Gentoo: Compilation Optimization Guide
- Аппаратная поддержка алгоритма AES современными процессорами
- How to Customize Your Ubuntu Kernel
- Ubuntu: Supported Hardware
- Пузырьки, кэши и предсказатели переходов
Материал по ICC
- Использование альтернативных компиляторов в Gentoo на примере Intel Compiler Suite
- Gcc vs Intel C++ Compiler: собираем FineReader Engine for Linux
Автор: gnomeby
