Re: Перекомпиляция основных программ
> Н. Артём <Artiom14@yandex.ru> writes:
> > > волнует. А вот избежать линковки с чем-нибудь падучим, или некрасивым,
> > > или просто не вписывающимся в систему -- бывает желательно, точно так же
> > > как выбрать из альтернативных реализаций какой-нибудь фичи менее
> > > популярную.
> > Хм... В сравнении со "стабильным Debian" это не является плюсом. Они и
> > так пытаюся избежать использования чего-нибудь падучего.
> Пример с emacs был приведен (в том числе) и в пользу того, что падучесть
> и глючность тоже бывают субъективными. Кому-то может быть очень важно,
> что emacs/GTK умеет рисовать меню на иврите справа налево [он, должно быть,
> умеет], а бага с падающими дисплеями ему не впёрлась, потому что
> у него когда падают иксы -- и так падает всё полезное. А вот кому-то
> очень важно наоборот.
Хм... emacs-nox? Да и emacs без GTK, кажется, есть..? Не знаю я как и что там дальше. Но сейчас-то он есть?
> > Отсюда вывод: выбрать другой дистр проще (ну, если имеется возможность
> > выбора).
> "Нужен другой провайдер? Убирайтесь в свою Жмеринку, там будет другой
> провайдер!". Подход по-своему логичный, но где-то варварский.
Так не я первый. У меня стоит^B^Bял рабочий Debian, который мне здесь не раз предложили сменить на Gentoo с очередным выкачиванием гигабайт, лёгким форматированием и настройкой заново.
> Возможность-то сменить дистр обычно имеется, а вот желание
> отсутсвует.
Я, хотя-бы, имел ввиду не смену, а выбор другого. Когда есть варианты, но ещё ни один не установлен.
> К тому же, если у вас требования к сборке чего бы то ни было
> отличаются от общепринятых, менять на что-либо debian -- чистое
> безумие. Не факт, что в debian соберут как вам надо, но на это хотя бы
> есть шанс -- и продуманы-протоптаны запасные варианты на случай, если не
> соберут (тот же vim я изрядно долго ставил "чупринской сборки из
> вагнеровского репозитария").
Отсюда снова вопрос про Gentoo... Ну и чем отличается Debian, в плане хвалёной гибкости?
> > Ну, конечно имеет. Но никто не мешает сделать тоже самое, например в
> > Debian? Если это единственная причина существования такого подхода -
> > он неоправдан. Ведь есть и другие причины..? (а тестов так и нет)
> А я наоборот утверждаю, что гибкость "содержательных" сборочных
> параметров -- единственное разумное оправдание source-based сред
> (gentoo, freebsd ports); и никаких тестов, что характерно, тут не
> нужно -- когда вам эта гибкость потребуется, вы будете *точно* знать,
> что она нужна.
А собрать свой пакет в Debian..? Поправив флаги и зависимости. Конечно, это сложнее, но задавать параметры сборки для каждой программы отдельно вы же не будете? Максимум для нескольких...
> > > простой пример: сборку с -O1, в которой не включается -falign-jumps и
> > > подобное) -- этот параметр получается не "стабильно
> > > пессимизированный", а непредсказуемый: сегодня у вас
> > > самый_главный_цикл попал на границы кэшлайна, а завтра вдруг из-за
> > > совершенно нерелевантных причин не попадет.
> > Какие причины? Включение какой-либо опции?
> Если бы. Просто некий код случайно попадает в правильное или
> неправильное место.
> По обсуждаемому случаю в tcl-core@ окончательная ясность так и не
> наступила, но мнения склоняются к тому, что тело цикла так легло на
> 8-way associative L1 I-cache, что инструкции активно друг друга
> вытесняли. -falign-jumps=32 и подобное -- позволяет до некоторой степени
> понизить вероятность сильных отклонений, но не исключает их полностью
> [и, кстати, не *увеличивает* в данном случае производительность, а
> именно стабилизирует -- но не до конца, увы].
Хм... Но ведь без изменения чего-бы то ни было, компилятор должен каждый раз создавать одинаковый код..?
Reply to: