# /usr/local/bin/analyze-x86 /var/tmp/portage/dev-lang/python-3.1.3-r1/work/Python-3.1.3/libpython3.1.so
instructions:
cpuid: 0 nop: 6253 call: 22311 count: 294410
i686: 902
AVX: 198


и кстати там не только с YMM регистрами , с YMM регистрами там 3 инструкции,
и еще 195 раз другие насчитались )

AVXi: vaddsd
AVXi: vbroadcastss
AVXi: vmovapd
AVXi: vmovd
AVXi: vpcmpeqd
AVXi: vsubpd
AVXi: vsubsd
AVXi: vunpcklps
AVXi: vxorpd

пример конечно не с SSE4.2, но уж GCC не особенно жалует их,
там строковые функции в основном:
«crc32», «pcmpestri», «pcmpestrm», «pcmpistri», «pcmpistrm», «pcmpgtq», «popcnt»
вероятность их включения небольшая, хотя можно использовать -mpopcnt , он из набора AMD SSE4a («lzcnt», «popcnt», «extrq», «insertq», «movntsd» ,«movntss»)

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

Заодно посмотрели насколько GCC 4.6 способен векторизовать в AVX )

:D У меня аж три оверлея (kde, systemd, lcd-filtering) подключено, и я ещё четвёртый (x11) собираюсь подключать в связи с переходом на nouveau. Как мне жить?) Интересно, а как называется такая религия, которая заставляет человека ограничивать количество пакетов? =)

лишний бинарник, хлам, всё сломаецо - аааа *схватился за голову*

Где один - там и два. Ситуация не настолько критическая, чтобы чтото добавлять.

Вы мне лучше другое скажите. Корректных тестов предложить вы не можете, однако утверждаете про деградации и невозможность использования О3. Не парадокс ли?

Однако у меня появилась глупейшая идея, которую вы, как надеюсь люди более знающие(я на линуксе всего 4-5лет и всего 1,5года на генту), мне разъясните:

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

Внимание вопрос - почему невозможно сделать конфигуратор для сборки разных пакетов с разными параметрами оптимизации? Например в виде того же файла: пакет оптимизация.

Если возможно, то как?

>Если возможно, то как?

Заносишь в файл /etc/portage/env/<type>/<program> нужные CFLAGS

Например, у меня было как-то раз:

/etc/portage/env/app-arch/lbzip2

CFLAGS="-march=core2 -mtune=core2 -O3 -pipe -mfpmath=sse -msse4.1 -ftree-loop-distribution -ftree-vectorize -fgraphite-identity -Wno-all"

http://sergiosdj.wordpress.com/2008/06/24/how-to-personalize-a-packages-cflag...
это хотели?

И так с архиваторами, кодеками и ещё несколькими пакетами.

[ root@desktop ] megabaks # cat /etc/portage/env/app-arch/gzip 
CFLAGS="-O3 -march=core2 -mtune=generic -mfpmath=sse -msse4.1 -fomit-frame-pointer -pipe"
[ root@desktop ] megabaks #

оно?

хотя у меня есть ещё и env.d - осталось со времён, когда в какой-то версии портажа сломали env - пришлось городить велосипед

или это
http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-enviro... ?

ебилд может фильтровать флаги выставленые глобально, в минимальный набор,
для вайн например остается только -march и -mtune, все остальное отрежется

Заносишь в файл /etc/portage/env/<type>/<program> нужные CFLAGS

Благодарю, действительно работает. Теперь остается лишь одна проблема - тестирование пакетов(желательно автоматическое) на корректный выбор оптимизации.

сами то как представляете как это должно происходить?
разный софт тестируется по разному

> -march — это грубо говоря тот набор инструкций, которые будут доступны gcc при генерации результата.

А -mtune — это грубо говоря порядок расположения инструкций из заданного набора в выдаче, основанный на характеристиках процессора

А разве нельзя написать скрипт, прогоняющий пакеты с разными наборами флагов и сравнивающий результаты?

сами то как представляете как это должно происходить? разный софт тестируется по разному

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

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

>Если возможно, то как?

acovea. За конечное, но оочень большое время ты получишь оптимальную оптимизацию для любого пакета

оно разве ещё живо и актуально?

>Вот например - для одного приложения один свой тест

Это называется «бенчмарк». У многих проектов есть набор юнит-тестов. У некоторых есть и специальные тесты, направленные на выявление регрессий в производительности (у Qt, например). Автоматически сгенерировать бенчмарк «для всего на свете» нереально, так как понятие «скорости работы» не универсально

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

Это называется «бенчмарк». У многих проектов есть набор юнит-тестов. У некоторых есть и специальные тесты, направленные на выявление регрессий в производительности (у Qt, например). Автоматически сгенерировать бенчмарк «для всего на свете» нереально, так как понятие «скорости работы» не универсально

На самом деле понятие скорости стабильно, потому как мы (допустим) тестируем три типа оптимизации на одной и той же машине: Os, O2, O3. И сравниваем. Вопрос в том, что пакетов обычно очень много - у меня 600+ и все вручную это конечно глупо проверять. Нужна возможность автоматизации. Попробую найти русскоязычную информацию по тому же app-benchmarks/acovea и понять что это вообще.

как ?

собирать с разными можно, а как сравнивать ?
для FF например сравнение в веб - peacekeeper, sunspider и прочие
для архиваторов - скорость перелопачивания данных
для gtk например gtkperf, которая кстати с разными флагами сборки gtk давала отличие только в 2% максимум, давно мерила правда

нет универсального метода.
для синтетики есть acovea, но синтетические тесты на то и синтетические, что к реальности могут не иметь никакого отношения.

к тому же, смешно было бы посмотреть на подбор флагов для Опенофиса например :) или xulrunner даже. Проку может быть на копейку, а электричества спалится на перекомпиляции куча, не говоря уже о затратах личного времени.

Use -O2 , Luke, and let it be as it is )
бинарщики вон не мучаются, а у гентушников по любому есть выигрыш, даже от -march, не говоря уже об удобных USE флагах

>На самом деле понятие скорости стабильно

o rly? можно определить скорость работы отдельной функции. Для программы с возможностью нелинейного исполнения это понятие просто неопределно

не говоря уже о затратах личного времени.

Use -O2 , Luke, and let it be as it is ) бинарщики вон не мучаются, а у гентушников по любому есть выигрыш, даже от -march, не говоря уже об удобных USE флагах

Никто не заставляет сидеть часами и смотреть на компиляцию, все может идти на фоне (тем более что теперь я лично тестировал на своей машине j64 - никаких лагов ;)).

«Видишь суслика? А он есть..» Если мы пока до чего то не додумались - не факт, что это невозможно - в любом случае оптимизации много не бывает, особенно, если сделать все удобно. Иначе можно до винды скатиться.

o rly? можно определить скорость работы отдельной функции. Для программы с возможностью нелинейного исполнения это понятие просто неопределно

А кто мешает тщательно протестировать эту самую целую программу с тремя различными параметрами? Тут вопрос лишь во времени, а не в невозможности. А с современным железом это даже смешно обсуждать.

думаете разработчики программы этого не делают?

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

ps: я не против тестов для отдельных пакетов, но таким образом подходить ко всем 1000+ пакетов... нет, это уже ненормально

вот mv на вас нет, чтобы он вам тут сказал что флажки это полная ерунда,

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

ps: я не против тестов для отдельных пакетов, но таким образом подходить ко всем 1000+ пакетов... нет, это уже ненормально

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

тем более.
предлагаете каждый пакетик по 3 раза пересобирать , да еще и testsuite гонять?

Thu Feb 24 19:13:54 2011 >>> www-client/chromium-10.0.648.114
merge time: 32 minutes.

Thu Mar 3 19:07:42 2011 >>> www-client/chromium-10.0.648.126
merge time: 31 minutes and 1 second.

Fri Mar 4 18:35:27 2011 >>> www-client/chromium-10.0.648.127
merge time: 31 minutes and 21 seconds.

Sat Mar 12 20:40:03 2011 >>> www-client/chromium-10.0.648.133
merge time: 34 minutes and 54 seconds.

Fri Mar 18 20:25:40 2011 >>> www-client/chromium-10.0.648.151
merge time: 29 minutes and 12 seconds.

Wed Mar 23 16:30:19 2011 >>> www-client/chromium-11.0.696.16
merge time: 30 minutes and 48 seconds.

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

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

Человек спит в среднем 8 часов в сутки. А это уже несколько пакетов. Или вообще на фоне, благо современные системы это позволяют. Так что, ничего нереального.

ок, пишите, ждем LightDiveToo с пакетным менеджером в котором будет блэкджек и тесты параметров компиляции для каждого собираемого пакета.

PS: и не забудем про отправку результатов тестов в апстрим, разработчикам,
по поводу допустим проблем с -O3

ок, пишите, ждем LightDiveToo с пакетным менеджером в котором будет блэкджек и тесты параметров компиляции для каждого собираемого пакета.

Я вспомнил! Извиняюсь, но я вспомнил. Обновление на генту не такое большое. Если обновляться раз в день/неделю - это всего пара пакетов. Вот потому и идея, что эти то пару пакетов легко можно успеть проверить. Потому никаки не тысяча каждый раз.

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

у меня ~x86 , я прекрасно знаю сколько это пакетов в среднем,

я просто хочу сказать, что от компилятора и его флажков зависит не так много,
есть конечно и исключения, но если задать -march, то отклонения будут очень маленькие между -O2 и чем-то еще, в типичном случае овчинка с подбором флагов методом перебора не стоит выделки и затрат времени, даже процессорного, даже ночью, я не зря привела выхлоп genlop -t chromium, обновляют его часто, собирать его полчаса, спасибо, мне совсем не хочется чтобы хромиум и ему подобные пакеты собирались по три раза.

посмотрим что портеж послал нам сегодня вечером -

[ebuild U ] sys-apps/pciutils-3.1.7-r1 [3.1.7] USE="-static-libs%"
[ebuild U ] dev-libs/gmime-2.4.24 [2.4.23]
[ebuild R ] sys-power/upower-0.9.9 USE="-ios% (-ipod%)"
[ebuild R ] media-sound/clementine-0.7_rc1 USE="-ios% (-iphone%)"
[ebuild U ] gnome-base/gnome-control-center-2.32.1-r1 [2.32.1]
[ebuild U ] kde-base/kdelibs-4.6.1-r2 [4.6.1-r1]
[ebuild R ] gnome-base/gvfs-1.6.7 USE="-ios% (-iphone%)"

честно, мне все равно какой будет уровень оптимизации у всех этих пакетов, -O2 необходимо и достаточно ) Из интересного только kdelibs

честно, мне все равно какой будет уровень оптимизации у всех этих пакетов, -O2 необходимо и достаточно ) Из интересного только kdelibs

Это линукс, тут никого никогда ничего не заставляют делать. Все только добровольно. Можете хоть бинарниками ставить. Я говорю о том, что возможность то теоретически есть - осталось лишь ее реализовать. а про то, что оптимизация мала - если бы она не была вообще заметна, не сделали бы флаг О3, это вопервых. Вовторых - оптимизируем один пакет, второй, третий. В итоге уже чтото.

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

я скажу что не нужно устраивать из этого культ

Ну почему же сразу культ. Мы уже выяснили, что оптимизация это как минимум хорошо. Нужно просто сделать ее удобной и максимально незаметной при работе. Никому от этого плохо не будет. Тем более - с мощностью современных систем даже 1-2% эту уже мощности целых компьютеров древних.

суть в том, что результаты этой оптимизации обычно будут также незаметны при работе...

делайте конечно, кто ж запрещает то )

Блин, сколько раз можно говорить : «родной» сайт для GCC - sources.redhat.com. gnu.org обновляется весьма непредсказуемо.

В частности, сабж - ftp://sources.redhat.com/pub/gcc/releases/gcc-4.6.0

не нужно говорить
надо всего лишь погонять на LOR-time-machine и написать новость

Есть дельное предложение

Я вообще собираюсь Qt4 учить и писать лёгкий DE на нём.

Можешь присоединиться к команде разработчиков Leechcraft — это модульный интернет-клиент с прицелом на то, чтобы в итоге стать отдельным DE. Русскоязычный тимлид, соответствие твоим целям — имхо, самое оно. Если заинтересовало, начни с FAQ у них на сайте.

Не получится сделать самокат на базе БелАЗа...

Вопросик по приведённому package.compilers.

Многоуважаемая Силвия,

Очень мне Ваш файлик понравился. Раньше про это не задумывался, но вот 30% регрессии - это как-то слишком. Поэтому надо-таки держать несколько компиляторов в системе видимо. Спасибо за тест! Заодно поближе присмотрюсь к clang, всё равно в CUDA с ним придётся разбираться.

А теперь вопрос: как конкретно такая структура делается? Это стандартные средства или самописное? Порылся в инете, но там всё грязные хаки с bashrc, и вот такой удобной структуры нет, обычно всё руками надо под каждый компилятор дописывать.

Т.е. в моих нуждах, скорее всего, эти 30% не важны, т.к. я сам программу оптимизирую довольно сильно в плане работы с кэшами и т.п. да и пользует она в основном floating point и обычно близка к теоретической производительности процессора. Но всё-таки, надо бы библиотечки пересобрать, lapack-и там всякие с arpack-ами и прочими fftw.

Кстати, гражданин megabaks сильно удивится, если узнает, что с lapack линкуется в том числе и hugin, если мне склероз не изменяет. Пока ничего лучше для склейки панорам не нашёл.

Заранее спасибо за ответ.

не удивится - он таким не пользуется просто
и всё на свете знать не получится

:-) Согласен.

Я просто к тому, что максимализм - это тоже не всегда хорошо. Хотя... вспоминая себя лет 15 назад на Физтехе, когда начинал возиться с первыми своими линухами и бздями, меня тоже раздражало, что какие-то пакеты тянут по зависимостям этот «никому не нужный» f2c. Но и до сих пор сталкиваюсь с тем, что есть куча НУЖНОГО кода, который есть только в виде фортрановских библиотек. Совсем не зря в моих любимых C-ях сделали возможность вызова функций из фортрана. Выглядит это в красивом и логичном коде страшнее ядерной войны! Но - деваться некуда. Те, кто написали, часто уже умерли, а функция работает и эффективно.

Правда, надо бы ARPACK переписать... Надо будет летом подумать над вопросом. Там вроде не так много, а вот с ограничениями столкнулся фортрановскими. Да и алгоритмы вроде как есть уже лучше. А последние из часто используемых LAPACK-овских функций вроде как недавно переписали интеловцы (подозреваю, как бы не в Нижнем или Новосибе :-) ). А то собственные значения произвольных (в том числе, комплекснозначных) матриц раньше только через вызов фотрановской функции искать надо было.

А Вам удачи и успехов в Ваших правильных и нужных делах, вроде Вашего сайта. И не ленитесь, люди ведь страждут во тьме без знания. ;-)

Уточнение.

Например, смотрел вот тут:

http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage#.2Fetc.2Fportage.2Fbashrc

Но это типичное «тёплое ламповое» решение, т.е. «грязный хак». А хочется чего-то более стандартного и красивого для использования и гибкой настройки нескольких компиляторов в системе. Есть ли такое?

у неё емнип свой врапер для сего
уж не знаю насколько этот хак окажется чище правки bashrc )

я просто собираю разные версии с разными --prefix

--prefix=/usr/local/gcc-4.6

выбирать можно через симлинк

ln -s /usr/local/gcc-4.6/bin/gcc /usr/local/bin/cc46

( и аналогично для g++)

CC=cc46 CXX=c++46


или второй (лучше) способ , через PATH

export PATH=/usr/local/gcc-4.6/bin:$PATH


есть еще третий вариант, gcc и g++ меняются на враппер скрипт,
которым еще можно и флаги контролировать

Понятно.

Спасибо за ответ!

Нет, это не то, чего бы мне хотелось. Хотя имеено через симлинки я и насоздавал компиляторов уже. Буду городить очередной велосипед через bashrc так, чтобы мне нравилось и было универсально в моём понимании.

Хотя странно это, казалось бы стандартная вешь. Нормально было бы и стандартное решение иметь. Тот же LAPACK и BLAS собирать icc, например, вполне логично...

стандартного нет,
если только gcc-config обозвать стандартным решением

а в остальном более принято bashrc + package.compilers или установка отдельного env для пакета