Экстремальная оптимизация

[Samae1L]

Всех с наступившим -)). Заинтересовался такими вещами, как PGO (профилирование) и сборкой некоторых пакетов компилятором icc. Говорят, что первое даёт немыслимый прирост скорости работы программ, второе тоже отменно оптимизирует собираемый софт. Но начал искать в гугле информацию по сборке с PGO - получаю нечто неарвзумительное на уровне кухонных разговоров, без конкретных алгоритмов действий. Кто располагает такими манами, подкиньте, пожалуйста.

Кстати, ещё вопрос: PGO не сделает работу программ нестабильной или даже невозможной на других машинах?

[taaroa]

Говорят, что первое даёт немыслимый прирост скорости работы программ, второе тоже отменно оптимизирует собираемый софт.

говорить можно что угодно. то, что действительно подлежит оптимизации - это ассемблерный код (архиваторы кодеки etc), лучший путь - оптимизировать алгоритмы. это действительно даст существенный прирост.
всё остальное от лукавого. рисковать стабильностью рабочей системы ради призрачных ~5% (в лучшем случае) неразумно.

[Samae1L]

у меня другая информация на этот счёт - firefox с pgo ускоряется в разы

[Goodvin]

у меня другая информация на этот счёт - firefox с pgo ускоряется в разы

Ускоряется ЧТО?
Скачивание контента из интернета?
Рендеринг HTML движком геко?
Чтение с диска?
Исполнение скриптов?

[Samae1L]

Рендеринг HTML движком геко?

да
и скорость интерфейса тоже

[neol]

http://dom.as/2009/07/27/profile-guided-op...ation-with-gcc/

I measured ~7% of sysbench performance increase (and probably would see much higher value in CPU-tight benchmarks).

[irony]Но firefox однозначно ускорится в пицот раз минимум.[irony]

[megabaks]

плохо гуглишь - http://www.linux.org.ru/wiki/en/%D0%A1%D0%...DO/PGO/LWP)_.3F
неосиляторам с "призрачные ~5% (в лучшем случае)" предлагаю не позориться и потереть свой бред

[taaroa]

неосиляторам с "призрачные ~5% (в лучшем случае)" предлагаю не позориться и потереть свой бред

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

Многие алгоритмы уже были отпрофилированы авторами кода вручную, и некоторые даже переписаны на язык assembler, поэтому не удивляйтесь , если потратив уйму времени на профилирование вашего любимого медиа-кодека вы получите прирост менее 1%

[megabaks]

т.е. предлагаешь мне сейчас вспомнить цифры всех тестов или пересобирать желаемые проги? о_О
бяда

[megabaks]

лови
это с icc и флагами -O3 -gcc -xSSE4.1 -ftz

Код: Выделить всё

megabaks@desktop ~/testio $ time `bzip2 chromium-9.0.597.19.tar && bunzip2 chromium-9.0.597.19.tar.bz2 && bzip2 chromium-9.0.597.19.tar && bunzip2 chromium-9.0.597.19.tar.bz2 && bzip2 chromium-9.0.597.19.tar && bunzip2 chromium-9.0.597.19.tar.bz2`

real    5m9.165s
user    4m39.990s
sys    3m23.519s
megabaks@desktop ~/testio $

а это с гцц и флагами -O2 -march=i686

Код: Выделить всё

megabaks@desktop ~/testio $ time `bzip2 chromium-9.0.597.19.tar && bunzip2 chromium-9.0.597.19.tar.bz2 && bzip2 chromium-9.0.597.19.tar && bunzip2 chromium-9.0.597.19.tar.bz2 && bzip2 chromium-9.0.597.19.tar && bunzip2 chromium-9.0.597.19.tar.bz2`

real    6m18.753s
user    4m48.146s
sys    5m19.444s
megabaks@desktop ~/testio $

проценты посчитаешь?
да - все тесты проводились в tmpfs с отключенных свопом и 3-х кратным сбросом кэшей перед каждым тестом

[neol]

лови
...оверквотинг поскипан
проценты посчитаешь?
да - все тесты проводились в tmpfs с отключенных свопом и 3-х кратным сбросом кэшей перед каждым тестом

Что показывают real, user и sys?

[Samae1L]

