Разница в производительности между скомпилированными и бинарными дистрибутивами / пакетами Linux

Я много искал в интернете и не мог найти точного ответа.

Есть такие дистрибутивы, как Gentoo (или FreeBSD), которые не поставляются с двоичными файлами, а только с исходным кодом для пакетов (портов).

Большинство дистрибутивов используют бинарные бэкэги (debian и т. Д.)

Первый вопрос: насколько можно ожидать увеличения скорости от скомпилированного пакета? Какое увеличение скорости я могу получить от реальных пакетов, таких как apache или mysql? т.е. запросов в секунду?

Второй вопрос: означает ли двоичный пакет, что он не использует никаких инструкций процессора, которые были введены после первого 64-битного процессора AMD? Что касается 32-битных пакетов, значит ли это, что пакет будет работать на 386 и в основном не использует большинство современных инструкций процессора?

Дополнительная информация:

• Я не говорю о десктопе, а о серверной среде.
• Меня не волнует время компиляции
• У меня больше серверов, поэтому увеличение скорости более чем на 15% стоит использовать пакеты с исходным кодом
• Пожалуйста, никаких огненных войн.

Разница в производительности будет почти во всех случаях минимальной и не стоящей. У веских причин использовать исходные дистрибутивы (пока вы используете собственные бинарные пакеты, как позволяет система привязки gentoo):

• Развертывание собственных патчей
• Простая настройка вашего ядра
• Упаковка ваших собственных обновлений

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

Стоит отметить, что вы можете делать это и с бинарным дистрибутивом, создавая свои собственные пакеты RPM или что-то еще. Накладные расходы на управление аналогичны.

Вы не увидите увеличения скорости на 15% при компиляции из исходного кода. Я не хотел бы оценивать его даже в 5% в любом разумном случае. Компиляция из исходного кода дает вам пару вещей:

• Вы можете использовать предпочитаемую версию компилятора
• Вы можете указать компилятору генерировать инструкции из расширений ISA, не используемых в пакетах бинарных дистрибутивов, таких как AESNI и AVX

Тем не менее, компилятор на самом деле очень редко генерирует их в любом случае, и общая экономия от их использования, как правило, очень незначительна, если рассматривать производительность приложения в целом. Такие вещи, как доступ к ОЗУ (и задержка) и задержка диска и устройства, являются гораздо более значимыми факторами, и вам действительно следует начать с этого.

Приложения, которые могут извлечь выгоду из пользовательской компиляции, которая будет работать только на сравнительно недавних процессорах Intel Core i7 или i5, включают в себя те, которые выполняют много векторной математики, и те, которые выполняют много шифрования и дешифрования AES или требуют много случайных чисел. Если вы хотите использовать Intel DRBG, вы должны сделать это и сейчас.

Если ни один из них не применим к вам, вы будете вполне довольны любым из дистрибутивов на основе Debian или Red Hat, и у вас будет намного меньше затрат на обслуживание.

Короткий ответ ... Многие крупномасштабные и чувствительные к скорости / задержке приложения работают в стандартных дистрибутивах Linux. Red Hat, CentOS, Debian, Ubuntu ... В большинстве случаев все они работают хорошо. Большая часть прибыли достигается за счет настройки приложений, стандартной оптимизации ядра и ОС и инфраструктуры.

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

Я управлял серверами на основе Gentoo в высокочастотной финансовой торговой среде. Несмотря на то, что у Gentoo были некоторые незначительные преимущества в производительности, я все же перешел на Red Hat и CentOS. Преимущества Gentoo на бумаге были легко преодолены благодаря более разумному выбору оборудования, улучшенной поддержке интеграции производителей и аппаратных средств сервера, более умному исправлению, выполненному инженерами Red Hat, и более эзотерическим технологиям, таким как обход ядра ...

