> 1. Возможно ли уже полностью собрать без глюков систему с graphite?

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

>Кроме багов в собираемых прогах, разумеется.

Есть что-то конкретное, что с графитом начало глючить?

У меня не собираются с графитом три или четыре пакета. Не факт, что тебе они при сборке попадутся.
Багов вроде бы не замечал (возможно просто не натыкался в лоб), по крайней мере такой феерии, как с icc не было и нет.

А описанные там страсти уже позади?
http://www.linux.org.ru/jump-message.jsp?msgid=3942424&cid=3944763

короче так
с -floop-interchange -floop-block -floop-strip-mine -ftree-loop-distribution
не собераются точно - питон 2.6 xine-lib и p7zip

-ftree-parallelize-loops=n ломает zlib, glib и ещё кучу софта (они работают с вероятностью 50 на 50 ) впрочем тока для н процов

-fprofile-generate -fprofile-correction ломаю zlib - смерть сразу же - даже емердж не запустится

а так с первыми опциями всё хорошо - даже если собрать ядро :)
З.Ы. это на ~x86

и да - если всю систему собрать с 4.4.2/4.4.3 и графитом то лиса точно не падает - проверено несколько раз на 2 установленных с нуля гентах на моём компе :)

кстати -ffast-math у меня не подружился с графитом

>Что глючит - xz-utils (распаковка xz)

исправлено в GCC 4.4.2 , моими стараниями и с ICC тоже ;)

mozilla firefox (segv on start)

http://www.linux.org.ru/forum/talks/4544708?lastmod=1265975446112#comment-454...

wine (ошибки памяти в приложениях)

не проверяла

linux kernel

да, все хорошо, вероятно исправили к 4.4.2

ACE framework (ICE в GCC при сборке)

бага открыта, никому дела нет, хотя на 64 битах все работает
с GCC 4.5 бага не проявляется, вероятно решили в 4.4.x так и оставить...

вообщем если хотите собирать, то собирайте действительно всё,
оставленая библиотека собраная более старым GCC может выдать несовместимость ABI ( http://gcc.gnu.org/gcc-4.4/changes.html см CAVEATS ) и в результате что-то будет падать или работать нестабильно

>-fprofile-generate
а где же -fprofile-use ? )

возможно и был - не могу я всё помнить :)

У меня вся система собрана с графитом. И никаких проблем нет)

у меня тоже :)
только не вижу битности
тестовая или стабильная ветка?
какие опции использовались?

ну если уж используете -fprofile , то тут помнить нужно )

это же PGO, и PGO выполняется в определенной последовательности

сначала собирается медленная версия генератор профилирующей информации

потом вы ее немного используете, информация для профилирования пишется на диск

потом вы с собранной информацией собираете уже быструю версию, -fprofile-use

Так с какими флагами безопаснее собирать для 32-битной системы?

Хех, уже все поломалось :)

Не собираются пакеты, юзающие gtk-doc с однотипной проблемой:
[code]
gtk-doc: Fixing cross-references
Use of uninitialized value $MODULE in concatenation (.) or string at /usr/bin/gtkdoc-fixxref line 171.
Use of uninitialized value $MODULE in concatenation (.) or string at /usr/bin/gtkdoc-fixxref line 171.
Can't open -sections.txt: Нет такого файла или каталога at /usr/bin/gtkdoc-fixxref line 171.
make[2]: *** [html-build.stamp] Ошибка 2
make[1]: *** [all-recursive] Ошибка 1
make: *** [all] Ошибка 2
* ERROR: dev-libs/atk-1.28.0 failed:
* compile failure
*[/code]

Фф само-собой сегфолтится.

так написано ж - ВСЁ собирать надо! а не только тут и тут

ну вот и решайте, нужно оно или нет ;)

ps: генту я пробовала ставить 3 раза

один раз просто так, дошла по хендбуку до «А теперь давайте соберем ядро» и мне надоело, да и дебиан менять не очень хотелось пока

второй раз собрала ~x86 , с GCC 4.4.x , не запускались даже иксы, падали тут же

третий раз собственно то, что сейчас, с eglibc и своим зоопарком gcc,
cегодня вот почти без приключений поставила eglibc 2.11.1 (-exp5)

