Стоит ли оптимизировать обработку изображений на С++ при помощи SIMD?

[BratSinot]

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

[ErmIg]

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

[BratSinot]

Я сразу понял, что статья написана для людей незнакомых с данной темой, и описана, по моему мнению, хорошо. Я работал с 3DNow, MMX, SSE, AVX, поэтому могу сказать, как человек знакомы с темой, что статья хорошо написана для людей абсолютно незнакомых с темой. По крайней мере, им станет понятно, чем отличаются те же SSE сборки от generic.
P.S. Правда я работал с упакованным и числами с плавающей точкой, но имею представление о работе с упакованными целочисленными числами. А так-же немного «ковырял» NEON для ARM.

[ErmIg]

Я больше по целым числам специализируюсь. Но MMX я уже не застал. Лет пять колупал SSE2, последний год — AVX2. Возможно, что скоро руки дойдут до NEON.

[BratSinot]

Ну MMX я тоже не застал (а если и застал, то слишком «мелким» был), скорее ради академического интереса на нем написал пару программ.

[tp7]

Указанное требование заставляет пересматривать способы хранения данных, например, хранить цветное изображение в виде набора отдельных цветовых плоскостей, а не в единой плоскости с чередованием цветовых каналов для каждой точки (как в BGR-24).

Проблема BGR24 не в том, что он BGR, а в том, что он 24. Это заставляет писать сумасшедшие костыли, которые чаще всего сводятся к конвертации этого дела в BGR32 и обратно. И хорошо, если у вас доступнен pshufb из SSSE3, а если нет?..

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

Да, было бы интересно почитать.

[ErmIg]

У каждого, кто пытался работать с BGR-24 на SSE2, наверное получились свои собственные уникальные костыли :)

[Maratyszcza]

И хорошо, если у вас доступнен pshufb из SSSE3, а если нет?

Тогда так

[tp7]

Не всегда выход, поскольку требует содержать отдельную рутину для обработки планарного RGB, в то время как pshufb позволяет использовать одну и ту же рутину для RGB32 и RGB24 с разницей лишь в пару инструкций.
Кроме того, а как паковать обратно-то будем? :)

[Maratyszcza]

Если вы внимательно присмотритесь, то заметите, что эти преобразования работают в обе стороны.

[FT232BM]

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

[ErmIg]

Я думаю, что реализация на IPP будет даже быстрее, если конечно найдется именно та функция, что вам нужна. К сожалению за IPP нужно денежку платить.

[FT232BM]

Под Linux не в коммерческих целях вполне бесплатно. Но это очень частный случай. Хотя если больно уж захочется попробовать…

[Yan169]

Мне кажется, стоило бы упомянуть автовекторизацию кода, для каких компиляторов она доступна, какие лучшие практики применения, и т.п. Возможно, от большинства минусов в некоторых случаях можно было бы избавиться, ограничившись переупорядочиванием данных в памяти и добавлением флагов компиляции.
Также интересно применение NEON для ARM, в частности, при использовании LLVM-компилятора.

[mOlind]

Я SIMD код люблю и уважаю в 2х случаях.
1. если он уже написан в составе какой-то библиотеки, вроде Accelerate.framework (vecLib + vImage)
2. если он был сгенерирован компилятором с включенной опцией vectorize loops. :)
Писать его самому — себе дороже, т.к. со всех сторон разложены грабли и легко можно сделать алгоритму только хуже.

[fshp]

Может сразу OpenCL использовать?

[ErmIg]

Тогда уж OpenVX, когда его до ума доведут.

[HounD]

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

[vladimirovich]

Вот-вот

В 8 бит гамма корректированых хрен чего обработаешь, кроме самого примитивного

[tp7]

Дык распаковывайте в 16, а то и в 32.
Есть сумасшедшее количество алгоритмов, которым float в принципе не сдался, и которые гораздо быстрее провести в целочисленных вычислениях. Даже если в теории точность может пострадать, очень часто никого не волнуют +-0.5 отклонения.

[Psionic]

8 bit? Это по 2 бита на канал? Ыы, разве такое на прктике встречается?

[mezastel]

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

[beeruser]

без доработки языка ничего хорошего не получится
ispc.github.io/

[mezastel]

А вот это уже интересно. Но еще нужно уметь векторизовывать на всех уровнях одновременно. Например, у меня 24 карточки Xeon Phi на 12 компах, мне хочется чтобы модель параллелизации была однородной.

[beeruser]

Тут слишком много посторонних факторов — зависимость от ОС / характеристики линков между компами.

[mezastel]

Не совсем. Тот же Intel поставляет в наборе MKL реализацию FFT, которая использует MPI. Вполне себе портабельно. Тут то же самое можно было бы сделать. Имхо между компьютерами общаться — так MPI это стандарт. А вот между девайсами — тут уж тривиально обернуть WinAPI/pthreads реализации в общий интерфейс, особенно если учесть что нужно всего лишь запустить поток. И тот же OpenMP, кстати, очень даже портабелен между операционками.

[encyclopedist]

Странно, но на Хабре ничего не нашёл про практическое использование Xeon Phi. Было бы интересно почитать, как оно устроено и работает.

[mezastel]

Ну это не удивительно. Технология во-первых достаточно свежая, а во-вторых очень дорогая для обычного потербителя — намного дороже чем CUDA, хоть и дешевле чем, например, использование FPGA.

[leventov]

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

[mezastel]

Мне кажется до этого-то техника должна дорости. Особенно если учесть что нам уже говорят про векторизацию в компиляторе. На простых кейсах точно, например если нам надо сделать c = a + b где все переменные uint8_t* и обрабатываются в цикле, что мешает поделить конечное значение цикла, скажем, на 4 и поменять указатели на __m128i* или что-то в этом духе? А это как раз юз-кейс как у автора: обработка 32-битных картинок.

[alekseev_ap]

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

[JawsIk]

Картинка заинтересовала. Только посмотрел я на неё несколько более приземлённо.
1. Чистая и очень дешёвая обработка пашни. Затрат на производство нет. Конь, пашет, тут же удобряет. Здесь же ест траву, нет затрат на пищу. Дёшево и чисто. Минус только в том, что надо трудиться, так что это плюс. Минус только для лентяев. И очень простое воспроизводство. Не нужно готовить супер-специалистов. Просто старики передают навык молодым. Нужен только конь и человек.
2. Грязная и дорогая обработка пашни. Разработка месторождений руды, добыча, литьё металла. На всё это нужно шахты, производство, оборудование. Огромные людские трудозатраты и огромное количество отходов, загрязнение и загаживание природы. При этом ещё нужно вспомнить о заводах, которые собственно делают станки, которые потом будут делать трактора. И всё это нужно по чему-то доставлять, а значит целая индустрия по строительству дорог. И это только одна стронона. А далее идёт топливо: добыча, производство, перевозка, отходы, выхлопы и т.д.
Забавно, что работая в IT мы как-то перестали задумываться о реальном мире.