Если вы находитесь в точке, где проблема эффективности стеков популярных приложений (LAMP) является проблемой, пожалуйста, убедитесь, что оптимизировали аппаратное обеспечение вашего сервера (тип ЦП, структура ОЗУ), сетевую инфраструктуру, систему мониторинга и сможете определить узкие места системы до того, как идти по этому пути.

У вас сейчас ограничение производительности ?

Все сделанные замечания верны. Я просто хотел бы выразить сомнение в том, что увеличение производительности на 5-15% недостижимо, особенно в современных версиях GCC, оно действительно зависит от архитектуры ЦП и от того, насколько близко оно к базовой линии, используемой в качестве цели. для бинарных распределений. GCCs -march = native будет, в дополнение к использованию расширений ISA, также оптимизировать для кеша / размера L1 и L2. Правильно выровненный код (для вашего процессора) может быть намного быстрее, особенно когда используется -flto, так что компилятор может знать все, что ему необходимо учитывать. [некоторые пакеты в настоящее время не работают с LTO, к сожалению]

Кроме того, компиляция выбранных пакетов с -Ofast, в дополнение к march = native и LTO, может существенно изменить ситуацию.

В будущем, если графитовая инфраструктура GCC стабилизируется, это будет иметь потенциал для еще больших выгод.

Это зависит от того, что вы хотите в своей системе, и на самом деле есть три школы мысли (и это верно как для аппаратного, так и для программного обеспечения)

Во-первых, мейнстрим в том, что касается большинства людей, занимающихся SF, - вы хотите, чтобы что-то, что, как вы знаете , работало, вам нужна поддержка и вы хотите это сейчас . В этом случае переходите на системы, основанные на Redhat (RHEL предоставляет вам отличную поддержку, а Centos - это перестройка сообщества хорошо протестированного дистрибутива RHEL). Однако вы не получите последние и лучшие. Во многих случаях это также верно для аппаратного обеспечения.

Второе - это точка зрения «середина дороги», то есть середина, идущая с чем-то вроде убунту. Вам нужны новые пакеты (за небольшую цену, обеспечивающие полную стабильность), вам нужен установщик и приятные вещи .

В некоторых случаях люди сталкиваются с проблемами, но у вас есть новые пакеты, и все это проверено . Хотя в Ubuntu много ненависти, это хороший компромисс между простотой установки и достаточно новыми пакетами. Debian, вероятно, немного более консервативный выбор. В наши дни вы можете даже установить Ubuntu с ядром с низкой задержкой из коробки. Я чувствую, что убунту и дебиан работают на меня, но ммм. Множество мест, где развернуты многие серверы, такие как Facebook и Google, используют эту опцию.

Наконец, есть исходники. Первоначальная настройка в большинстве случаев - это сильная боль в тылу. Вы ошиблись с настройкой ядра? Ой, потрать несколько часов на перекомпиляцию. Вы также не получите инсталлятор - это за n00bs. Вы часто получаете самые передовые приложения и возможность компилировать их по мере необходимости (включая возможность выбора оптимизации для скорости или использования памяти, например) и скользящий выпуск. Если у вас есть очень специфические, эзотерические потребности, Gentoo отлично подходит. Если вам нужно развернуть несколько десятков систем и вы хотите автоматизировать их ... удачи. Исходные дистрибутивы просто не масштабируются. Вы получаете большую гибкость, * некоторую ** дополнительную скорость, но не ремонтопригодность на том же уровне, что и дистрибутив IMO на основе пакетов. Ты нескорее всего, увеличится на 15%, и вы, скорее всего, потратите время, пытаясь настроить флаг компиляции для своего оборудования, а если вы что-то напутаете, потратите время на то, чтобы выяснить, что именно не удалось.

BSD - это отдельное семейство ОС. Некоторые люди клянутся ими (по крайней мере один постоянный пользователь коммуникационной комнаты является пользователем freebsd), и разные BSD имеют разные цели - например, openbsd одержим безопасностью, а freebsd - основной. В некоторых случаях они могут не иметь такой же поддержки аппаратного обеспечения, как Linux, но это зависит от нескольких факторов.