Да не, это всплыл баг с gtk-doc, из-за которого не пересобрать остальное, просто совпадение :)

насчет вайн, собрала сейчас 1.1.38

при запуске WoW черный экран и все, раньше валилось с ошибкой памяти

хотя быть может те самые CAVEATS с packed форматом проявляются, у меня с 4.3.x пока многое собрано

archive Data\enGB\locale-enGB.MPQ opened
archive Data\enGB\speech-enGB.MPQ opened
archive Data\enGB\expansion-locale-enGB.MPQ opened
archive Data\enGB\lichking-locale-enGB.MPQ opened
archive Data\enGB\expansion-speech-enGB.MPQ opened
archive Data\enGB\lichking-speech-enGB.MPQ opened
wine: Unhandled page fault on read access to 0xffffffff at address 0x7b9dc8f6 (thread 0009), starting debugger...

Так а что раньше в нем работало, не поломалось?

У меня пока пересобрался system, щас собирается указанный тобой набор для firefox.
Пришлось ненадолшлпрерваться из-за этого бага: http://bugs.gentoo.org/show_bug.cgi?id=305191

я не так часто собираю и тем более пересобираю что-то как может показаться, 4.4.4 (redhat, svn) у меня по умолчанию стоит около 2 недель пока (до этого был 4.3.4), вроде то, что с ним собрано (без графита кстати) работает нормально

Кстати, победить сегфолт фаерфокса пересборкой только тех пакетоав не получилось.
На сколько я понял, такая проблема есть только на x86-32 с флагами -ftree-vectorize и -mfpmath=sse. Помогло пересобрать sqlite c -mstackrealign, но говорят сам gcc с таким флагом не собирался...

-mfpmath вообщем-то непричем
-ftree-vectorize достаточно агрессивная опция, может падать из-за нее, к тому же она включена в -O3 (можно отключить -fno-tree-vectorize) , с -mstackrealign не экспериментировала, ничего не скажу

и насчет ФФ, хоть он и запускается и работает, все равно у меня он падал на отдельных страницах, так что по рекомендациям лучших собаково^W Mozillы собираю дальше GCC 4.1.2

Никто не сказал про самое интересное: есть ли ощутимый профит от сабжа?

есть - но не мильон % - не панацея от тормозов

>-mfpmath вообщем-то непричем

Вроде как причем, там дело касается выравнивая границы стека при sse-интструкуиях.

> есть - но не мильон % - не панацея от тормозов

А конкретные цифры на какой-нибудь проге есть? А то эта фраза под любую ситуацию подходит и инфы в себе почти не несёт...

если устроит вот такой тест:

/var/tmp :$pipebench < linux-2.6.32.8.tar | ./gzip_graphite -9 > /dev/null
Summary:
Piped 364.71 MB in 00h00m46.77s: 7.79 MB/second

/var/tmp :$pipebench < linux-2.6.32.8.tar | ./gzip_nographite -9 > /dev/null
Summary:
Piped 364.71 MB in 00h00m46.41s: 7.85 MB/second

то видно что прирост небольшой, а может даже и в пределах статистической погрешности

перепутала местами... нет прироста, регрессия даже )

> pipebench < linux-2.6.32.8.tar | ./gzip_graphite -9 > /dev/null

Думаю, лучше так пускать: time gzip -9 < linux-2.6.32.8.tar > /dev/null. Но разница действительно несерьёзная. Надо попробовать что-нибудь более склонное ко всяческим распараллеливаниям...

Спасибо, в общем-то я так и думал что всё будет от случая к случаю зависеть.

Кстати, а нету ли случаем такого же сравнения, но для xz?

есть в графите и это - но сцуко ломает кучу всего :(

чёт я не понял - цифр точно не помню,но порядка 10% tar+gzip собраные с графитом выигрывали на распаковке стэйджа

> >Что глючит - xz-utils (распаковка xz)

исправлено в GCC 4.4.2 , моими стараниями и с ICC тоже ;)

Молодец. А что за старания-то?

http://sourceforge.net/projects/lzmautils/forums/forum/708858/topic/3306733


хм, там Игорь Павлов теперь пытается выяснить на форуме в чем баг в LZMA
;)


в p7zip кстати c ICC 11 на декомпрессии до сих пор выдает ошибки

