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