> Н. Артём <artio...@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 и подобное -- позволяет до некоторой степени > понизить вероятность сильных отклонений, но не исключает их полностью > [и, кстати, не *увеличивает* в данном случае производительность, а > именно стабилизирует -- но не до конца, увы]. Хм... Но ведь без изменения чего-бы то ни было, компилятор должен каждый раз создавать одинаковый код..? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/73281287376...@web53.yandex.ru