LINUX.ORG.RU

Автовекторизация в gcc (ia32)


1

1

Что-то меня скорость работы плагинов Cinelerra-GG не устраивала (6-7 фпс для color3way на одной дорожке 1280*720!), и я решил поглядеть, что мне может дать автовекторизация (так по ядрам Cin и так умеет раскидывать работу плагинов).

Покурил доки
https://locklessinc.com/articles/vectorize/

http://gcc.gnu.org/projects/tree-ssa/vectorization.html

врубил "-O3 -march=native -mtune native" вместо "-O2 -march=i486 -mtune=i686" (дефолт слакбилда, который я юзал). Скорость поднялась до 9 фпс, но векторных инструкций почти не было..

Проверял через скрипт, который нашёл тут

https://superuser.com/questions/726395/how-to-check-if-a-binary-requires-sse4...

https://pastebin.com/A8bAuHAP (почему-то концы строк он мне сделал виндовые! поменял через меню в kwrite, иначе не работало)

objdump -M intel -d /dev/shm/tmp/cinelerra-goodguy-20190211/cinelerra-5.1/plugins/color3way/i686/color3way.o | ./opcodes.sh -s SSE2 -s SSE3 -s SSE -s AVX -s FMA | less

ладно, не работает ... Но если добавить -fast-math так что флаги в global_config стали
CFLAGS_ := -O3 -ffast-math -ftree-vectorizer-verbose=2 -march=native -mtune=native -D__STDC_CONSTANT_MACROS

то скорость плагина возросла до 15 фпс, а в ассемблерном выхлопе появились всякие vmovss и прочие....

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

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-...

gcc --version gcc (GCC) 5.5.0

cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 21
model           : 2
model name      : AMD FX(tm)-4300 Quad-Core Processor
stepping        : 0
microcode       : 0x6000852
cpu MHz         : 1399.998
cache size      : 2048 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 16
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bugs            : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 7599.98
TLB size        : 1536 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Интересно, на 64-битной сборке прирост будет ли? Потом может быть проверю.

Ещё может кому ресурс пригодится (eng) https://www.agner.org/optimize/

Т.е. ты компилировал для команд 486-го процессора с помощью древнего компилятора?
Слушай, установи Убунту. Там по умолчанию всё намного лучше, чем ты «натюнишь» сам.

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

Убунту и прочие КДЕ(5) я и так погоняю на виртуалке с kvm. Но - позже ....

А так спасибо конечно, за совет.

Andrew-R ★★★ ()

Но если добавить -fast-math ... в ассемблерном выхлопе появились всякие vmovss и прочие....

Я это давно узнал, поэтому и компилирую с -fast-math , и юнит тесты тоже чтобы не сломалось.

Причина по которой, без -fast-math не включаются векторизация в следующем.

по умолчанию сложение работает так:

a1+a2+a3+a4... // последовательно

При векторизации так:

a1 + a5 + a9
a2 + a6 + a10
a3 + a7 + a11
a4 + a8 + a12
// потом складываются частичные суммы
// и добавляются остаточные слагаемые, если количество слагаемых не кратно 4
с точки зрения математики это одно и тоже.

Но с точки зрения типа double это разное

a1 + a5 + a9 +...+a2 +...
не будет равен
a1+a2+a3+a4 + ...
из-за округлений при сложении, и других ограничений типа double.

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

А -fast-math флаг, говорит компилятору, делай всё что угодно с оптимизациями, лишь бы это было правильно с точки зрения математики, а не с точки зрения получения точно такого же числа ответа, как и без оптимизаций.

Вот ещё пример, того что может сделать -fast-math, кроме изменения порядка при сложении. вместо

a/b; // a - переменная, b - константа
использовать
a * 1/b; // 1/b вычислено на этапе компиляции

fsb4000 ★★★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Вот ещё пример, того что может сделать -fast-math, кроме изменения порядка при сложении.

Это и без -ffast-math происходит.

С -ffast-math начинает заменяться, например, sqrt(a)*sqrt(b) или sqrt(a)/sqrt(b) на sqrt(a*b) и sqrt(a/b), соответственно.

utf8nowhere ★★★ ()
Ответ на: комментарий от Andrew-R

спасибо и utf8nowhere за уточнение.

Вот ещё что вспомнил на эту тему:

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

Вот можешь почитать:

https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-prec...

fsb4000 ★★★★★ ()

Что-то меня скорость работы плагинов Cinelerra-GG не устраивала

AMD FX

Кхм, так может процессор нужно купить?

anonymous ()

Ну и да, 64бит убанта порвёт твой 486 шлак.

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

А мжет и не нужно .. Это и так большой шаг вперёд по сравнению с прошлым (3800+, dual-core amd).

Проверил на 64-битной Слаке - по умолчанию 22 фпс, с оптимизациями "-O3, -ffast-math -march=native -mtune=native" - 30 фпс! И падает до 22 фпс только если поверх трэка с цветокорректируемым видео положить ещё трек с прозрачностью 50% и тех же размеров (1280x720). OpenGL медленнее, чем X11/Direct.

Andrew-R ★★★ ()

Собирай в 64. Однозначно есть смысл.

Потом посмотри что GCC с march=native понаделал. Я не доверяю этому native, потому что было однажды, что на процессоре с SSE, этот самый SSE не включался. Лучше самому сифлаги скрасноглазить.

Потом можешь inline-limit поднять. Прикрутить unsafe-loop-optimizations и unroll-loops. Такие бинари лучше не распространять, конечно, но для твоего конкретно CPU стоит значение подыскать. Тем более с cache_size: 2048 :)

Рекомендую с другой мажорной версией GCC попробовать сравнить. Со времён пятой ветки прошло довольно много времени.

a1batross ★★★★★ ()

Автовекторизация НЕ РАБОТАЕТ. Более того для получения серьезной производительности нужно серьезно изменить layout данных. Дело даже не в кэше. Компоненты должны правильно лежать, чтобы обойтись без горизонтальных операций над регистрами. Такое ни один компилятор не сможет сделать даже если догадается. Формат данных нужен совершенно другой.

https://archive.org/details/GDC2015Fredriksson

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

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

https://locklessinc.com/articles/vectorize/ - «gcc is very good, and can auto-vectorize many inner loops. However, if the expressions get too complex, vectorization will fail. gcc also may not be able to get the most optimal form of the loop kernel. In general, the simpler the code, the more likely gcc is to give good results.
However, you cannot expect gcc to give what you expect without a few tweaks. You may need to add the »--fast-math" to turn on associativity. You will definitely need to tell the compiler about alignment and array-overlap considerations to get good code.
On the other hand, gcc will still attempt to vectorize code which hasn't had changes done to it at all. It just won't be able to get nearly as much of a performance improvement as you might hope."

но в моём случае и так сработало.

Andrew-R ★★★ ()

Можно ещё -Ofast юзать вместо -O3 -ffast-math. Только про все опции, которые они включают читайте аккуратно.

anonymous ()
Ответ на: комментарий от fsb4000

Но с точки зрения типа double это разное

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

Тут кстати еще интересный вопрос. Я тут оптимизировал алгоритмы над float с avx2 на avx512 (там мложение/перемножение векторов, матриц и всякое такое прочее). Разница конечно есть, но погрешность минимальна. И что самое главное, если логически рассуждать, то avx512 вариант будет даже более математически точным, потому что кол-во операций в нем меньше, а значит и накопленная погрешность ниже. Но в целом там разница получалась в пределах тысячиных долей процента, что совершенно ни на что влияет.

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

Собирай в 64. Однозначно есть смысл.

Не знаю как с sse, но емнип с avx в 64битном режиме доступно больше регистров для этого самого avx.

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

Я тут оптимизировал алгоритмы над float с avx2 на avx512

Насовал симдов - это не значит «оптимизировал».

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

Ты даже близко не понимаешь - что такое «оптимизировать».

Но в целом там разница получалась в пределах тысячиных долей процента, что совершенно ни на что влияет.

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

Во-вторых, вероятнее всего проблема даже не в этом, а в, как я уже говорил «напихать симдов - не оптимизировать».

anonymous ()
Ответ на: комментарий от utf8nowhere

Это и без -ffast-math происходит.

Хоть он говорил и не про это, но. Опять эксперты на связи? https://godbolt.org/z/BoXba7

С -ffast-math начинает заменяться, например, sqrt(a)*sqrt(b) или sqrt(a)/sqrt(b) на sqrt(a*b) и sqrt(a/b), соответственно.

Нелепая херня.

anonymous ()

ffast-math это совсем про другое. В SSE полно скалярных инструкций.

Первый минорный прирост fps ты получил за счет переупорядочивания инструкций и более агрессивного инлайнинга. Второй буст fps был за счет того, что кое-где точные математические вычисления были заменены на более быстрые приближенные аналоги.

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

