Оптимизация приложений в Ubuntu

В своей статье я рассказывал про управление пакетами и в данный момент исхожу из того, что управлять предварительно собранными пакетами, которые доступны в репозиториях, пользователь уже уверенно умеет. Если это не так, то дальше читать не надо.
В семействе команд apt имеется синтаксический аналог команды apt-get под названием apt-build. Для чего он нужен? Загляните в список доступных репозиториев командой cat /etc/apt/sources.list. Видите закомментированные символом решётки строки, начинающиеся с deb-src? Это репозитории, содержащие скрипты для самостоятельной компиляции, сборки и установки deb-пакетов. Почему они закомментированы и зачем нужны? Закомментированы они, чтобы неофиты их не использовали. Для них – готовые deb-пакеты, управляемые командой apt-get. Причём эти пакеты нередко скомпилированы для компьютеров уровня 386, что гарантирует их работоспособность практически на любом компьютере. У вас наверняка компьютер получше, но скорость работы готового софта из репозитория не самая высокая. Короче, если вы не желаете употреблять то, что вам приготовили – готовьте сами с помощью apt-build. Не беспокойтесь -- никаких "страшных" команд вроде cоnfigure, make или make install вам не понадобится. Всё предельно автоматизировано! Однако, подводные камни всё же есть.
По умолчанию команда apt-build отсутствует, поэтому установим её: sudo apt-get install apt-build Начнётся скриптовая установка команды apt-build, в процессе которой вам будет задано несколько вопросов. Три совета. Во-первых, устанавливайте средний уровень оптимизации, во-вторых, согласитесь, что deb-файл для команды apt-build будет добавлен в репозиторий (иначе вы не сможете обновлять эту команду), в-третьих, отметьте именно свой класс компьютера. Например, если у вас многоядерник, то отмечайте core2. В процессе установки автоматически подтянется также куча пакетов, необходимых для компиляции и сборки. Затем в файле /etc/apt/sources.list любым редактором надо раскомментировать строки, начинающиеся с deb-src. Обязательно надо проиндексировать новые источники командой sudo apt-build update Прежде, чем оптимизировать ранее установленный пакет – удалите его. Как это сделать, вы знаете. А если не знаете, то целесообразнее ничего не компилировать и дальше не читать. Кстати, экспериментально установлено, что опция reinstall в команде apt-build срабатывает не всегда. Информация о директории для сборки, опции компилятора, архитектура вашего процессора сохраняется в директории /etc/apt/apt-build.conf. При желании можно кое-что подредактировать вручную, например, повысить уровень оптимизации, но удобнее файл apt-build.conf изменять командой sudo dpkg-reconfigure apt-build. Запустите её и снова ответьте на вопросы, причём в дополнительных параметрах для make обязательно уточните количество ядер, указав их, как -jN, где N -- число на единицу больше, чем количество ядер вашего компьютера. Т.е. для двухъядерному процессору соответствует -j3, трёхъядерному соответствует -j4 и т.д. Иначе, возможно, программа будет работать с одним ядром. Это ускорит сборку. Всё готово, пора компилировать. Например, так: sudo apt-build install firefox Результат появится в локальном репозитории /var/cache/apt-build/repository
На полчаса-час, а то и больше (в зависимости от производительности компьютера и "веса" исходников) после запуска компиляции ваш компьютер будет занят процентов на 70-80. По окончанию компиляции и сборки, если не было ошибок, полученный продукт подвергнется тестированию, на что потребуется ещё столько же времени. Наконец всё закончится. Если в процессе тестирования будет обнаружена хотя бы одна ошибка, то продукт не будет установлен, и вместо него система установит прежний deb-пакет из репозитория. Если такая неприятность произошла, то идём в локальный репозиторий /var/cache/apt-build/repository и ищем установочный deb-пакет с именем компилируемого пакета. Если такой пакет наличествует, то всё в порядке, ошибки не фатальные, скорее всего имеет место конфликт зависимостей. Опять вычищаем из системы неоптимизированный пакет и любым способом, например, посредством утилиты gdebi, пытаемся установить оптимизированный пакет. Если он не будет устанавливаться из-за конфликтов с какими-либо ранее установленными пакетами, то посмотрите, что это за пакеты, и можно ли их удалить. Например, английские спеллеры для «огнелиса» можно удалить безболезненно. Если конфликтующие пакеты нельзя удалить, то сначала надо попытаться их тоже оптимизировать. После этого надо попробовать повторно установить оптимизированный пакет. Если получилось – принимайте поздравления. Для рабочего стола Unity установите также оптимизированный пакет глобального меню; он, очень вероятно, тоже появился в локальном репозитории /var/cache/apt-build/repository.
Бывает, что ничего путного не получилось, и нет времени и/или желания искать причину, тогда снова устанавливаем неоптимизированный, но работоспособный прежний пакет из штатного репозитория с помощью старой знакомой команды sudo apt-get install или с помощью Центра приложений. :) Оптимизированные приложения всегда работают быстрее неоптимизированных на 2-15%, причём прирост тем больше, чем лучше ваш компьютер. Правда, заметить это на современных "цифродробилках" удаётся далеко не всегда. Тогда резонно спросить: "А зачем оптимизировать-то?" Дело в том, что есть классы приложений, где оптимизация даёт ощутимый эффект. Например, конверторы медиафайлов. Так что, если у вас есть немного времени и желания, то рискуйте. В крайнем случае вы не потеряете ничего. Заметьте: пользователи Windows лишены возможности что-либо оптимизировать подобной пересборкой. :)
Версия для печатиВерсия для печати

Рубрики: 

  • 1
  • 2
  • 3
  • 4
  • 5
Всего голосов: 0
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

Страницы

Аватар пользователя Alandr
Дело в том, что есть классы приложений, где оптимизация даёт ощутимый эффект. Например, конверторы медиафайлов.
А можно конкретный пример? Что именно оптимизируется в этом самом конверторе применительно к отдельно взятому конкретному компу?
Аватар пользователя mike
Никому ничего не хочу доказывать. Перекомпилите, пожалуйста, сами ffmpeg или ещё что и сравните. Что именно изменилось -- см. в директории /var/cache/apt-build/build в файле с расширением changes.
Аватар пользователя Alandr
Перекомпилите, пожалуйста, сами ffmpeg
Я не настолько крут :) У меня вполне утилитарный вопрос: периодически у меня возникает необходимость в перекодировании файлов MKV (h.264) в AVI (DivX/XviD), причем определяющим фактором является не качество, а скорость. Вот мне и хотелось узнать, будет ли перекодирование в Ubuntu с оптимизированным кодировщиком быстрее, чем та же операция в Windows. Ну и, само собой, будет ли разница вообще заметна невооруженным глазом, т.к. из-за +2% прироста скорости суетиться не хочется.
Аватар пользователя mike
Вы хотите, чтобы я для вас проделал эту работу? :)
Аватар пользователя Alandr
Вы хотите, чтобы я для вас проделал эту работу? :)
Нет, я прошу, чтобы вы примерно оценили разницу между обычным и оптимизированным конвертором видео. Вы пишете: "оптимизированные приложения ... быстрее ... на 2-15%", а также "есть классы приложений, где оптимизация даёт ощутимый эффект ... конверторы медиафайлов". Правильно ли я понимаю, что в моем случае можно получить больше, чем +15%?
Аватар пользователя mike
Будет ли перекодирование в Ubuntu с оптимизированным кодировщиком быстрее, чем та же операция в Windows? ... Правильно ли я понимаю, что В МОЁМ СЛУЧАЕ можно получить больше, чем +15%?
Вопрос некорректен. %% в заметке касались Ubuntu vs Ubuntu. Про ВАШ СЛУЧАЙ (Windows vs Ubuntu) вообще речи не было. Пожалуйста, выясняйте сами. Извините, но на эту работу у меня нет ни времени, ни желания.
Аватар пользователя Alandr
Вопрос некорректен.
Частично согласен. Я исходил из предположения, что скорость конвертора под Windows равна скорости неоптимизированного конвертора под Ubuntu, но не высказал этого в явном виде. Хорошо, задам корректный вопрос (в последний раз, больше приставать не буду :)). Если сравнить неоптимизированный и оптимизированный конверторы под Ubuntu, то разница будет скорее в диапазоне 2-15% или все-таки 15%+ (не могу понять этого из текста заметки)? Спасибо.
Аватар пользователя mike
Скорее всего <15. Но ваш вопрос опять же некорректен. Смотря какой конвертор и что конвертировать. Поставьте ffmpeg на 4-х ядерник, по умолчанию он работает одним ядром, прооптимизируйте с параметром -j5 и сравните. Получатся разные цифры для разных конвертируемых файлов. На форумах неоднократно сообщалось, что после оптимизации некоторых плейеров HD переставало тормозить. Мелочь, а приятно, не так ли? Заметка содержит всего лишь ознакомительный материал, ранее в "Вестях" не освещавшийся, и как продолжение статьи. Всё, извините, больше отвечать на подобные вопросы я не намерен; хотите конкретики -- пожалуйста, исследуйте самостоятельно.
Аватар пользователя Alandr
Ясно. Спасибо.
Аватар пользователя Shtsh
В статье очень серьёзная ошибка! Параметр -jX для make указывает только количество потоков для сборки! Влияет только на скорость компиляции, но не на скорость работы программы.

Страницы