[gcc][graphite] Плюсы и минусы?

хочется попробовать - пробуйте )
из минусов - отдельные приложения становятся нестабильны.
из плюсов - отдельные приложения работают быстрее.

В общем все как всегда. Имеет ли смысл вообще реализовывать какие-то отпимизации , разворачивания циклов , если это дает не более 5% прироста производительности?

Ну вот сейчас дособерется - попробую :)

Кстати, я правильно понимаю что использование или неиспользование этих оптимизаций при компиляции приложений можно выбирать флагами на лету?

CFLAGS ? или что-то наподобие #pragma в исходниках ?
если второе - не знаю.

5% тут,
5 там...
еще 5 здесь... )

опять начинаешь? )))
всё стабильно, но как мы уже по-ходу додумались - надо всё и вся собирать одной веткой - и делов-то :)

> опять начинаешь? )))
вопрос не закрыт )

надо всё и вся собирать одной веткой - и делов-то

тоже еще не факт.

>если это дает не более 5% прироста производительности?

Это с одной старушки - пятачок. А с двадцати старушек - уже рубль.

>Кстати, я правильно понимаю что использование или неиспользование этих оптимизаций при компиляции приложений можно выбирать флагами на лету?

В Gentoo можно сделать использование персональных флагов сборки (и, вообще, выбирать разные компиляторы) для конкретных пакетов.

не только в Gentoo, это везде можно ) Gentoo как среда с автоматизацией сборки даже менее удобна в этом плане , чем среда с ручной сборкой, хотя конечно в современных дистрибутивах все собирать вручную с отслеживанием зависимостей напрягает, поэтому и автоматизированый вариант вполне сойдет.

>надо всё и вся собирать одной веткой

Да, только с каждой новой веткой сколько-то процентов старого софта вообще не соберутся :)

кстати, вот ты говорила,что графит шалит только на 32
т.е. вся 64 система собрана 4.3.4 например и софт собранный с, например, 4.4.2 и графитом в отличии от 32 НЕ падает?

>говорила,что графит шалит только на 32
только относительно mozilla , я не могу утверждать что все это применимо ко всему, тем более если учесть что Graphite достаточно сильно перелопатили в 4.5 , все это пока несколько экспериментально (да , гентушники своего рода белые мышки в тестировании всего нового и всего разнообразия опций сборки)

в генте это решают gcc-4.4-fix.diff 'ами )

кстати задам вот такой вопрос, может кто подскажет почему так?

есть вот такой процессор (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 часов

3) -march=i686 -mtune=pentium4
аналогично первому случаю

4) -march=pentium-m
виснет в течении первого часа, иногда сразу паника при загрузке, kernel oops() Illegal opcode вылетают уже где угодно, в том числе и в драйверах файловой системы

5) -march=pentium4
может хоть неделю работать, oops-ов нет

gcc 4.2, 4.3, 4.4, конфигурация ядра идентична (!), т.е. значение имеет только -march=

а как его видит гсс?

 gcc -m32 -fverbose-asm -march=native -Q --help=target | grep march 

pentium-m

может дело в опция которые включает гсс при пне4 и пне-м?

sylvia@allure:~$ cc43 -fverbose-asm -march=pentium4 -Q --help=target > pen4
sylvia@allure:~$ cc43 -fverbose-asm -march=pentium-m -Q --help=target > penm
sylvia@allure:~$ diff penm pen4
16c16
< -march= pentium-m
---

-march= pentium4

отличие только в -march (и -mtune)

-march=pentium3 кстати дает аналогичный результат с -march=pentium-m ,
ядро вылетает в панику также быстро

-m32 по умолчанию, это 32 битный процессор на 32 битной системе, без возможности 64 битного режима , gcc умеет только 32 бита

кроме того от версии это не зависит, ядра собраные разными версиями (4.2 , 4.3 и 4.4) ведут себя абсолютно одинаково

добавлю и то что дистрибутивные версии gcc Slackware, Gentoo Portage, Ubuntu ведут себя аналогично, и pentium-m ядра вешаются с одинаковой закономерностью, в то время как pentium4 работают стабильно, процессор - Celeron M, архитектуры pentium-m, в то время как pentium4 - netburst.
Особенно интересно что и -march=i686 тоже работает нестабильно, вот вам и GCC, с его особой уличной магией, так что что там с графитом и мозиллой это еще вариант несколько более простой... (вообще не полениться бы кому и собрать его с отладкой ? мне вот все не хочется возиться, тем более напишешь багрепорт, так и будет висеть по полгода и больше, никто даже не посмотрит...)

а -march=pentium-m и натив отличаются?
и как оно себя ведёт если как натив собрать?

с -march=native собирала, также паникует в течении получаса,
хотя обычно я указываю тип процессора явно, т.к. предпочитаю сборку на быстрой машине, не ждать же час, когда за 12 минут можно все собрать)

тут на линухфоруме ( вроде ) у человека на ноуте с дровами на видео были проблемы с новыми ядрами (32 вообще не грузилось)
кто-то что-то поломал )))

ядра 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 по умолчанию).

мне повезло больше - из мэйка ядра