ffast-math это совсем про другое.

Именно про это.

В SSE полно скалярных инструкций.

Это ничего не меняет.

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

Нелепо. Всё это есть и в O3.

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

Так же нелепо. Никто ничего не заменяет какими-то приближенными аналогами.

Буст он получил за счёт того, что а) в 32битном режиме ублюдское abi и гцц использует -mfpmath=387 по дефолту. fm врубает -mfpmath=sse и он получает буст только за с чёт этого. б) без fm компилятор вообще ничего не может делать с fp, примеры уже приводились выше.

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

Ой, анонимус закукарекал, не понял о чем тебе писали выше.

Насовал симдов - это не значит «оптимизировал».

Симды там уже были и оптимизация как алгоритмическая, так и под avx2 специфику уже была произведена раньше. Основная задача была - переход на avx512 специфичное железо для увеличения объемов обрабатываемых данных в единицу времени. Ибо тут довольно жесткий реалтайм. Если ты не знаешь о чем говоришь, то лучше не говори. Если тебе не нравится слово «оптимизировал» читай его как «переписывал».

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

Что ты несешь? Я это прекрасно знаю. Я вот только не понимаю при чем тут это? Ты можешь мне пояснить как кол-во портов связано с куском из моего сообщения которое ты процитировал, можно не по колхозному. Сдается мне ты банально не понял о чем я писал. Но ведь так важно кукарекнуть на лоре=)

Во-вторых, вероятнее всего проблема даже не в этом, а в, как я уже говорил «напихать симдов - не оптимизировать».

Какая проблема? Нет никакой проблемы, ты о чем вообще? Разве я не а что-то жаловался? Я же не йобобо чтобы добиваться битэкзактности в флоат-операциях.

Ты даже близко не понимаешь - что такое «оптимизировать».

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

В 64-битном режиме под Арчем тоже есть прирост, но только в превью, рендеринг занимает столько же ...

https://lists.cinelerra-gg.org/pipermail/cin/2019-February/000290.html

I did some quick tests:
CFLAGS std --> -02  TIMEcompile= about 20 min
Playback --> unchecked "play every frame"; X11-OpenGL

Only edit --> framerate achivied = 30
edit + effects -->                            = 07

Renderig of 20 sec of mp4 video. Preset hd.youtube = 1 min 59 sec


CFLAGS new --> -03 -ffast-math  TIMEcompile= about 20 min (the same!)
Playback --> unchecked "play every frame"; X11-OpenGL

Only edit --> framerate achivied = 30
edit + effects -->                            = 13

Renderig of 20 sec of mp4 video. Preset hd.youtube = 1 min 59 sec (the same!)

результаты работы двух версий Синелерры идентичны..
https://lists.cinelerra-gg.org/pipermail/cin/2019-February/000294.html

>
>
> Would it be possible to render a project with "traditional" Cinelerra,
> then again with the optimized.
> Then import both rendered files into the traditional and set the top track
> to "subtract".
> Shouldn't be it a pure black?
>

Yes, I did it. For me is "pure black".

>

Да, я прочитал про нестабильность включения-невключения автовекторизации, что мол при каком-нибудь невинном действии с заголовками она ВНЕЗАПНО и НЕОЖИДАННО может перестать давать эффект, и это большая причина её не использовать..

Ну, геймдев это всё-таки геймдев, там игрушку на машине пользователя никто перекомпилировать не будет ...

тут ещё терминологический вопрос - считать ли использование sse/avx для быстрой математики - автовекторизацией? Ну, векторы начинают использоваться автоматически ....

Andrew-R ★★★ ()
Ответ на: комментарий от anonymous

Для дурачка анонимуса я поясню еще одну вещь, мой пост был о точности вычислений, а не оптимизации, кол-ве циклов цпу, портах и микро-операциях, латености, throughtput инструкций. Мой пости был о точности. На некотором классе операций, которые хорошо ложаться на simd, увеличение разрядности вектора позволяет сократить кол-во ЛОГИЧЕСКИХ операций, что ведет к изменению погрешности.

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

Симды там уже были и оптимизация как алгоритмическая, так и под avx2 специфику уже была произведена раньше. Основная задача была - переход на avx512 специфичное железо для увеличения объемов обрабатываемых данных в единицу времени. Ибо тут довольно жесткий реалтайм. Если ты не знаешь о чем говоришь, то лучше не говори. Если тебе не нравится слово «оптимизировал» читай его как «переписывал».

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

