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

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

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

Но если добавить -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 + ...

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

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

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

a/b; // a - переменная, b - константа

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

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

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

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

Спасибо за развёрнутое объяснение!

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

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

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

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

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

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

AMD FX

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

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

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

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

Ну вот, а потом газифицируют, что 64бит нинужно.

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

https://ibin.co/4WiRSmAgcIhg.png

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

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

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

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

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

https://archive.org/details/GDC2015Fredriksson

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

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."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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 для быстрой математики - автовекторизацией? Ну, векторы начинают использоваться автоматически ....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример тебе будет, но позже.

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

Ага, вот ещё ключик нашёлся:

https://ubuntuforums.org/showthread.php?t=1477356
-mfpmath=both

его тоже попробую.

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

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.

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

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

Надо сложить множество флоатов, приведу пример на 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 по точности чисел. А так как эти числа дальше все равно используются как множетили/параметры логорифмов/других операций, а над резльтатами дальнеших вычислений в итоге делается вероятностый анализ, то она ни на что не влияет. Но чисто ради академического интереса стоит отметить, что она есть и что возможно при других задачах/наборах данных погрешность может быть выше и такие вещи полезно и знать.

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

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

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

Чересчур. Генерирует запись в память когда не следует https://stackoverflow.com/q/54524947/9585016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещё может кому ресурс пригодится (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://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"

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

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

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

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

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

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

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

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

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

Я про фриз. Про -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 бит.

[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

О как!

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

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

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

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