Будет ли пакет, скомпилированный мной, работать лучше, чем установка из репозиториев?

Если вы не проводите серьезную оптимизацию во время сборки или не вносите существенных изменений в функции, которые вы создаете, для очень сложных программ, очень маловероятно, что вы увидите какое-либо преимущество в производительности. И даже с серьезными оптимизациями вы все равно увидите лишь минимальное улучшение. Нет никакого реального преимущества для создания приложений таким образом, по большей части в Ubuntu.

Вы не не получите никакого повышения производительности, если перекомпилируете что-то в своей системе, если только ваша Ubuntu не имеет особых настроек, как, например, использование множества базовых библиотек из другого источника.

Хитрость в том, что все, что упаковано для Ubuntu, построено на реальной системе Ubuntu, , которая использует те же пакеты на вашем . Это означает, что среда сборки на 100% одинакова, все библиотеки имеют идентичные привязки и т. Д., Отличается только пользовательская конфигурация. Из-за этого при сборке бинарных пакетов может быть применена большая агрессивная оптимизация, и они все равно будут действовать в вашей системе. Таким образом, Ubuntu может предоставлять пользователям пакеты с максимальной производительностью.

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

Что касается стабильности, то рассуждения такие же. Поскольку пакеты собраны в системе Ubuntu, в которой есть те же библиотеки , что и у вас (при условии, что вы получили их из репозиториев), их поведение будет отличаться.

В заключение, не ожидайте никакой прибыли при создании приложений самостоятельно.

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

Обычно нет, но есть исключения здесь и там.

1. Компиляция Firefox 18 из исходного кода с флагами «-march = native -pipe -O2», казалось, уменьшила эти маленькие периоды безответственности во время загрузки страницы, но больше ничего не изменилось. Компиляция его с флагами "-march = native -pipe -Os" уменьшила его на 16,5 МБ в ОЗУ. Как следствие, он запустился заметно быстрее и, похоже, занимал меньше оперативной памяти при более чем 30 открытых вкладках, но все пункты меню, казалось, работали вечно.
2. Компиляция OpenArena из исходного кода с флагами "-march = native -pipe -O2" увеличила среднюю частоту кадров с 28,7 (результаты timedemo) до 33,4 по сравнению с установкой из репозитория. Это большое улучшение.

Все остальное, что я скомпилировал из исходного кода, либо имеет, работает примерно одинаково, либо иногда ломается / работает как дерьмо.

Я статистик, работающий в R. Я использую систему с двойной загрузкой (Ubuntu / Windows 7). Когда я установил R из репозитория Ubuntu (r-base, r-base-dev, ...), его производительность была ужасной! Время, необходимое для запуска определенного сценария (вычисление траектории частицы в цикле), было на 50% больше, чем в Windows! В унынии я удалил версию R, предоставленную Ubuntu, и собрал свою собственную с флагами "-march=native -O3" для всех компиляторов (CFLAGS, CXXFLAGS, FFLAGS, OBJCFLAGS, FCFLAGS), и результат был. .. Впечатляет, мягко говоря. Мои сценарии выполнялись в два раза быстрее, чем в Windows 7. Кроме того, иногда официальные репозитории содержат доисторические версии библиотек, и разработчик может захотеть каждый раз собирать свежие библиотеки.

Кроме того, я также скомпилировал ядро ​​Linux, но выигрыш был намного скромнее (5%). Так что это действительно зависит от программного обеспечения, от того, сколько он получит, используя вашу нативную архитектуру и т. Д. Некоторые шахматные движки (например, Stockfish) полагаются на инструкции sse и popcnt, поэтому, если скомпилированный двоичный файл по умолчанию - разъем всех процессоров, мастер из самых старых - не поддерживает новые интересные вещи, на которые способен ваш процессор, рассмотрите возможность его компиляции.