Что ты несешь? Я это прекрасно знаю. Я вот только не понимаю при чем тут это? Ты можешь мне пояснить как кол-во портов связано с куском из моего сообщения которое ты процитировал, можно не по колхозному. Сдается мне ты банально не понял о чем я писал. Но ведь так важно кукарекнуть на лоре=)

О, трепло начало кукарекать и делать вид, что оно чего-то знало, но почему-то не отвечает. Почему же? А теперь просит меня ей рассказать о том, как и с чем это связано? Если ты знало, то почему ты не знаешь «как это связано»?

Какая проблема? Нет никакой проблемы, ты о чем вообще? Разве я не а что-то жаловался? Я же не йобобо чтобы добиваться битэкзактности в флоат-операциях.

Проблема очевидна - ты нихрена не получил, а значит ты нихрена не смог. Во всех остальных случаях ты бы либо что-то получил, либо бы не страдал хернёй.

anonymous ()
Ответ на: комментарий от Dudraug

Ты начал перечислять все известные тебе базворды? Хорошо, предположим - ты говорил о точности, но зачем ты закукарекал про «это ничего мне не дало»? Зачем ты закукарекал о какой-то разнице?

На некотором классе операций, которые хорошо ложаться на simd, увеличение разрядности вектора позволяет сократить кол-во ЛОГИЧЕСКИХ операций, что ведет к изменению погрешности.

Ну дак покажи. Каким образом ширина влияет на кол-во операций? Ты пытаешься кукарекать про кол-во инструкций? Как это связано с операциями?

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

Сообщаю новость - если у тебя что-то оптимизировано - ты получаешь линейное увеличение производительности, всегда.

Да, но что это меняет? Изменилось тз, изменилась бизнес задача. Что дальше? Появилась задача использовать simd большей разрядности, увеличить кол-во обработанных данных. Тебя послушаешь, то увеличение разрядности simd вообще не имеет смысла=)

О, трепло начало кукарекать и делать вид, что оно чего-то знало, но почему-то не отвечает. Почему же? А теперь просит меня ей рассказать о том, как и с чем это связано? Если ты знало, то почему ты не знаешь «как это связано»?

Наверное потому что я знаю, что это никак не связано с темой о которой я говрил. А ты понял, что сел в лужу и не знаешь, что ответить.

Проблема очевидна - ты нихрена не получил, а значит ты нихрена не смог. Во всех остальных случаях ты бы либо что-то получил, либо бы не страдал хернёй.

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

Dudraug ★★★★★ ()
Ответ на: комментарий от Andrew-R

тут ещё терминологический вопрос - считать ли использование sse/avx для быстрой математики - автовекторизацией? Ну, векторы начинают использоваться автоматически ....

Это не векторизация, а бекенд для вычислений, который использует компилятор. Когда-то в штудах был колхозный сопроцессор, который занимался fp-вычислениями. Потом добавили симды и стало два вычислителя. И те и тем могли производить fp-вычисления.

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

В amd64-abi fp вообще передаются через симвдовые регистры и без sse ты 64битный код не соберёшь.

Всё это не имеет никакого отношения к векторизации.

Ну, геймдев это всё-таки геймдев, там игрушку на машине пользователя никто перекомпилировать не будет ...

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

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

Да, я прочитал про нестабильность включения-невключения автовекторизации,

Это это значит я не понял, но к векторизации всё это не имеет отношения. Да, без fast-math компилятор не сможет в векторизацию fp-вычислений, но раз ты не получил профита на арче - значит там ничего не векторизуется. И я не ошибся в причинах получения профита.

anonymous ()
Ответ на: комментарий от Dudraug

Да, но что это меняет? Изменилось тз, изменилась бизнес задача. Что дальше? Появилась задача использовать simd большей разрядности, увеличить кол-во обработанных данных. Тебя послушаешь, то увеличение разрядности simd вообще не имеет смысла=)

Ты совсем упоротый? Ты несёшь какую-то нелепую херню. Тебе сообщили, что в рамках оптимизированного кода увеличение ширины даёт линейное увеличение производительности, а ты мне кукарекаешь о «ебя послушаешь, то увеличение разрядности simd вообще не имеет смысла=)»?

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

Наверное потому что я знаю, что это никак не связано с темой о которой я говрил. А ты понял, что сел в лужу и не знаешь, что ответить.

Наверное потому что я знаю, что это связано с темой о которой я говрил. А ты понял, что сел в лужу и не знаешь, что ответить.

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