Собранные бинарные файлы будут привязаны к типу процессора (конвееру, размеру кешей, конкретным ключам сборки, например -mfpmath=sse) , что может проявиться снижением производительности на других процессорах, особенно с меньшим кешем, типом конвеера (in order execution на Intel Atom например), что существенно ограничивает распространение собранных данным методом программ

а если мой процессор имеет самый маленький кэш среди своей архитектуры (core 2), на других процах той же архитектуры (core 2 и выше) регрессий производительности не будет?

[megabaks]

Что показывают real, user и sys?

ну почитай ман, если так интересно

[serzh-z]

ну почитай ман, если так интересно

"Я принёс вам посылку, от Дяди Фёдора, только я её вам не отдам", ага? )

Я слабо понимаю, почему real оказался меньше, чем user+sys.

[megabaks]

не - ну ещё предложите мне объяснить - что это вообще за символы таки! (цЫфры)
ну как дети в самом деле!
попросили тестов - ловите!

[megabaks]

Я слабо понимаю, почему real оказался меньше, чем user+sys.

а они и не должны совпадать!
так и быть - наберу за тебя

Код: Выделить всё

man time

Код: Выделить всё

The  time command runs the specified program command with the given arguments.  When command finishes, time writes a message to standard
       error giving timing statistics about this program run.  These statistics consist of (i) the elapsed real  time  between  invocation  and
       termination,  (ii) the user CPU time (the sum of the tms_utime and tms_cutime values in a struct tms as returned by times(2)), and (iii)
       the system CPU time (the sum of the tms_stime and tms_cstime values in a struct tms as returned by times(2)).

[drBatty]

неосиляторам с "призрачные ~5% (в лучшем случае)" предлагаю не позориться и потереть свой бред

это не бред. действительно, привязка к типу CPU даёт некоторое ускорение, и оно тем больше, чем более кроссплатформенен проект. Создатели FF естественно не привязывают код к CPU, потому даже таким способом можно выиграть (имхо ненужные) 20%. Ну и что? можно обложится спеками на недельку, и выиграть все 50, а может и больше %%.

проценты посчитаешь?

вы таки ещё что-либо по древнее возьмите. bzip2 это очень древняя программа, рассчитанная на компьютеры с маленькой памятью. Просто увеличте размер блока, и bzip2 станет работать в разы быстрее. Кроме того, вы можете просчитывать сразу N блоков, это приведёт ещё к увеличению быстродействия на 15-20%, а ещё можно сменить хафмана на арифметика, что позволит добиться ещё большего ускорения. Толку-то?

регрессий производительности не будет?

будет.

[megabaks]

твой пост - это многократное /0
не пиши мне такого больше!

[drBatty]

твой пост - это многократное /0

лор.... такой лор... не вижу в своём посте деления на ноль.

[megabaks]

тролль - такой тролль

неосиляторам с "призрачные ~5% (в лучшем случае)" предлагаю не позориться и потереть свой бред

это не бред

и тут же

потому даже таким способом можно выиграть (имхо ненужные) 20%

и

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

где /0 найдёшь?
или пальчиком показать?

[drBatty]

firefox с pgo ускоряется в разы

способом можно выиграть (имхо ненужные) 20%

"в разы" и 20% - это далеко не одно и тоже.

где /0 найдёшь?
или пальчиком показать?

дык я писал о том, что выигрыш даже 50% - мелочь. проще, а главное дешевле купить более мощное железо, чем заниматься пересборкой, которая заведомо даст не очень хорошие результаты. Ну вот зачем вы пересобирали bzip2? не проще-ли использовать xz, который при той-же степени сжатия работает быстрее (ценой большего количества потребляемой памяти, и новому алгоритму LZMA2)?

Ну ладно, собрали. Что дальше? Будете юзать в гордом одиночестве до первого апгрейда? А потом опять пересобирать, причём дважды на каждый комп, и ещё собирать статистику? Все опции компиляции == компромисс. Иначе-бы это не опции были, а фичи. И компромисс для каждого компьютера свой. Если на одном компьютере программа будет работать на 7% быстрее, то на другом на 500% медленнее, если вообще заработает. Мало того, опасно применять свои уникальные опции, можно напороться на баг, который не был обнаружен разрабом (ибо он такие опции не применял), даже если комп один, вы замучаетесь фиксить этот баг, или ждать пока его пофиксят (если пофиксят конечно, что тоже не факт).

Короче - оправданно только в одном случае - если вы нищеброд, у вас есть iPI-MMX-166, и вы хотите смотреть кино (такого процессора чуть-чуть не хватает для просмотра фильмов, а разница в фильмах - критична. Это не архиватор, где нет принципиальной разницы, ждать 100 часов, или 93).

Расскажите другие случаи применения такой оптимизации на десктопе?

[megabaks]

я не понимаю - вот зачем мне xz например - если в bzip2 мильён сорсов?
предоставишь проксю, которая из *bz2 будет делать мне *xz? )
тогда не вопрос - выкину бзип!
и да - про переносимость не понимаю - гента - это конструктор! и на каждой машине сей конструктор уникален - зачем переносимость да ещё с сохранением производительности?
понятно, что лучше рисовать нормальный код (jpeg => libjpeg-turbo как пример) но сборка с разными ключиками и прочими ухищрениями даёт таки профит на том же железе
идея "зачем оптимизировать? - лучше купить новое железо" - это признак...кхм...не буду выражаться

Короче - оправданно только в одном случае - если вы нищеброд, у вас есть iPI-MMX-166, и вы хотите смотреть кино (такого процессора чуть-чуть не хватает для просмотра фильмов, а разница в фильмах - критична. Это не архиватор, где нет принципиальной разницы, ждать 100 часов, или 93).

Расскажите другие случаи применения такой оптимизации на десктопе?

ОЛОЛО!!!111 )))

[megabaks]

Чорд, опять деление на ноль!

Ну вот зачем вы пересобирали bzip2? не проще-ли использовать xz, который при той-же степени сжатия работает быстрее

+

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

а ты забавный :3
ничего что я не тратя ни копейки получил более быстрый архиватор, причём НУЖНЫЙ мне!?
таки праздники продолжаются )

[drBatty]

я не понимаю - вот зачем мне xz например - если в bzip2 мильён сорсов?
предоставишь проксю, которая из *bz2 будет делать мне *xz? )
тогда не вопрос - выкину бзип!

раньше всё было в gzip'е. и что? в слаквари уже давно xz, множество исходников сейчас в lzma или в том-же xz - так они меньше места занимают.

и да - про переносимость не понимаю - гента - это конструктор! и на каждой машине сей конструктор уникален - зачем переносимость да ещё с сохранением производительности?

переносимость что-бы переносить К.О.
причём без красноглазия, просто собрав ебильд (раз уж речь про Gentoo).

понятно, что лучше рисовать нормальный код (jpeg => libjpeg-turbo как пример) но сборка с разными ключиками и прочими ухищрениями даёт таки профит на том же железе
идея "зачем оптимизировать? - лучше купить новое железо" - это признак...кхм...не буду выражаться

а я немного не так сказал - я вовсе не против оптимизации, просто надо помнить, что только 5-15% кода нуждается в оптимизации, и обычно она уже написана на ассемблере, и никакой оптимизации там не получится.

А вот переносимость и надёжность затрагивает 100% кода, а вы таки используете опции ГЛОБАЛЬНО, ко всему проекту, что очень чревато как раз вашим делением на ноль (вот выкинет компилятор кусок "ненужного" кода, и при вычислении например времени работы этого кода в рантайме получится 0, о чём автор никак не подозревал, и на это время таки поделил - в итоге, у всех работает, у вас - нет. Здравствуй дебагер.). Есть и другие неожиданности...

ничего что я не тратя ни копейки получил более быстрый архиватор, причём НУЖНЫЙ мне!?
таки праздники продолжаются )

ты таки тоже презабавный. хотя я рад за тебя, ведь твоё время не стоит ни копейки... это пройдёт :(

Какая собственно разница, сколько занимает распаковка? 0.03 или там 0.07 секунд? или у тебя действительно первый пень?

[Samae1L]

про bzip - можно просто поставить lbzip2 и не выёживаться с xz

[megabaks]

ебилд - правило сборки! ФСЁ!
флаги на каждой генте свои!
тут никто не собирается ничего переносить!

lbzip2|pbzip2 не совсем хорошо на сорсах - внутрях-то один файл обычно

раньше всё было в gzip'е. и что? в слаквари уже давно xz, множество исходников сейчас в lzma или в том-же xz - так они меньше места занимают.

ты вообще адекватный?
я же тебе написал - мильён сорсов в bz2 - накой хрен мне твои xz?