LINUX.ORG.RU

[gentoo][gcc]graphite

 ,


0

0

1. Возможно ли уже полностью собрать без глюков систему с graphite?
2. На сколько существенный профит? Бывают ли обратные ситуации, с проседанием производительности?
3. Есть ли смысл использовать для однояденых архитектур?

★★★★★
Ответ на: комментарий от megabaks

правда если добавить -ftree-parallelize-loops=n для xz-utils, то с графитом немного шустрее - опять же в пределах погрешности :(

megabaks ★★★★
()
Ответ на: комментарий от Sylvia

аха - блин - зря я потёр циферки 2 месячной давности

megabaks ★★★★
()
Ответ на: комментарий от megabaks

есть ещё идеи на чём потестить? где много этих самых «loops» ? :)

megabaks ★★★★
()
Ответ на: комментарий от megabaks

-ftree-parallelize-loops=n

там слабая параллелизация, очень немногие циклы распаралелливаются эвристически компилятором, в ICC опция -parallel присутствует уже достаточно давно, эффект от нее очень слабый, в программе размера типа gzip, xz-utils распаралелливает обычно менее 10 циклов в программе,
эффект маленький, так что лучше использовать честное распаралелливание в

pigz, pbzip2 , в xz-utils использование нескольких ядер стоит в TODO, LZMA SDK его поддерживает

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

ну мало не мало - главное что собраную с этой фигнёй zlib у меня половина софта отказалось понимать )))

megabaks ★★★★
()
Ответ на: комментарий от megabaks

>странно,но цифры в пределах погрешности - 11 секунд при распаковке 17+ гигового архива

А не упирается ли в скорость дисковой подсистемы?
Хотя получается где-то 8мб/с, вряд-ли у тебя такой медленный винт... Или ты не в /dev/null распаковываешь?

madcore ★★★★★
() автор топика
Ответ на: комментарий от madcore

ну естессно в нуль :) а винт на разделе с архивом ~50+Mb/s

megabaks ★★★★
()
Ответ на: xz от Sylvia

Спасибо за тесты! Видимо, программы под графит еще затачивать надо.

aix27249
()
Ответ на: комментарий от megabaks

нет, в принципе ничего нового в LTO нет,
в ICC давно уже есть IPO, и есть другой способ провести оптимизацию всей программы, он давно использовался в KDE до версии 4 ( gentoo useflag: kdeenablefinal ), суть в том что из многочисленных файлов исходников делается 1 (в случае KDE something_all.cpp куда вставляются #include <source1.cpp>
#include <source2.cpp>
... и все это компилится одним махом в бинарник), в случае ICC - файлы объединяются препроцессором. Эффект в принципе только в том что делаются более агрессивно inline , насколько я понимаю.

ps: в целом производительность кода GCC 4.5.x пока низкая, также было и с 4.4, потом перед релизом оптимизировали, так что пока рано еще делать какие то выводы и бенчмарки.

Sylvia ★★★★★
()
Ответ на: комментарий от megabaks

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

Sylvia ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.