Чего ты там выполнил, клоун. Если только в фантазиях. Ты уже там с показаниями определись - получил ты изменения, либо нет. Наверное как всегда полы помыл и пришёл на лор кукарекать.

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

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

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

но раз ты не получил профита на арче - значит там ничего не векторизуется

на Арче как раз профит был - превью с эффектами стало работать почти в 2 раза быстрее. 13 фпс против 7.

Сейчас гляну, что будет с -mavx.

Andrew-R ★★★ ()
Последнее исправление: Andrew-R (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ты совсем упоротый? Ты несёшь какую-то нелепую херню. Тебе сообщили, что в рамках оптимизированного кода увеличение ширины даёт линейное увеличение производительности, а ты мне кукарекаешь о «ебя послушаешь, то увеличение разрядности simd вообще не имеет смысла=)»?

Это ты упоротый. Тебе сказал, что мол «да, линейное увеличение производительности, что с того». Я еще выше тебе описал, что можешь вместо «оптимизизровал» читать «переписывал», «адаптировал». Я не искал ботлнеков, это не было ни моей задачей, ни моей планом. Ты просто дое*ался до использованного словва, хотя я выше поправился уже и сказал, что использовал не корректное слово. Ты совсем йобобо?

Наверное потому что я знаю, что это связано с темой о которой я говрил. А ты понял, что сел в лужу и не знаешь, что ответить.

Наверное потому что тема о которой ты говорил никак не свяазанна с моей темой, не?

Чего ты там выполнил, клоун. Если только в фантазиях. Ты уже там с показаниями определись - получил ты изменения, либо нет. Наверное как всегда полы помыл и пришёл на лор кукарекать.

Ты совсем долбанутый? Тебе ж написали по циклам цпу ожидаемый профит на конечной системе получил.

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

Ты пытаешься кукарекать про кол-во инструкций?

Ты наверное совсем глупый, я тебе выше ответил, что нет. Как можно разговор вести с таким йобобо.

Dudraug ★★★★★ ()

Царь в треде, все в карету!

anonymous ()

Похоже, «настоящая» автовекторизация действительно не работает:

color3way.C:264:27: note: not vectorized: multiple nested loops.
color3way.C:264:27: note: bad loop form.
color3way.C:269:5: note: not vectorized: control flow in loop.
color3way.C:269:5: note: bad loop form.
color3way.C:272:5: note: not vectorized: control flow in loop.
color3way.C:272:5: note: bad loop form.
color3way.C:275:5: note: not vectorized: control flow in loop.
color3way.C:275:5: note: bad loop form.
color3way.C:278:5: note: not vectorized: control flow in loop.
color3way.C:278:5: note: bad loop form.
color3way.C:281:5: note: not vectorized: control flow in loop.
color3way.C:281:5: note: bad loop form.
color3way.C:284:5: note: not vectorized: control flow in loop.
color3way.C:284:5: note: bad loop form.

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

Andrew-R ★★★ ()
Ответ на: комментарий от anonymous

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

Надо сложить множество флоатов, приведу пример на 2 компонетных и 4 компонетных векторах. На реальном avx это будет 16 и 32(для avx2 и avx512). Все флоаты здесь >= 0

a1, a2,
a3, a4,
a5, a6,
a7, a8,
a9, a10,
a11,a12
==
r1, r2

r1+r2

На каждой итерации мы накапливаем сумму в векторе, накопленная сумма увеличивается. Как известно числа с плавающей точкой довольно специфичны, что значит, что складывая большое число и маленькое есть риск большой погрешности и по сути «потерять» маленькое значение.

Теперь возьмем реализацию для 4 компонетов

a1,a2,a3,a4,
+a5,a6,a7,a8,
a9,a10,a11,a12
==
r1, r2,r3,r4

r1+r2+r3+r4

Теперь мы имеем 4 промежутных результата и кол-во логических операций составляющих каждый из них меньше, чем в оригинале в два раза, что означает что сумма будет меньше и на поздних итеррациях вероятность сложения очень большого числа с маленьким уменьшается. В зависимости от специфики данных на этапе последнего сложения промежуточных значений ситуация мб разная. Но часто бывает, что в обоих вариантах накопленные суммы(r1+r2 - первый кейс, r1+r2+r3+r - второй кейс) будут иметь одинаковый порядок и погрешность будет в пределах допустимых.

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

Но на деле это обычно не существено. У меня получалась разница порядке 0.005% между avx2 и avx512 по точности чисел. А так как эти числа дальше все равно используются как множетили/параметры логорифмов/других операций, а над резльтатами дальнеших вычислений в итоге делается вероятностый анализ, то она ни на что не влияет. Но чисто ради академического интереса стоит отметить, что она есть и что возможно при других задачах/наборах данных погрешность может быть выше и такие вещи полезно и знать.

Dudraug ★★★★★ ()
Ответ на: комментарий от Andrew-R

ну написано же - if-ы во внутренних циклах мешают векторизации, в зависимости от того что там за условие, векторизация или принципиально не возможна, либо условие можно вынести из цикла (т.е. «шаблонные» копии цикла сделать), либо условия можно заменить условными присваиваниями (a ? b : c, a ? b : c и т.п.)

зы интеловский компилятор вроде изощрённее в автовекторизации control flow, может даже чересчур..

anonymous ()
Ответ на: комментарий от Dudraug

Сразу сделаю оговорку, я выразился не совсем корректно в прошлый раз и наверное был понят неверно. Да, я признаю, что в формулировке сказанной мной это звучит как бред.

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

Ну вообщем в конечном итоге ты говорил об изменении порядка сложения, но это не особо относится к симдам, ведь ты можешь и без них складывать так же, вернее ты будешь складывать так же, т.к. симды это лишь малая часть параллельности современного процессора. Вернее, до avx512 симдовая параллельность для флоатов была вообще дерьмом дерьма, особенно на даблах. Т.е. базовая параллельность у тебя 10, когда как параллельность самих симдов у тебя 4/8.

На самом деле, если у тебя в скалярной дрситне один аккумулятор, а в мивдовой дристне n, где n - ширина вектора(в флоатах/даблах) - твой код говно.

Надо сложить множество флоатов, приведу пример на 2 компонетных и 4 компонетных векторах.

Если у тебя действительно это реализовано так, как ты говоришь - твой код ещё более дерьмо.

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

Сообщаю новость - об этом все знают, даже в школе. Даже школяр, который прочитал про fast-math про это знает.

anonymous ()
Ответ на: комментарий от Andrew-R

на Арче как раз профит был - превью с эффектами стало работать почти в 2 раза быстрее. 13 фпс против 7.

Это не тот профит. В том, о чём ты говорил изначально - профита не было и ты сам об этом сообщил.

Сейчас гляну, что будет с -mavx.

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

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

Если у тебя действительно это реализовано так, как ты говоришь - твой код ещё более дерьмо.

Очевидно, что нет, это был сферический пример.

Dudraug ★★★★★ ()

Если позволите, то несколько советов.

Ещё может кому ресурс пригодится (eng) https://www.agner.org/optimize/

В том, что касается сборки/пересборки системы или пакетов, лучше гентарей никого не найти. Поэтому, я бы рекомендовал не этот сайт. А вот эту страничку https://wiki.gentoo.org/wiki/Safe_CFLAGS#AMD. Несмотря на то, что там всё таки safe flags, там дано более точное указание цели.

Исходя из:

vendor_id : AuthenticAMD
cpu family : 21
model : 2

прямо сразу можно сказать что CFLAGS я бы скрасноглазил вот так:

CFLAGS="-O2 -march=bdver1 -mtune=bdver1 -pipe -fomit-frame-pointer -sse4_2 -avx -m32 -mfpmath=sse"

Хотя, скорее всего, флаги -msse4_2 и avx будут выставлены компилятором автоматически, при указании корректного -march и при указании -mfpmath=sse. Флаг -fomit-frame-pointer может быть выставлен так же автоматически, даже при -О1, но это стоит проверить. У Вас довольно древний gcc, лучше бы да, его обновить.

Насчёт -O3 vs. -O2. Если коротко, то -О3 это чревато. Лучше оставить либо -O2, либо тогда уж ставить -Ofast. Последний флаг это тот же -О3, но с установленым -ffast-math. Нет, скажу сразу что system-wide я бы так не поставил. Причин несколько. Сам по себе -О3 включает ряд оптимизаций в части развёртывания циклов, например. Т.е., не факт что код будет в итоге быстрее, но факт что код будет больше. И весьма вероятен даже отрицательный прирост оптимизации. Ну и плюс ктому, с -ffast-math не все пакеты собираются (тот же sqlite), так что общесистемно ну его на хрен.

Плюс к тому, -ffast-math это довольно агрессивные оптимизации для арифметических вычислений (например, вещественную реассоциацию). Но увы и ах, они не совсем соответствуют IEEE, так что, если результат «где-то там», «примерно так» и «но это не точно» приемлем, то почему бы и нет, хотя, на инструкции ХММ это слабо влияет, если не включена поддержка sse (см. выше).

Как включить веккторизацию. Если принудительно, то указав флаги -ftree-vectorize и -ftree-vectorizer-verbose=N (хотя, данная опция сейчас deprecated и её лучше заменить на -fopt-info-vec). Если, конечно, будет возможно, то компилятор обеспечит использование SIMD. Но лучше бы сразу писать (если SIMD/NEON нужны) с https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, тогда компилятору нужно будет меньше думать. Примеры здесь https://gcc.gnu.org/projects/tree-ssa/vectorization.html#using. Для того же sse4_2 нужно будет

#include <smmintrin.h>
сделать. https://monoinfinito.wordpress.com/series/vectorization-in-gcc/

Линки по теме. https://habr.com/ru/company/intel/blog/158939/ https://wiki.gentoo.org/wiki/GCC_optimization#-msse.2C_-msse2.2C_-msse3.2C_-mmmx.2C_-m3dnow Плюс, не забываем про инстриники https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=SSE4_2.

В итоге CFLAGS я бы поставил так:

CFLAGS="-O2 -march=bdver1 -mtune=bdver1 -pipe -fomit-frame-pointer -sse4_2 -avx -m32 -mfpmath=sse -ftree-vectorize -fopt-info-vec"

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)

Прирост должен быть.

Интересно, на 64-битной сборке прирост будет ли?

Да, должен быть. Там -mfpmath=sse сразу должно быть выставлено, по умолчанию. Ну и всё зависит от версии компиля и использованных инструкций, конечно же.

Moisha_Liberman ★★ ()
Ответ на: Если позволите, то несколько советов. от Moisha_Liberman

Re: Если позволите, то несколько советов.

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

(фриз и при -O2 -march=i686 -mtune=i686)

С -Ofast один из пользователей на Арче словил глюки... так что ну его пока в таком виде.

Увы, как я уже сказал судя по информации компилятора, он практически ни один цикл автовекторизовать не смог. Я идею обоим-двум девелоперам двух веток Cinelerra закинул - может вдохновяться.

Обновлять системный gcc не очень хочется - опять патчить разное устаревшее ... ладно бы это был C, так тут - c++ со всеми его ..плюсами ...и минусами ...

Andrew-R ★★★ ()
Ответ на: Re: Если позволите, то несколько советов. от Andrew-R

Странно всё это.

Я про фриз. Про -Ofast я и не удивлён, странно было бы если бы оно ровненько завелось и взлетело. С -О3 или -Оfast всегда полно забавных эффектов.

Ну мне-то обновиться не проблема, система и так обновляется ибо rolling release это rolling release. Но было куда как веселее когда я воткнул в выхлоп emerge -pvq cinelerra:

[ebuild N ] sci-libs/fftw-3.3.8 USE="openmp (-altivec) -doc -fortran -mpi (-neon) -quad -static-libs -test -threads (-zbus)" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="avx sse sse2 -avx2 -fma3 -fma4" [ebuild N ] media-libs/a52dec-0.7.4-r7 USE="-djbfft -oss -static-libs" ABI_X86="(64) -32 (-x32)"

[ebuild N ] media-libs/faac-1.29.9.2 USE="-static-libs" ABI_X86="(64) -32 (-x32)"

[ebuild N ] media-libs/faad2-2.8.8 USE="-digitalradio -static-libs" ABI_X86="(64) -32 (-x32)"

[ebuild N ] app-eselect/eselect-xvmc-0.4

[ebuild N ] media-libs/libdv-1.0.0-r3 USE="-static-libs" ABI_X86="(64) -32 (-x32)"

[ebuild N ] media-video/mjpegtools-2.1.0-r4 USE=«gtk png sdl -dv -quicktime -sdlgfx -static-libs» ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86=«mmx»

[ebuild N ] x11-libs/libXvMC-1.0.10-r1 USE="-static-libs" ABI_X86="(64) -32 (-x32)"

[ebuild N ] media-video/cinelerra-2.3 USE="alsa opengl (-altivec) -css -debug -ieee1394 -oss" CPU_FLAGS_X86="mmx -3dnow"

Вовсе не факт что надо именно саму cinelerra пересобирать или её плагины. Судя по тому, что portage решила поставить мне в систему (самое интересное и вкусное я выделил жирным шрифтом), там надо пересобирать используемые библиотеки. Вот там-то и может быть реальный буст. GCC у меня (Gentoo 8.2.0-r6 p1.7) 8.2.0 и да, для 64 бит.

Moisha_Liberman ★★ ()
Ответ на: Странно всё это. от Moisha_Liberman

Re: Странно всё это.

[ebuild N ] media-video/cinelerra-2.3

Это другая Cinelerra ...

Я вот эту больше сейчас кручу:

https://www.cinelerra-gg.org/downloads/

Ебилд ТОЖЕ устарел, сейчас CinGG по другому адресу. https://gitlab.fi.muni.cz/xbocek1/d3-gentoo/blob/master/media-video/cinelerra...

# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6

DESCRIPTION="The most advanced non-linear video editor and compositor - Good Guy's version"
HOMEPAGE="https://cinelerra-cv.org/"

IUSE="+pref opus vpx"

RDEPEND=">=sci-libs/fftw-3
	>=media-libs/libtheora-1.1:="

DEPEND="${RDEPEND}
	app-arch/xz-utils
        virtual/pkgconfig
        dev-lang/nasm
	dev-util/ctags"

if [[ ${PV} = *9999* ]]; then
        inherit git-r3
        EGIT_REPO_URI="git://git.cinelerra-cv.org/goodguy/cinelerra.git"
	EGIT_CLONE_TYPE=shallow
else
        SRC_URI=""
        KEYWORDS="~amd64 ~arm ~arm64 ~x86"
fi

SLOT="0"

S="${WORKDIR}"/${P}/cinelerra-5.1

src_prepare() {
        ./autogen.sh
	default
}

src_configure() {
	CONF=""
	if use pref ; then
		CONF="${CONF} --prefix=/usr/local_cin"
	fi
        if use opus ; then
                CONF="${CONF} --with-opus --enable-opus"
        fi
        if use vpx ; then
                CONF="${CONF} --enable-libvpx"
        fi
	econf ${CONF}
}

src_compile() {
	emake
}

src_install() {
	emake -j1 -l1 DESTDIR="${D}" install

	# patch better render templates
	tar -xzf "${FILESDIR}"/fqt_mp4.tar.gz -C "${D}"/usr/share/cin/ffmpeg/

	if use pref ; then
		mkdir -p "${D}"/etc/env.d/
                cp "${FILESDIR}"/99local_cin "${D}"/etc/env.d/
        fi
}

pkg_postinst() {
	if use pref ; then
		elog "Don't forget to run env-update if first install"
	fi
}

git clone git://git.cinelerra-gg.org/goodguy/cinelerra.git
Клонирование в «cinelerra»…
remote: Counting objects: 11686, done.
remote: Compressing objects: 100% (8713/8713), done.
remote: Total 11686 (delta 3857), reused 10040 (delta 2789)
Получение объектов: 100% (11686/11686), 152.14 MiB | 105.00 KiB/s, готово.
Определение изменений: 100% (3857/3857), готово.
Распаковка файлов: 100% (11792/11792), готово.

В общем у кого Гента - тот и ебилд правит .... по мне так просто строчку EGIT_REPO_URI=«git://git.cinelerra-cv.org/goodguy/cinelerra.git» надо поправить, но без рабочей системы чтобы проверить я ничего наверняка не скажу ....

Про версии Cinelerra:
https://linuxvideoediting.blogspot.com/2018/11/istoriya-razvitiya-cinelerra.html

Andrew-R ★★★ ()
Ответ на: Re: Странно всё это. от Andrew-R

О как!

Тестанул этот ебилд. Хотя, оно и так ясно что там в зависимостях, запросило fftw, при чём с теми же флагами (openmp, sse, avx) что и раньше.

Так что, скорее всего, тут надо выкруживать корректные флаги для рантайм либ чисто для начала. Т.е., пересобирать именно их, новым компилём и с нормальной векторизацией. А потом уже эту cinelerra как-то крутить. Не будет нормальных и быстрых рантайм-библиотек, производительность так и будет на дне где-то.

Ну вот, как-то вот так, в общем.

P.S. Видео и аудио это вообще не моя поляна, если честно. По ламерству своему я вообще до вчерашнего дня и не знал что есть такой пакет. Прошу меня извинить, если что не так. =)

Moisha_Liberman ★★ ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.