p7zip 9.04 (lzma sdk):

Intel C/C++ compiler 10.1 (с 11.1 не работает) -O3 -ipo -xS

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 3188 155 2003 3102 | 42405 197 1946 3828
23: 3068 156 1998 3126 | 42178 197 1957 3861
24: 3076 161 2051 3307 | 41518 198 1949 3852
25: 3013 163 2105 3440 | 40951 197 1950 3851
----------------------------------------------------------------
Avr: 159 2039 3244 197 1951 3848
Tot: 178 1995 3546

GCC 4.4.4 -O3:
Graphite:

Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 2925 155 1831 2846 | 36670 297 1115 3311
23: 2891 159 1856 2946 | 36431 298 1118 3335
24: 2877 163 1895 3093 | 35976 199 1677 3338
25: 2876 167 1970 3284 | 35511 199 1679 3340
----------------------------------------------------------------
Avr: 161 1888 3042 248 1397 3331
Tot: 205 1643 3187

без графита:
Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS

22: 2993 157 1856 2912 | 36822 199 1671 3324
23: 2935 160 1865 2990 | 36348 198 1679 3328
24: 2900 164 1903 3119 | 36072 199 1681 3347
25: 2873 166 1971 3280 | 35555 199 1684 3344
----------------------------------------------------------------
Avr: 162 1899 3075 199 1679 3336
Tot: 180 1789 3205

опять графит чуть-чуть позади, p7zip в отличие от xz использует многопоточное сжатие, во всяком случае как минимум 2 ядра он утилизует

xz

без графита, декомпрессия
$time ./xz-cc44 -dc < linux-2.6.32.8.tar.xz >/dev/null
real 0m7.257s
user 0m7.132s
sys 0m0.052s

графит, декомпрессия
~/tmp :$time ./xz-graphite -dc < linux-2.6.32.8.tar.xz >/dev/null
real 0m7.290s
user 0m7.170s
sys 0m0.045s

тест компрессии:
тестовые данные (обьем не для серьезного теста, а скорее для приближенной оценки)
$dd if=/dev/urandom of=randomdata bs=1M count=256
268435456 bytes (268 MB) copied, 53.7057 s, 5.0 MB/s

без графита:
$time ./xz-cc44 -9v < randomdata >/dev/null
100.0 % 256.0 MiB / 256.0 MiB = 1.000 1.2 MiB/s 3:28
real 3m28.976s
user 3m26.298s
sys 0m0.749s

с ним:
$time ./xz-graphite -9v < randomdata >/dev/null
100.0 % 256.0 MiB / 256.0 MiB = 1.000 1.2 MiB/s 3:31

real 3m31.148s
user 3m28.440s
sys 0m0.771s


вывод - везде графит чуть отстает


все тесты сделаны на core2 duo penryn @ 2Ghz, ядро 2.6.32.8 preempt + BFS патч

так а с какими флагами собираешь?
просто у меня другие результаты были

-msse2 -march=pentium4 -mtune=core2 -mfpmath=sse,387 -g0 -ftree-loop-linear -floop-interchange -floop-block -floop-strip-mine -ftree-loop-distribution -O2 -fomit-frame-pointer

у мну
"-O2 -march=core2 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=3072 -floop-interchange -floop-block -floop-strip-mine -ftree-loop-distribution -g0 -Wno-all"

а ядро? может дело в bfs ?

кути откомпиляцо - попробую на таре и бзипе - есть гигантский архив в ~17 гигов

-msse -msse2 -msse3 -mssse3 -msse4.1

-msse4.1 достаточно )

2.6.32-gentoo-r3 с BFS 1000Hz low-latency

>-msse4.1 достаточно )
это на память ;)

кстати, насколько я помню у вас 64 бита, графит с 64 ведет себя получше чем с x86, у меня 32 битная система

не - у меня ~x86

странно,но цифры в пределах погрешности - 11 секунд при распаковке 17+ гигового архива
с графитом
real   35m44.157s
user   33m42.395s
sys   0m57.936s
без
real   35m33.724s
user   33m36.542s
sys   0m58.081s

gz bz2 xz - всё одно и тоже

беда :( было гораздо лучше

причем цифры еще и в минус для графита )