Re: Перекомпиляция основных программ
Н. Артём <Artiom14@yandex.ru> writes:
>> волнует. А вот избежать линковки с чем-нибудь падучим, или некрасивым,
>> или просто не вписывающимся в систему -- бывает желательно, точно так же
>> как выбрать из альтернативных реализаций какой-нибудь фичи менее
>> популярную.
> Хм... В сравнении со "стабильным Debian" это не является плюсом. Они и
> так пытаюся избежать использования чего-нибудь падучего.
Пример с emacs был приведен (в том числе) и в пользу того, что падучесть
и глючность тоже бывают субъективными. Кому-то может быть очень важно,
что emacs/GTK умеет рисовать меню на иврите справа налево [он, должно быть,
умеет], а бага с падающими дисплеями ему не впёрлась, потому что
у него когда падают иксы -- и так падает всё полезное. А вот кому-то
очень важно наоборот.
> Отсюда вывод: выбрать другой дистр проще (ну, если имеется возможность
> выбора).
"Нужен другой провайдер? Убирайтесь в свою Жмеринку, там будет другой
провайдер!". Подход по-своему логичный, но где-то варварский.
Возможность-то сменить дистр обычно имеется, а вот желание
отсутсвует. К тому же, если у вас требования к сборке чего бы то ни было
отличаются от общепринятых, менять на что-либо debian -- чистое
безумие. Не факт, что в debian соберут как вам надо, но на это хотя бы
есть шанс -- и продуманы-протоптаны запасные варианты на случай, если не
соберут (тот же vim я изрядно долго ставил "чупринской сборки из
вагнеровского репозитария").
> Ну, конечно имеет. Но никто не мешает сделать тоже самое, например в
> Debian? Если это единственная причина существования такого подхода -
> он неоправдан. Ведь есть и другие причины..? (а тестов так и нет)
А я наоборот утверждаю, что гибкость "содержательных" сборочных
параметров -- единственное разумное оправдание source-based сред
(gentoo, freebsd ports); и никаких тестов, что характерно, тут не
нужно -- когда вам эта гибкость потребуется, вы будете *точно* знать,
что она нужна.
> Ничего подобного. Плагины - совсе другой разговор. Их возможно
> включать и выключать динамически. Добавлять, убавлять и ещё чёрт знает
> чего делать. Причём, их может писать другой человек и выкладывать где
> угодно. Никакие USE флаги, портежи и прочее с ними не
> конкурируют. Просто разные задачи.
В идеальном сферическом вакууме, может, и не должны конкурировать. На
самом деле конкурируют осязаемым образом, о чем свидетельствует (1)
реализация схожей функциональности в разных программах то плагинами, то
опциями сборки (сравните Fvwm с остальными WM); (2) случаи миграции в
сторону плагинов (а иногда обратно) в процессе развития софта.
Между плагином и статической опцией сборки *бывает* более-менее
непрерывная шкала: кому-то хватает просто динамической загрузки, кто-то
публикует интерфейс для внешних разработчиков, кто-то реализует
выключение и замену плагинов в одном запуске, а кто-то нет.
[Понятное дело, что есть опции сборки, которые никому не нужны в
"динамическом" варианте. Но есть и остальные].
>> простой пример: сборку с -O1, в которой не включается -falign-jumps и
>> подобное) -- этот параметр получается не "стабильно
>> пессимизированный", а непредсказуемый: сегодня у вас
>> самый_главный_цикл попал на границы кэшлайна, а завтра вдруг из-за
>> совершенно нерелевантных причин не попадет.
> Какие причины? Включение какой-либо опции?
Если бы. Просто некий код случайно попадает в правильное или
неправильное место.
По обсуждаемому случаю в tcl-core@ окончательная ясность так и не
наступила, но мнения склоняются к тому, что тело цикла так легло на
8-way associative L1 I-cache, что инструкции активно друг друга
вытесняли. -falign-jumps=32 и подобное -- позволяет до некоторой степени
понизить вероятность сильных отклонений, но не исключает их полностью
[и, кстати, не *увеличивает* в данном случае производительность, а
именно стабилизирует -- но не до конца, увы].
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
Reply to: