GCC 4.6.0

да! GCC 4.4.5 с теми же опциями, без выравнивания и с оптимизациями выдал на 15 секунд быстрее.

//regressions make me cry T.T

Может, в 4.5 стоит включить -fexcess-precision=fast ?

один фиг

Support for hot-patchable function prologues via the ms_hook_prologue attribute for x86_64 in addition to 32-bit x86.

Поддержка, необходимая для Steam между прочим.

Это что-то про трояны, да?

Да, да. Следи за звездочками, не отвлекайся.

Тогда, я пас. //Жду-недождусь того дня, когда clang будет готов для сборки всей системы

> когда clang будет готов для сборки всей системы

я боюсь, что и из него сделают в итоге тормозную бяку.

>я боюсь, что и из него сделают в итоге тормозную бяку

каким образом? он же полностью модульный

>Жду-недождусь того дня, когда clang будет готов для сборки всей системы

А что сделал для этого ЛИЧНО ТЫ?

> А что сделал для этого ЛИЧНО ТЫ?
Я? Ждал, жду и буду ждать. А что? Что я должен был сделать? Написать патчей? Тогда он действительно станет «тормозной бякой».
Я вообще собираюсь Qt4 учить и писать лёгкий DE на нём.

>Что я должен был сделать?

Тестить сборку системы и репортить баги

Тогда он действительно станет «тормозной бякой».

Говнопатч не примут, это же не столмановская богадельня

Найдут способ.

//я до сих пор считаю идеалом код одной корейской игрушки, где была 1 строчка коммента на 5 строк кода + flow-chart'ы и четкие указания в какие файлы и что нужно дописывать, если хочешь расширить функциональность.

В rh gcc с патчами, от ванильного gcc он сильно отличается.

ты когда запилишь libpng с SIMD? :3

> Тестить сборку системы и репортить баги
Я думаю, репортов о том, что ядро не собирается, там и так полно.

.36 собиралось же вроде?

Хм. А говорили, что кроме как gcc ядро ничем больше не собирается. Надо бы проверить.

сменила ванильный 4.5.3pre на 4.5.2 из редхат ветки
бенчмарк между ними
256 Mb bzip2 -9:

vanilla: 1m24.217s
redhat: 1m24.288s
т.е. по сути без разнцицы

далее для -O2 -fomit-frame-pointer -march=core2

1Gb gzip -9 (без asm):

GCC 4.3 0m46.117s
GCC 4.4 0m46.866s
GCC 4.5 0m48.066s
GCC 4.6 0m43.673s


256 Mb xz:

GCC 4.3 2m10.624s
GCC 4.4 2m9.781s
GCC 4.5 2m12.250s
GCC 4.6 2m4.807s

4.6 себя показывает достаточно неплохо, в сравнении, т.е. оптимизацию для корки2 улучшили.

с bzip2 конечно вышло совсем не радужно... по-хорошему надо брать gprof хотя бы и отлавливать тот кусок кода , который выдает такую безобразную регрессию....

не во всех версиях, или в SVN не все патчи идут,
в целом - он вкуснее в плане стабильности или бэкпорта некоторых возможностей
например поддержка core2 в 4.1 ветке (ваниль - 4.3)
или atom в 4.4 (4.5)

>по-хорошему надо брать gprof

и профилировать ВООБЩЕ ВСЕ

зачем все? в gzip и xz например все в порядке

>например все в порядке

и весь код идеален?

Вы идиот? Причём тут код пользовательского приложения? Тут GCC обсуждают.

фу таким быть
вы - хам!

Странно от тебя это слышать =)

я ранее был хамом?
ппц...я себя ненавижу :3

Особенно, когда выпьешь)
Я (KevinDetry) всё помню =)

Оооо - с возвращением - я скучал
кстати да - как ни странно - я опять выпимшЫ )

пфф.. обьясняю,
сейчас с тестами bzip2 я продемонстрировала регрессию в производительности, около 30%, регрессия проявилась начиная с 4.4 ветки и существует в 4.4 4.5 и 4.5

время компрессии возросло с 50 секунд , на 15 секунд и более

в тестах с gzip и xz - этого нет. следовательно что-то не так с bzip2

надо брать bzip2 , компилить с -pg и смотреть в каких функциях отмечается наибольшее возрастание времени потребления процессора, потом смотреть код этих функций, оптимальный вариант - найти кусок кода , который плохо оптимизируется начиная с 4.4, и сделать из него testcase ( например простенький цикл ) зациклив который можно убедиться в том, что GCC 4.3 его компилит нормально, а вот GCC 4.4 компилит его уже так что он тормозит...
C этим в принципе есть хорошие шансы того, что багу исправят быстро и не оставят без внимания.
Я не вижу смысла устраивать аудит всего абсолютно кода везде, титанический труд, есть конкретная проблема с bzip2, есть инструменты для профилирования (не путать с PGO)

А я и не возвращался ^_^
Посмотри на ник, это времянка.
Вернусь, когда свою idea на Qt4 напишу)
Вот зря ты так, не убивай своё здоровье, кто будет optimization.hardlinux.ru развивать, если не ты?

>Тут GCC обсуждают.

Причем тут анонимусы, они вообще на /b/ сидят только.

потести на -march=i686

Да ёлки палки. Вот только ЛибреОфис собрал. Ждем 4.6.1 >_<

да - на поддержку надо время
ща назрело несколько страниц, но сцуко тааак лень (

128 Mb bzip2 -9
-O2 -march=i686

4.3 0m26.177s
4.4 0m28.868s

(для сравнения с тем что выше время x2) те 52 и 56 с, кстати не так сильно возрастает время компрессии в сравнении с 4.3 vs 4.4 @ Core2

4.3 -march=core2 конечно быстрее будет, а вот для 4.4+ - i686

PS: опять для гентушников проблему заложили... бинарщики то не собирают с -march=core2

в slitaz вообще наркоманы и собирают для i486 )))

ну 4.3 рип
оно не в счёт

в счет
1) он еще поддерживается, хотя и не особенно активно.
см gcc.gnu.org

2) регрессия с bzip2 вылезла при переходе от 4.3 к 4.4

ну де факто 4.3 - рип
посему - оно не имеет значения
а вот на 4.4 и далее на том же бзипе 686 наилучший выбор

посмотри табличку сравнения, я уж лучше клангом соберу )
и кстати с точки зрения багрепорта - сравнить надо как раз с 4.3, каким бы старым он ни был...


PS: займитесь пожалуйста кому не лень и есть время...

>ты когда запилишь libpng с SIMD? :3

во-первых, я пока нашел для себя более интересный проект :3

во-вторых, надо бы подтвердить или опровергнуть мою гипотезу о важности оптимизации zlib в скорости загрузки

>ну де факто 4.3 - рип

а 4.2 еще живет :)

я потыкал примитивы от штеуда
первое - они не соответствуют реальности
второе - мне тупо лень разгребать их костыли
третье - ты уверен что тормоза в сжатии?

это про правилах форума аль о некрофилах?

Странно вас читать тут. Вы неправильно меряете же ) -march — это грубо говоря тот набор инструкций, которые будут доступны gcc при генерации результата. А -mtune это и есть та целевая платформа, под которую идёт оптимизация. Если вы не указываете -mtune, то вы оптимизируете под абстрактуную платформу и используете -mtune=generic. Сделайте тесты с -O3 -march=native -mtune=native -flto для gcc-4.5+, а то как-то неинтересно совсем ваши сравнения читать )

>Если вы не указываете -mtune, то вы оптимизируете под абстрактуную платформу и используете -mtune=generic.

если не указано тогда =march, -mtune=generic нужно указывать явно.

Сделайте тесты с -O3 -march=native -mtune=native -flto для gcc-4.5+

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

Ага, нашёл в мане «specifying -march=cpu-type implies -mtune=cpu-type», извиняюсь, что недосмотрел.

еще нюансы -
-march и -mtune могут быть заданы и по умолчанию во время сборки gcc, достаточно часто используется generic, но чтобы он работал в таком случае, нужно не задавать march

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

-flto с GCC 4.5 использовать лучше не стоит, оно не стабильно, с 4.6 - must try it, его переработали, хотя с сборкой библиотек я бы была осторожнее,

-O3 , я уже написала про стабильность, набор экспериментальных оптимизаций который ничего не гарантирует, кроме того с снапшотами 2 месячной давности GCC 4.6 оптимизация выше -O2 работала очень нестабильно.

по поводу -march=native - вы плохо смотрели тесты и сообщения им предшествующие, хитрость в том, что кое в чем generic может обходить вариант native, равно как например --param l1-cache-size и --param l2-cache-size лучше задавать меньше реального размера, во всяком случае для CFLAGS, большие кеши современных корок с попыткой полной утилизации с -march=native и код раздувают и могут даже приводить к тому что он будет медленнее работать ( нужно тестировать с приложениями )

в остальном не стану повторяться.