[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Перекомпиляция основных программ



> Stanislav Vlasov <stanislav.v.v@gmail.com> writes:
> > >  Но вообще есть ощущение, что Gentoo - оно в основном таки да, для задротов.
> > >  Любителей гордо похвастаться "а у меня сборка вся из себя ускоренная и вон как
> > >  летает".  Еще ни одного достаточно уверенного подтверждения того, что она таки
> > >  да, летает (по сравнению с, допустим, дебиановской), я не видел.
> >  Могу добавить, что было сравнение дебиана и генту с оптимизациями.
> >  Таки не в пользу генту по тестам. Правда, это было довольно давно, во
> >  времена Etch, если не ошибаюсь.
> Настоящие хардкорные гентушники говорят прежде всего о гибкости, которую
> дает перекомпиляция (use-флаги, позволяющие для многих пакетов
> включить/выключить использование каких-либо библиотек).
Вряд ли это сильно влияет на скорость. Скорее, на объём занятого дискового пространства.
Разве сейчас это кого-то сильно волнует на десктопе?

> Кстати, я с нетерпением жду, когда кто-нибудь популяризует среди
> озабоченных -fprofile-arcs/-fbranch-probabilities, что придаст процессу
> перекомпиляции совершенно особую прелесть: «опций gcc накрутить любой
> дурак сможет, а настоящий мужик должен собрать первый раз, позапускать
> как следует и собрать во второй раз с использованием собранной
> статистики».
:-D Жестоко. Профилированием пусть разработчики занимаются.

> Об ошибках измерения: не так давно в tcl-core@sf.net появился повод
> вспомнить, что рантаймовые ошибки могут оказаться полной фигнёй по
> сравнению с «артефактами выравнивания» конкретных сборок: то есть,
> делаешь изменение (кода или опций компилятора -- неважно), компилируешь,
> на запусках имеешь стабильное ускорение на 10% -- и внезапно
> оказывается, что к *смыслу* изменений оно никакого отношения не имеет, а
> просто какой-то кусок кода или данных расположился удачнее. Такой тип
> ошибок почему-то редко кто подозревает; обычно присматриваются к
> методике тестирования в части порядка запуска, или там набора исходных
> данных -- при том, что основная составляющая ошибки может быть к моменту
> запуска уже внесена.
Но, тем не менее, что-то же  этому способствовало?


Reply to: