Н. Артём <artio...@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
