Как стать автором
Обновить

Комментарии 33

По моему автор описал совсем уж очевидные преимущества и недостатки. Для людей, которые над этой темой не задумывались (имеют малое отношение к программированию, или совсем не имеют), статья «пойдет» как вводная, а для людей, хоть немного знакомых с темой будет «речью Капитана Очевидность».
Наверное в некотором роде действительно, так оно и есть — я действительно написал очевидные для специалиста вещи. Но я себя сознательно ограничивал, так как хотел описать проблему в общих чертах, что бы она была понятна не специалистам. Возможно, что я был не прав.
Я сразу понял, что статья написана для людей незнакомых с данной темой, и описана, по моему мнению, хорошо. Я работал с 3DNow, MMX, SSE, AVX, поэтому могу сказать, как человек знакомы с темой, что статья хорошо написана для людей абсолютно незнакомых с темой. По крайней мере, им станет понятно, чем отличаются те же SSE сборки от generic.
P.S. Правда я работал с упакованным и числами с плавающей точкой, но имею представление о работе с упакованными целочисленными числами. А так-же немного «ковырял» NEON для ARM.
Я больше по целым числам специализируюсь. Но MMX я уже не застал. Лет пять колупал SSE2, последний год — AVX2. Возможно, что скоро руки дойдут до NEON.
Ну MMX я тоже не застал (а если и застал, то слишком «мелким» был), скорее ради академического интереса на нем написал пару программ.
НЛО прилетело и опубликовало эту надпись здесь
Указанное требование заставляет пересматривать способы хранения данных, например, хранить цветное изображение в виде набора отдельных цветовых плоскостей, а не в единой плоскости с чередованием цветовых каналов для каждой точки (как в BGR-24).

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

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

Да, было бы интересно почитать.
У каждого, кто пытался работать с BGR-24 на SSE2, наверное получились свои собственные уникальные костыли :)
И хорошо, если у вас доступнен pshufb из SSSE3, а если нет?

Тогда так
Не всегда выход, поскольку требует содержать отдельную рутину для обработки планарного RGB, в то время как pshufb позволяет использовать одну и ту же рутину для RGB32 и RGB24 с разницей лишь в пару инструкций.
Кроме того, а как паковать обратно-то будем? :)
Если вы внимательно присмотритесь, то заметите, что эти преобразования работают в обе стороны.
Можно обрабатывать изображения используя IPP. Такой себе компромисс. Не так быстро как если бы при указанном подходе, но значительно быстрее, по сравнению с невекторизированным кодом. IPP может автоматически определять процессор, на котором исполняется.
Я думаю, что реализация на IPP будет даже быстрее, если конечно найдется именно та функция, что вам нужна. К сожалению за IPP нужно денежку платить.
Под Linux не в коммерческих целях вполне бесплатно. Но это очень частный случай. Хотя если больно уж захочется попробовать…
Мне кажется, стоило бы упомянуть автовекторизацию кода, для каких компиляторов она доступна, какие лучшие практики применения, и т.п. Возможно, от большинства минусов в некоторых случаях можно было бы избавиться, ограничившись переупорядочиванием данных в памяти и добавлением флагов компиляции.
Также интересно применение NEON для ARM, в частности, при использовании LLVM-компилятора.
Я SIMD код люблю и уважаю в 2х случаях.
1. если он уже написан в составе какой-то библиотеки, вроде Accelerate.framework (vecLib + vImage)
2. если он был сгенерирован компилятором с включенной опцией vectorize loops. :)
Писать его самому — себе дороже, т.к. со всех сторон разложены грабли и легко можно сделать алгоритму только хуже.
Может сразу OpenCL использовать?
Тогда уж OpenVX, когда его до ума доведут.
В то время, когда все умные люди переходят на работу с числами с плавающей точкой для задач обработки изображений, вы продолжаете бороздить просторы большого театра.
Вот-вот

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

Дык распаковывайте в 16, а то и в 32.
Есть сумасшедшее количество алгоритмов, которым float в принципе не сдался, и которые гораздо быстрее провести в целочисленных вычислениях. Даже если в теории точность может пострадать, очень часто никого не волнуют +-0.5 отклонения.
8 bit? Это по 2 бита на канал? Ыы, разве такое на прктике встречается?
Вообще идеальная ситуация это когда компилятор сам векторизует то, что можно векторизовать. Писать SSE руками нудно и, к тому же, выигрыш не гарантирован.
без доработки языка ничего хорошего не получится
ispc.github.io/
А вот это уже интересно. Но еще нужно уметь векторизовывать на всех уровнях одновременно. Например, у меня 24 карточки Xeon Phi на 12 компах, мне хочется чтобы модель параллелизации была однородной.
Тут слишком много посторонних факторов — зависимость от ОС / характеристики линков между компами.
Не совсем. Тот же Intel поставляет в наборе MKL реализацию FFT, которая использует MPI. Вполне себе портабельно. Тут то же самое можно было бы сделать. Имхо между компьютерами общаться — так MPI это стандарт. А вот между девайсами — тут уж тривиально обернуть WinAPI/pthreads реализации в общий интерфейс, особенно если учесть что нужно всего лишь запустить поток. И тот же OpenMP, кстати, очень даже портабелен между операционками.
Странно, но на Хабре ничего не нашёл про практическое использование Xeon Phi. Было бы интересно почитать, как оно устроено и работает.
Ну это не удивительно. Технология во-первых достаточно свежая, а во-вторых очень дорогая для обычного потербителя — намного дороже чем CUDA, хоть и дешевле чем, например, использование FPGA.
Ту векторизацию, о которой пишет автор, ни один компилятор никогда сам не сделает.
Мне кажется до этого-то техника должна дорости. Особенно если учесть что нам уже говорят про векторизацию в компиляторе. На простых кейсах точно, например если нам надо сделать c = a + b где все переменные uint8_t* и обрабатываются в цикле, что мешает поделить конечное значение цикла, скажем, на 4 и поменять указатели на __m128i* или что-то в этом духе? А это как раз юз-кейс как у автора: обработка 32-битных картинок.
Да, было бы интересно почитать. Только не затягивайте пожалуйста, очень актуальная для многих тема.
Картинка заинтересовала. Только посмотрел я на неё несколько более приземлённо.
1. Чистая и очень дешёвая обработка пашни. Затрат на производство нет. Конь, пашет, тут же удобряет. Здесь же ест траву, нет затрат на пищу. Дёшево и чисто. Минус только в том, что надо трудиться, так что это плюс. Минус только для лентяев. И очень простое воспроизводство. Не нужно готовить супер-специалистов. Просто старики передают навык молодым. Нужен только конь и человек.
2. Грязная и дорогая обработка пашни. Разработка месторождений руды, добыча, литьё металла. На всё это нужно шахты, производство, оборудование. Огромные людские трудозатраты и огромное количество отходов, загрязнение и загаживание природы. При этом ещё нужно вспомнить о заводах, которые собственно делают станки, которые потом будут делать трактора. И всё это нужно по чему-то доставлять, а значит целая индустрия по строительству дорог. И это только одна стронона. А далее идёт топливо: добыча, производство, перевозка, отходы, выхлопы и т.д.
Забавно, что работая в IT мы как-то перестали задумываться о реальном мире.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.