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

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

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

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

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

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

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

Я статистик, который работает в 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 инструкции, поэтому, если скомпилированный двоичный файл по умолчанию - разъем всех процессоров, мастер самых старых - не поддерживает новые интересные вещи, на которые способен ваш процессор, рассмотрите возможность его компиляции.

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

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 по сравнению с установкой из репозитория. Это большое улучшение.

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