В общем все как всегда. Имеет ли смысл вообще реализовывать какие-то отпимизации , разворачивания циклов , если это дает не более 5% прироста производительности?
не только в Gentoo, это везде можно ) Gentoo как среда с автоматизацией сборки даже менее удобна в этом плане , чем среда с ручной сборкой, хотя конечно в современных дистрибутивах все собирать вручную с отслеживанием зависимостей напрягает, поэтому и автоматизированый вариант вполне сойдет.
кстати, вот ты говорила,что графит шалит только на 32
т.е. вся 64 система собрана 4.3.4 например и софт собранный с, например, 4.4.2 и графитом в отличии от 32 НЕ падает?
>говорила,что графит шалит только на 32
только относительно mozilla , я не могу утверждать что все это применимо ко всему, тем более если учесть что Graphite достаточно сильно перелопатили в 4.5 , все это пока несколько экспериментально (да , гентушники своего рода белые мышки в тестировании всего нового и всего разнообразия опций сборки)
кстати задам вот такой вопрос, может кто подскажет почему так?
есть вот такой процессор (Celeron M 390):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.70GHz
stepping : 8
cpu MHz : 1700.192
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
bogomips : 3400.38
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:
по википедии процессор относится к семейству Pentium-M (-march=pentium-m) , тесты производительности характерны, для -march=pentium-m она максимальна.
собираю ядро (любое современное старше .29 , c более старыми такого вроде не было, хотя уже точно и не скажу), конфигурация .config во всех случаях идентична, может меняться только тип процессора Generic i686, Pentium2, Pentium3, Pentium-M, Pentium4, хотя на самом деле и он тут не решает, а решают только флаги gcc.
1) -march=i686 -mtune=generic (достаточно общий случай сборки)
ядро работает в пределах 2-20 часов, далее следует завис X11, возможно illegal opcode kernel oops() в подсистеме acpi (/sys/power)
2) -march=i686 -mtune=pentium-m
аптайм сокращается до 30 минут - 8 часов
4) -march=pentium-m
виснет в течении первого часа, иногда сразу паника при загрузке, kernel oops() Illegal opcode вылетают уже где угодно, в том числе и в драйверах файловой системы
5) -march=pentium4
может хоть неделю работать, oops-ов нет
gcc 4.2, 4.3, 4.4, конфигурация ядра идентична (!), т.е. значение имеет только -march=
добавлю и то что дистрибутивные версии gcc Slackware, Gentoo Portage, Ubuntu ведут себя аналогично, и pentium-m ядра вешаются с одинаковой закономерностью, в то время как pentium4 работают стабильно, процессор - Celeron M, архитектуры pentium-m, в то время как pentium4 - netburst.
Особенно интересно что и -march=i686 тоже работает нестабильно, вот вам и GCC, с его особой уличной магией, так что что там с графитом и мозиллой это еще вариант несколько более простой... (вообще не полениться бы кому и собрать его с отладкой ? мне вот все не хочется возиться, тем более напишешь багрепорт, так и будет висеть по полгода и больше, никто даже не посмотрит...)
с -march=native собирала, также паникует в течении получаса,
хотя обычно я указываю тип процессора явно, т.к. предпочитаю сборку на быстрой машине, не ждать же час, когда за 12 минут можно все собрать)
ядра 28 29 30 31 32 33rc
уж не знаю кто там чего и где поломал, но поведение ядра радикально зависит от ключика -march при сборке, причем -march=i686 тоже виснет (!)
> В Gentoo можно сделать использование персональных флагов сборки (и, вообще, выбирать разные компиляторы) для конкретных пакетов
и как указать, к примеру, portage, что emerge должен собирать один пакет gcc-4.3.3, а другой — gcc 4.4.3? C paludis вроде понятно, в bashrc пишем ветвистую лапшу и устанавливаем CFLAGS, PATH и т.п. как хотим. А в emerge это как будет?
Ещё, я тут пересобираю через crossdev MinGW-ом избранные пакетики. И сразу вопрос, вот emerge-wrapper есть, i686-pc-mingw32-emerge или emerge-i686-pc-mingw32, а враппера для ebuild.sh нету (хотя пишется по аналогии на коленке легко).
Но в общем случае вопрос тот же, по поводу профиля portage. Как указать, к примеру, что пакеты для crossdev-emerge надо брать из конкретного оверлея, а не из основного дерева? Как задать «собирать конкретной версией тулчейна», если их несколько и не хочется плодить i686-pc-mingw32-XXXv1/v2 ?? Как задать конкретные use-флаги для конкретного оверлея в emerge? (например, из оверлея ported-2FBSD собираем с elibc_FreeBSD вместо elibc_glibc?)
С paludis как-то проще всё, хотя и нет рабочего аналога crossdev «из коробки», но наколбасить скрипт по аналогии и задать всё, что нужно через bashrc можно просто (или вообще наклонировать /etc/paludis-1, /etc/paludis-2 и задавать paludis --environment paludis-1 по умолчанию).
я к тому что если у вас работает с экстремальными флагами, то это не значит что это будет работать везде и у всех, бывает и такое что и -march= со всеми остальными безопасными флагами в корне меняет стабильность кода на определенных железках, да, кора2 те же ядра что с pentium-m , что с pentium4 переносила отлично
> Gentoo как среда с автоматизацией сборки даже менее удобна в этом плане , чем среда с ручной сборкой,
ага. Посмотрел на crossdev-wrappers и сразу захотелось в Arch, к простым PKGBUILD'ам.
хотя конечно в современных дистрибутивах все собирать вручную с отслеживанием зависимостей напрягает, поэтому и автоматизированый вариант вполне сойдет.
тогда автоматизированный вариант должен быть автоматизирован экстремально: позволять задавать произвольные настройки «ручной сборки» в качестве профиля пакетного менеджера, так, чтобы при этом одним рецептом ebuild/pkgbuild без изменений можно было собрать под любую кросссистему. Пока обходимся «палками и верёвками», полуручная заданная среда с врапперами.
Имеющийся профиль в Генте недостаточно расширяем. Например, взяли gcc-config c одной активной версией, посмотрели gcc-config -E другая PATH, задали его и собрали — и emerge будет думать, что собирали другой версией. Хотя ЕМНИП, он вообще не отслеживает, какой версией gcc собирали, в итоге можем при пересборке напасть на какой-нибудь древний пакет вроде xbase, который собирался gcc 4.1, но уже не собирается gcc 4.4
В идеале, хотелось бы что-нибудь вроде continuous intergration (потому что сборка 9999 scm live ebuild-ов — это тоже ССЗБ, без гарантий, что соберётся вообще или что 9999 не устарел очень сильно, или что тулчейн сильно не поменялся и всё ещё собирает нашу scm версию).
Что-то вроде Nix в качестве пакетного менеджера (чтобы задавать зависимости на версии тулчейна, параметры среды сборки, которые сейчас проще собирать вручную) + Hydra в качестве continuous build фермы.
а патчи-то тоже откуда-то накладывать надо. Значит, старый ebuild нужно менять, значит, нельзя гарантировать, что устаревшая-необновлявшаяся версия будет воспроизводимо собираться.
Вывод: автоматизация в стиле генты сделана таким образом, чтобы ломать и пересобирать заново, а не «стабильно и надёжно».
ненене. А то давай еще DESTDIR руками укажем, тогда сам ч0ртЪ не разберется, с какими флагами, что и куда собирали. Ну не грепать же логи сборки на предмет переменных, в самом деле.
Сделаем потом emerge -v конкретная версия, и все красоты, заданные через переменные затрутся и потеряются.
Оно должно идти в новый, обновлённый профиль, по идее.
в виде логов — да. Но если мы потом сделаем reinstall того пакета, то не факт что все настройки сохранятся (/me не уверен, побежал проверять). По крайней мере, версия gcc, которая Last known good не сохраняется
>и как указать, к примеру, portage, что emerge должен собирать один пакет gcc-4.3.3, а другой — gcc 4.4.3?
Да. У меня, правда, сделан упрощённый вариант, подходит для пакетов, которые можно собрать другой версией компилятора без смены по gcc-config. Т.е. просто вызывается, например:
Как указать, к примеру, что пакеты для crossdev-emerge надо брать из конкретного оверлея, а не из основного дерева?
Понятия не имею, я сrossdev вручную не ковырялся. Но в Gentoo перед сборкой любого пакета можно вызывать свой bash-скрипт, который и подготовит всё, что нужно, при желании.
1)есть /etc/make.conf в нём строка CFLAGS=
2) есть /var/db/pkg/категория/имя_пакета/CFLAGS
в котором перечислены флаги с которыми собран пакет
надо - сваять скрипт который покажет все пакеты в виде категория/имя_пакета
которые собраны с флагами отличными от флагов в make.conf и одной строкой через пробел - чтоб подсунуть emerge-у
или есть ли какое-то стандартное (скажем так) решение?