-O2 -march=core2 -mtune=core2 -pipe -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 --param l1-cache-size=64 --param l2-cache-size=3072 -floop-interchange -floop-block -floop-strip-mine -ftree-loop-distribution -fomit-frame-pointer -findirect-inlining -g0 -Wno-all 

но работает ^_^

CC=icc CFLAGS="-O2 -xT -i-static" emerge gzip
скажем )

хотя может у KRoN73 есть и другой вариант покрасивее

ну некоторые и ICC собирают, и тоже работает

я к тому что если у вас работает с экстремальными флагами, то это не значит что это будет работать везде и у всех, бывает и такое что и -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 фермы.

>в генте это решают gcc-4.4-fix.diff 'ами )

а патчи-то тоже откуда-то накладывать надо. Значит, старый ebuild нужно менять, значит, нельзя гарантировать, что устаревшая-необновлявшаяся версия будет воспроизводимо собираться. Вывод: автоматизация в стиле генты сделана таким образом, чтобы ломать и пересобирать заново, а не «стабильно и надёжно».

>тем более напишешь багрепорт, так и будет висеть по полгода и больше, никто даже не посмотрит...

а через полгода выйдет gcc 4.5, и всё опять по новой...

Кстати, а через llvm-gcc не пробовала собирать? Им стабильнее? Хотя конечно оно уже устарело немного, gcc 4.2

>CC=icc CFLAGS="-O2 -xT -i-static" emerge gzip

ненене. А то давай еще DESTDIR руками укажем, тогда сам ч0ртЪ не разберется, с какими флагами, что и куда собирали. Ну не грепать же логи сборки на предмет переменных, в самом деле. Сделаем потом emerge -v конкретная версия, и все красоты, заданные через переменные затрутся и потеряются. Оно должно идти в новый, обновлённый профиль, по идее.

>генты сделана таким образом, чтобы ломать и пересобирать заново
ну так и имидж у дистрибутива в целом соответствующий )

через llvm-gcc не пробовала собирать

нет

/var/db/pkg/app-arch/bzip2-1.0.5-r1 :$cat CC CFLAGS CXX CXXFLAGS
fgcc
-O2 -fomit-frame-pointer -g0 -mfpmath=sse,387 -msse2 -march=pentium4 -pipe
fg++
-O2 -fomit-frame-pointer -g0 -mfpmath=sse,387 -msse2 -march=pentium4

ай? в /var/db/pkg все сохраняется, чем и с какими флагами...

ещё такой есть компилятор: http://nwcc.sourceforge.net/index.html

оно совместимо с gcc расширениями, но только plain c.

в виде логов — да. Но если мы потом сделаем reinstall того пакета, то не факт что все настройки сохранятся (/me не уверен, побежал проверять). По крайней мере, версия gcc, которая Last known good не сохраняется

>и как указать, к примеру, portage, что emerge должен собирать один пакет gcc-4.3.3, а другой — gcc 4.4.3?

Да. У меня, правда, сделан упрощённый вариант, подходит для пакетов, которые можно собрать другой версией компилятора без смены по gcc-config. Т.е. просто вызывается, например:

# /etc/portage/package.comppilers
app-arch/gzip gcc-4.1.2 g++-4.1.2

Как указать, к примеру, что пакеты для crossdev-emerge надо брать из конкретного оверлея, а не из основного дерева?

Понятия не имею, я сrossdev вручную не ковырялся. Но в Gentoo перед сборкой любого пакета можно вызывать свой bash-скрипт, который и подготовит всё, что нужно, при желании.

>хотя может у KRoN73 есть и другой вариант покрасивее

Мой /etc/portage/bashrc:
http://dpaste.com/150719/

По умолчанию - обычно поведение.

Если пакет указан в /etc/portage/package.icc, то пакет соберётся через icc.

Ещё есть /etc/portage/package.icc-cflags и /etc/portage/package.gcc-cflags для указания персональных опций компиляции.

># /etc/portage/package.comppilers

app-arch/gzip gcc-4.1.2 g++-4.1.2

и при пересборке мира, например, gzip будет автоматом собран gcc-4.1.2?

>/etc/portage/package.gcc-cflags с флагами для пакета
и

/etc/portage/env/категория/имя_пакета с флагами для пакета

это одно и тоже?

>и при пересборке мира, например, gzip будет автоматом собран gcc-4.1.2?

Да.

>это одно и тоже?

Не знаю. Я с новым функционалом портежа не ковырялся, он не документирован нормально :) А я ковырялся с этим давно.

спасибо, интересное решение

ясно :)

а вот такого нет?

1)есть /etc/make.conf в нём строка CFLAGS=
2) есть /var/db/pkg/категория/имя_пакета/CFLAGS 
в котором перечислены флаги с которыми собран пакет
надо - сваять скрипт который покажет все пакеты в виде категория/имя_пакета
которые собраны с флагами отличными от флагов в make.conf и одной строкой через пробел - чтоб подсунуть emerge-у

или есть ли какое-то стандартное (скажем так) решение?

надо лишь не полениться прочитать мануал
http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage

CCCFLAGS="-O2 -xT -gcc"
ICCCXXFLAGS=«${ICCCFLAGS}»

Заменить -xT на -xS если процессор поддерживает sse4.1

Эммм... Регрессия или баг?