>влечет за собой использование оптимизации mmx,sse,sse2

для этого вроде как есть -O2 и -O3

>не влечет за собой использование оптимизации mmx,sse,sse2

У меня все в норме, использует. Можно для верности дополнительно указать -mssse3 и -O3 (-ftree-vectorize)

native включает

Кто сказал, что не включает?

http://www.linux.org.ru/forum/talks/4729581

П'гостите, а в чём смысл этого вашего анализа? Вы предлагаете посмотреть на коробки с конструкторами, из которых собираются мотоциклы, и, на основании своих визуальных наблюдений различных деталей, сказать, какой мотоцикл будет лучше (быстрей/комфортней/надёжней).

Не могли бы вы показать вывод

gcc -Q -march=native -mtune=native --help=ta

Какая у вас сис-ма, и версия gcc.

2yumko, если бы включал, я бы не спрашивал.

2Sylvia, Ваш ответ самый достойный, склоняю голову. Но из-за него возникают вопросы: Почему? Почему -Q врет? - Потому что не работает?

П'гостите, а в чём смысл этого вашего анализа?

-march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 -mtune=core2

vacata?

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

>Но из-за него возникают вопросы: Почему

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

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


И вообще gcc достаточно слабо использует все что выше sse2, -mmmx включается -march=i686 и выше

у всех свои методы, можно и на детальки смотреть и делать выводы

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

Начать нужно с того, что подавляющее большинство используемого софта основывается на event-driven модели, и не требует выжимания тактов. Следующим шагом является отбор софта, который работает в режиме прямого потребления процессора: кодеки, архиваторы. Если с соображаловкой всё в порядке, то становится ясно, что оптимизация по скорости в таком софте выполняется вручную: разрабатываются алгоритмы, делаются ручные хаки, типа ручного использования векторных расширений, ибо компиляторы до такой, вобщем-то, творческой работы ещё не скоро дойдут.

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

Считать команды - это 100% бред.

Прошу прощения, но вы не соответствующем топике пишите. То что вы обсуждаете находится здесь ->

http://www.linux.org.ru/forum/talks/4729581

Тому топику 2 месяца, нехорошо трупик пинать. Да и всплыл он тут.

Отвечая на ваш вопрос: а почему компилятор должен включать команды mmx, sse, sse2, etc? Это довольно специфичные расширения, абсолютно ненужные в повседневной жизни. Если нет резона их использовать, то компилятор и не будет.

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

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

Это п-ц, товарищи. Генту головного мозга, ГГМ.

я так понимаю что ваши предложения лезть в код каждой программы и вручную корпеть над ловлей плохо оптимизированных участков кода, исправлять их и отсылать в апстрим? Да , это хороший вариант, но трудоемкий и требующий знаний, большинство же пользователей ни временем, ни знаниями достаточного уровня не обладают, поэтому будут спрашивать об оптимизации средствами GCC или другого компилятора, даже если выигрыш будет в 5-7% это уже положительный результат, как ни крути.

Ваш подход не позволяет судить о степени оптимизации средствами GCC. Факт наличия каких-либо команд абсолютно перпендикулярен эффективнму коду.

В такой же манере можно сравнить население России и Швейцарии, и на основании количественного превосходства утверждать, что в России население живёт лучше, потому что его тупо больше.

да , не позволяет, и даже сравнение производительности с разными флагами все равно останется сравнением производительности в пределах одной программы.

Хотите предложить другой универсальный подход? Критиковать можно все, это легко.

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

Ох, вспоминаю, как недавно оптимизировал прогу для восстанановления по CRC32 1 «сломанного» байта информации: вместо O(n^2), стало O(n). Раньше вычислялось 2-3 суток (день на 4-х ядернике), сейчас меньше секунды :)

Хотите предложить другой универсальный подход? Критиковать можно все, это легко.

А один уже разве был? ;)

В любом случае, без специфичных знаний судить о ещё недоступных уму вещах - занятие крайне рискованное. Соответственно, для начала нужно получить эти специфичные знания, а потом уже предлагать какие-то подходы. А багаж знаний для оценки качества компилятора нужен просто невероятно большой (и у меня его в полном объёме нет).

на самом деле для десктопов эти 5% вообще непринципиальны, с помощью gcc можно разгонять в пределах 25%, с использованием всех его возможностей, если брать код и переписывать его более эффективно, то выигрыш будет многократный, другое дело что, 98% пользователей будут есть что дают (готовые сборки) 1.99% поиграют с флажками, включая FDO, и лишь кто-то напишет и пошлет патч в апстрим. mv прав с точки зрения эффективного программирования, но почему-то совсем не хочет понять что не все программисты, и не все хотят тратить много времени на анализ производительности, для некоторых достаточно магии -O99 -march=native -fmake-it-cool-and-fast , хотя бы и за счет психологии ツ
Могу привести примеры - если собирать что-то на удаленной машине и «поверить» на время что это локально, начинает казаться что система тормозит, второй пример - если пересобрать что-то с помощью ICC , то начнет казаться что все стало быстрое-быстрое, на самом деле может оказаться, что из за случайности ни флаги, ни компилятор не менялись, и вообще пакет был пересобран в идентичном прошлому варианту виде

спасибо, что собственно и требовалось, будем дальше считать SSE инструкции в бинарниках, гентушникам это нравится, психологическое восприятие работает, если программа «оптимизирована» , значит воспринимается что она работает быстрее, к счастью многие не сравнивают результаты даже прибросом измерения user time, system time, real time

на самом деле для десктопов эти 5% вообще непринципиальны, с помощью gcc можно разгонять в пределах 25%,

Не верю. Покажите десктопный пример, где пересборка с -O2 на ваши ключи даёт прирост 25%.

1.99% поиграют с флажками, включая FDO,

Линуксом пользуется примерно 1% обладателей компьютеров, вы о чём? И даже на линуксе 2% с флажками компилятора играться не будет. И даже с флажками ./configure, что для программы имеет несравнимо более ярко выраженный эффект, играться 2% не будет.

за счет психологии

У нас тут, всё же, технический форум, нет?

>Не верю. Покажите десктопный пример

FireFox 3.6.4beta/ Peacekeeper

GCC4.5.1: 3095 Points
FDO @ GCC4.3.4: 3347 Points
FDO @ GCC4.5.1: 3306 Points
официальная сборка: 2748 Points

+ 21% за счет FDO, +12% если просто брать оптимизацию флагами под -march=pentium4

не 25, но достаточно близко

Линуксом пользуется примерно 1% обладателей компьютеров

вот если их взять за 100% ... хотя и в других ОС есть те, кто занимаются этим, только их очень мало, а вот Линукс за счет своей открытости и привлекает, в том числе и на такие эксперименты

У нас тут, всё же, технический форум, нет?

для роботов?

FireFox 3.6.4beta/ Peacekeeper

+ 21% за счет FDO, +12% если просто брать оптимизацию флагами под -march=pentium4

Какая прелесть! Это что, после пересборки интернет на 21% стал быстрее, или юзер странички на 21% быстрее читать начал? =)

для роботов?

Нет, но оценивать сугубо технические вещи с точки зрения психологии и прочего фень шуя - это ненормально.

>Какая прелесть! Это что, после пересборки интернет на 21% стал быстрее, или юзер странички на 21% быстрее читать начал? =)

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

оценивать сугубо технические вещи с точки зрения психологии и прочего фень шуя - это ненормально.

абсолютно нормально, выбор многих вещей базируется на иных факторах нежели только технические.
ШГ / не ШГ
rpm / deb
Убунту / Дебиан
свистелки / аскетизм
winamp-like / foobar-like
список можно продолжать бесконечно, при наличии альтернатив у чего-либо будут учтены все факторы, и психологические далеко не в последнюю очередь

да ты упорот наглухо )

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

Смею предполагать, что 21% прироста скорости - это в каком-то синтетическом тесте, не имеющем ничего общего с реальностью. Соответственно, «после переконпеляции стало быстрей» - это опять психология.

список можно продолжать бесконечно

Вы тут список фень шуя выкатили, а не технических аспектов. И, на сколько я помню, даже в самом техническом сраче из этого списка (rpm vs deb) никто о технических сторонах никогда не говорил, потому что для правильного критического взгляда надо пособирать оба типа пакетов, чтобы иметь о них представление.

>Смею предполагать, что 21% прироста скорости - это в каком-то синтетическом тесте, не имеющем ничего общего с реальностью

а как еще анализировать производительность ? ) Более полного теста производительности браузеров чем Peacekeeper пока нет

Соответственно, «после переконпеляции стало быстрей» - это опять психология

какой «железный» аргумент... вот сейчас многие обновляют корки2 на и7 , они тоже за счет психологии быстрее работают ?)
Я привела результаты тестов , вполне измеряемые и однозначно показывающие прирост выше 15%, тут уже «в пределах погрешности» не сказать, а тесты, пусть даже и синтетические , тоже разрабатывают далеко не дилетанты в этом деле, даже в «потолочных» тестах фороникса бывает иногда какой-то смысл, да, можно сидеть и уповать на то что перепишут код и ждать этого вечно, а можно взять и отхватить 15% производительности просто за счет флажков GCC

а как еще анализировать производительность ? ) Более полного теста производительности браузеров чем Peacekeeper пока нет

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

какой «железный» аргумент... вот сейчас многие обновляют корки2 на и7 , они тоже за счет психологии быстрее работают ?)

Полагаю, что если юзер не конпеляет генту, не играет в ресурсоёмкие игры и не ставит новые виндовзы, то он разницы особо не увидет.

да, можно сидеть и уповать на то что перепишут код и ждать этого вечно, а можно взять и отхватить 15% производительности просто за счет флажков GCC

Ох уж эти девичьи мечты...

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

если этот текст перестает тормозить при скроллинге это может считаться положительной оценкой производительности? или изчезает ощущение того что меню «резиновое» и выпадает с задержкой ?

Полагаю, что если юзер не конпеляет генту, не играет в ресурсоёмкие игры и не ставит новые виндовзы, то он разницы особо не увидет

между core2 и core i7 возможно, а между pentium 3 и i7 ?
вот на pentium 4 ФФ уже подтормаживает, особенно на сайтах с обилием скриптов

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

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

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

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

2mv,

а почему компилятор должен включать команды mmx, sse, sse2, etc?

Потому, что так сказано в документации!

Жизнь у всех повседневная, за каждым днем идет НОВЫЙ день, несущий новые события.

Если нет резона их использовать, то компилятор и не будет.

т.е. Компилятор сам может определить врубить или не врубить оптимизацию?

P.S. А вообще вы призываете отказаться от любознательности.

ну для микро вариантов лучше начинать не с флажков gcc, а с построения самой системы: ядро, libc (glibc достаточно толстая библиотека для микроскопов) , классические утилиты или их замена в виде busybox ....

если этот текст перестает тормозить при скроллинге это может считаться положительной оценкой производительности? или изчезает ощущение того что меню «резиновое» и выпадает с задержкой ?

Только вот не убедите, что пересборкой с тем же комплектом фич такие тормоза решить можно. Даже если вдуг рендеринг со скроллингом на 25% быстрее станет, то какая разница, сколько рисуется страница: 5 секунд или 4? Впрочем, он и не станет...

между core2 и core i7 возможно, а между pentium 3 и i7 ?

Честно говоря, я особой разницы между Alasm на Спектруме и Emacs на i7 не вижу. Набирать текст программы можно было быстрей, чем он придумывается, и на Спектруме.

Или вот более реальный пример: Word 6 на 386sx-33 с 4мб памяти работал ну явно быстрее, чем используемый с тем же набором фич Word 2000 на Duron-700 с 256мб. Как так? Или раньше конпеляторы на столько лучше были? ;)

вот на pentium 4 ФФ уже подтормаживает, особенно на сайтах с обилием скриптов

Дык, на некоторых сайтах ФФ из-за js наглухо вешается и будучи запущенным на i7! ;)

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

Разумеется, всё это для гентушников. Они просто впадают в яростный экстаз, когда выходит новая субминорая версия gcc, потому что следущие трое суток можно онанировать на выхлоп конпелятора в консоли.

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

Объективного способа самостоятельно и грамотно оценить что-то, лежащее в не вашей компетенции, нет.

а почему компилятор должен включать команды mmx, sse, sse2, etc?

Потому, что так сказано в документации!

Что там сказано? Что на «if (a > b)» будет использовано векторное умножение с сатурацией?

т.е. Компилятор сам может определить врубить или не врубить оптимизацию?

Вы себе вообще представляете, что такое MMX, SSE, Altivec и прочее подобное, и для чего всё это нужно?

Нужен глибц, пока до поры до времени.

Я вам не говорил, что я начал с флажков ;).

>Что там сказано? Что на «if (a > b)» будет использовано векторное умножение с сатурацией?

Нет.

Вы себе вообще представляете, что такое MMX, SSE, Altivec и прочее подобное, и для чего всё это нужно?

Да.

>Честно говоря, я особой разницы между Alasm на Спектруме и Emacs на i7 не вижу. Набирать текст программы можно было быстрей, чем он придумывается, и на Спектруме.

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

Или вот более реальный пример: Word 6 на 386sx-33 с 4мб памяти работал ну явно быстрее, чем используемый с тем же набором фич Word 2000 на Duron-700 с 256мб. Как так? Или раньше конпеляторы на столько лучше были?

точно не хуже меня знаете в чем тут дело )

Разумеется, всё это для гентушников. ...

смешно, но неубедительно )

Объективного способа самостоятельно и грамотно оценить что-то, лежащее в не вашей компетенции, нет.

хорошо, свежесть продуктов оценивать требуется полный химическо-токсикологический анализ ? Если заболели - всегда 100% обязательно сделать клинические анализы крови, мочи, спермограмму, биохимический анализ крови, КТ и МРТ черепа, грудной клетки, тазовой области.... или достаточно померить температуру и рассказать для начала о своих жалобах врачу?

Стоит наверное делать разницу между абсолютно точными,точными в пределах допустимой погрешности (доверительная вероятность 95%), тестами приближенной оценки для пилотных исследований?
Не нужно так однобоко относиться ко всему.

Считать команды всё равно глупо. Даже если знаешь слово «спермограмма» %)

>даже если выигрыш будет в 5-7% это уже положительный результат, как ни крути

Положительный, но несущественный. Пользователей слабых компьютеров
среди гентушников ничтожно мало, наоборот, большая часть приобретает
мощные процессоры, чтобы компилировать быстрее. У новых процессоров
ещё больше возможностей, их тоже все надо использовать. И т.д.

Концепция генту - это перфекционизм в чистом виде. Однобокий такой.
Вот ты, например, хотя бы багрепорты отсылаешь. Т.е. есть какая-то
польза от этого. Ради чего за 5-7% борются остальные вообще непонятно.

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

ну это несколько патология, можно ведь одну генту использовать на нескольких компьютерах, или distcc,
сравнительно мощный десктоп -> нетбук , хотя я делала опрос в talks, мало кто использует такое, как ни странно.

Концепция генту - это перфекционизм в чистом виде

не забываем про гибкость ) у меня CFLAGS достаточно консервативны, в отличие от тех кто гоняется за перфекционизмом

CXXFLAGS="-march=pentium4 -msse2 -mmmx -fomit-frame-pointer -O2"
CFLAGS=«${CXXFLAGS} -pipe»

pentium4 - ноут

хотя бы багрепорты отсылаешь

не часто, и только по системным вещам или если бага настолько сильно меня касается

>Это что, после пересборки интернет на 21% стал быстрее, или юзер странички на 21% быстрее читать начал? =)

Какой пухленький! JS/рендеринг ускорился.

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

может low latency включили ? ツ
ядро не особенно то собирается под процессор, там всего-лишь используется -mtune=

>может low latency включили ? ツ
ядро не особенно то собирается под процессор, там всего-лишь используется -mtune=
Возможно, может HPET включил или что ещё. ^) Там ещё кеды 3.3 были, потом перешёл на 3.5 и на моём P4 всё летать стало.

Возможно, может HPET включил или что ещё.

lol

Я вот про это самое и троллю весь день: люди хз, что за баззворды, лишь бы включить и переконпелировать.

>lol
Но компиляция помогла жеж. ^) Кто мешал это сделать мейнтейнерам?

Но компиляция помогла жеж. ^)

Ведь вы даже не знаете, что именно вам помогло.

Кто мешал это сделать мейнтейнерам?

Мейнтейнеры только и делают, что весь день конпеляют. У них работа такая.

Срач не читал (да ты мне и сама все обьяснила в свое время), но возник вопрос - что почитать на тему профайлинга софта?
Ткнулся к мыщьху - у него только винда и профайлер от штеуда. Что есть гуевого в никсах?

kprof
xprof
как фронтенды к gprof,

но это не совсем то, под профилированием (fdo - feedback directed optimization, pgo - profile guided optimization) часто имеется ввиду несколько другая вещь, там gui не нужно, там просто трехэтапная сборка
1) сборка программы с -fprofile-generate , программа получается медленная, во время выполнения пишет статистику выполнений функций
2) установка и использование собранной программы, сбор статистики
3) make clean, -fprofile-generate сменяется на -fprofile-use , собираем и устанавливаем финальную сборку программы, при сборке gcc будет использовать собранную на этапе 1 статистику для оптимизации.


с помощью gprof , это как mv пишет, ловить плохо написанные участки кода где идет нагрузка и переписывать их