Re: Перекомпиляция основных программ
Н. Артём <Artiom14@yandex.ru> writes:
>> Настоящие хардкорные гентушники говорят прежде всего о гибкости,
>> которую дает перекомпиляция (use-флаги, позволяющие для многих
>> пакетов включить/выключить использование каких-либо библиотек).
> Вряд ли это сильно влияет на скорость. Скорее, на объём занятого
> дискового пространства. Разве сейчас это кого-то сильно волнует на
> десктопе?
"Доктор, вы маньяк". Разумеется, ни то ни другое _обычно_ никого не
волнует. А вот избежать линковки с чем-нибудь падучим, или некрасивым,
или просто не вписывающимся в систему -- бывает желательно, точно так же
как выбрать из альтернативных реализаций какой-нибудь фичи менее
популярную.
Я вот (для домашних дебианов) emacs-snapshot с orebokech.com пересобираю
с athena вместо Gtk, и тут ни при чём ни скорость, ни дисковое
пространство, ни даже красота или кошерность -- просто у emacs-gtk есть
давний баг, из-за которой он не может открыть X connection после того,
как какой-нибудь из дисплеев один раз уронят. Это реально достает -- при
паттернах использования вроде "вытащил фрейм десктопного емакса на
нетбук, поработал, усыпил нетбук". Основной debian'овский emacs пока
собирают и под athena, но я не рассчитываю, что это будет долго
продолжаться. Вот в генте решили "ничего не решать" за пользователя в
смысле таких взаимозаменяемых опций; подход имеет право на
существование.
[Правда, если бы гентообразные были сильнее распространены, это убило
бы последний стимул писать софт с динамической-плагинистой архитектурой
-- ну как vlc умеет все свои варианты UI без пересборки. А хотелось бы,
чтобы такого софта становилось со временем больше].
>> оказывается, что к *смыслу* изменений оно никакого отношения не имеет, а
>> просто какой-то кусок кода или данных расположился удачнее. Такой тип
>> ошибок почему-то редко кто подозревает; обычно присматриваются к
>> методике тестирования в части порядка запуска, или там набора исходных
>> данных -- при том, что основная составляющая ошибки может быть к моменту
>> запуска уже внесена.
> Но, тем не менее, что-то же этому способствовало?
Как правило, причина подобных вещей известна и её рано или поздно
начинает контролировать компилятор (или даже умеет контролировать -- при
определенных опциях -– но не в упомянутом мной случае). Проблема в том,
что если компилятор *не оптимизирует* какой-нибудь параметр (возьмем
простой пример: сборку с -O1, в которой не включается -falign-jumps и
подобное) -- этот параметр получается не "стабильно пессимизированный",
а непредсказуемый: сегодня у вас самый_главный_цикл попал на границы
кэшлайна, а завтра вдруг из-за совершенно нерелевантных причин не попадет.
Такие засады можно побороть обработкой массива измерений, но (1) массив
должен быть не просто по куче запусков, а по куче пересборок, (2) способ
получения этой кучи пересборок должен "зашумлять" те факторы, влияние
которых мы хотим исключить. И вот как добиться выполнения пункта (2) --
в общем случае не очень понятно.
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
Reply to: