Comments 33
По моему автор описал совсем уж очевидные преимущества и недостатки. Для людей, которые над этой темой не задумывались (имеют малое отношение к программированию, или совсем не имеют), статья «пойдет» как вводная, а для людей, хоть немного знакомых с темой будет «речью Капитана Очевидность».
Наверное в некотором роде действительно, так оно и есть — я действительно написал очевидные для специалиста вещи. Но я себя сознательно ограничивал, так как хотел описать проблему в общих чертах, что бы она была понятна не специалистам. Возможно, что я был не прав.
Я сразу понял, что статья написана для людей незнакомых с данной темой, и описана, по моему мнению, хорошо. Я работал с 3DNow, MMX, SSE, AVX, поэтому могу сказать, как человек знакомы с темой, что статья хорошо написана для людей абсолютно незнакомых с темой. По крайней мере, им станет понятно, чем отличаются те же SSE сборки от generic.
P.S. Правда я работал с упакованным и числами с плавающей точкой, но имею представление о работе с упакованными целочисленными числами. А так-же немного «ковырял» NEON для ARM.
P.S. Правда я работал с упакованным и числами с плавающей точкой, но имею представление о работе с упакованными целочисленными числами. А так-же немного «ковырял» NEON для ARM.
UFO just landed and posted this here
Указанное требование заставляет пересматривать способы хранения данных, например, хранить цветное изображение в виде набора отдельных цветовых плоскостей, а не в единой плоскости с чередованием цветовых каналов для каждой точки (как в BGR-24).
Проблема BGR24 не в том, что он BGR, а в том, что он 24. Это заставляет писать сумасшедшие костыли, которые чаще всего сводятся к конвертации этого дела в BGR32 и обратно. И хорошо, если у вас доступнен pshufb из SSSE3, а если нет?..
Если читатели сочтут эту тему интересной, то я готов написать несколько статей, которые будут описывать особенности оптимизации на конкретных примерах.
Да, было бы интересно почитать.
У каждого, кто пытался работать с BGR-24 на SSE2, наверное получились свои собственные уникальные костыли :)
Можно обрабатывать изображения используя IPP. Такой себе компромисс. Не так быстро как если бы при указанном подходе, но значительно быстрее, по сравнению с невекторизированным кодом. IPP может автоматически определять процессор, на котором исполняется.
Мне кажется, стоило бы упомянуть автовекторизацию кода, для каких компиляторов она доступна, какие лучшие практики применения, и т.п. Возможно, от большинства минусов в некоторых случаях можно было бы избавиться, ограничившись переупорядочиванием данных в памяти и добавлением флагов компиляции.
Также интересно применение NEON для ARM, в частности, при использовании LLVM-компилятора.
Также интересно применение NEON для ARM, в частности, при использовании LLVM-компилятора.
Я SIMD код люблю и уважаю в 2х случаях.
1. если он уже написан в составе какой-то библиотеки, вроде Accelerate.framework (vecLib + vImage)
2. если он был сгенерирован компилятором с включенной опцией vectorize loops. :)
Писать его самому — себе дороже, т.к. со всех сторон разложены грабли и легко можно сделать алгоритму только хуже.
1. если он уже написан в составе какой-то библиотеки, вроде Accelerate.framework (vecLib + vImage)
2. если он был сгенерирован компилятором с включенной опцией vectorize loops. :)
Писать его самому — себе дороже, т.к. со всех сторон разложены грабли и легко можно сделать алгоритму только хуже.
Может сразу OpenCL использовать?
В то время, когда все умные люди переходят на работу с числами с плавающей точкой для задач обработки изображений, вы продолжаете бороздить просторы большого театра.
Вот-вот
В 8 бит гамма корректированых хрен чего обработаешь, кроме самого примитивного
В 8 бит гамма корректированых хрен чего обработаешь, кроме самого примитивного
Дык распаковывайте в 16, а то и в 32.
Есть сумасшедшее количество алгоритмов, которым float в принципе не сдался, и которые гораздо быстрее провести в целочисленных вычислениях. Даже если в теории точность может пострадать, очень часто никого не волнуют +-0.5 отклонения.
Есть сумасшедшее количество алгоритмов, которым float в принципе не сдался, и которые гораздо быстрее провести в целочисленных вычислениях. Даже если в теории точность может пострадать, очень часто никого не волнуют +-0.5 отклонения.
8 bit? Это по 2 бита на канал? Ыы, разве такое на прктике встречается?
Вообще идеальная ситуация это когда компилятор сам векторизует то, что можно векторизовать. Писать SSE руками нудно и, к тому же, выигрыш не гарантирован.
А вот это уже интересно. Но еще нужно уметь векторизовывать на всех уровнях одновременно. Например, у меня 24 карточки Xeon Phi на 12 компах, мне хочется чтобы модель параллелизации была однородной.
Тут слишком много посторонних факторов — зависимость от ОС / характеристики линков между компами.
Не совсем. Тот же Intel поставляет в наборе MKL реализацию FFT, которая использует MPI. Вполне себе портабельно. Тут то же самое можно было бы сделать. Имхо между компьютерами общаться — так MPI это стандарт. А вот между девайсами — тут уж тривиально обернуть WinAPI/pthreads реализации в общий интерфейс, особенно если учесть что нужно всего лишь запустить поток. И тот же OpenMP, кстати, очень даже портабелен между операционками.
Странно, но на Хабре ничего не нашёл про практическое использование Xeon Phi. Было бы интересно почитать, как оно устроено и работает.
Ту векторизацию, о которой пишет автор, ни один компилятор никогда сам не сделает.
Мне кажется до этого-то техника должна дорости. Особенно если учесть что нам уже говорят про векторизацию в компиляторе. На простых кейсах точно, например если нам надо сделать
c = a + b где все переменные uint8_t* и обрабатываются в цикле, что мешает поделить конечное значение цикла, скажем, на 4 и поменять указатели на __m128i* или что-то в этом духе? А это как раз юз-кейс как у автора: обработка 32-битных картинок.
Да, было бы интересно почитать. Только не затягивайте пожалуйста, очень актуальная для многих тема.
Картинка заинтересовала. Только посмотрел я на неё несколько более приземлённо.
1. Чистая и очень дешёвая обработка пашни. Затрат на производство нет. Конь, пашет, тут же удобряет. Здесь же ест траву, нет затрат на пищу. Дёшево и чисто. Минус только в том, что надо трудиться, так что это плюс. Минус только для лентяев. И очень простое воспроизводство. Не нужно готовить супер-специалистов. Просто старики передают навык молодым. Нужен только конь и человек.
2. Грязная и дорогая обработка пашни. Разработка месторождений руды, добыча, литьё металла. На всё это нужно шахты, производство, оборудование. Огромные людские трудозатраты и огромное количество отходов, загрязнение и загаживание природы. При этом ещё нужно вспомнить о заводах, которые собственно делают станки, которые потом будут делать трактора. И всё это нужно по чему-то доставлять, а значит целая индустрия по строительству дорог. И это только одна стронона. А далее идёт топливо: добыча, производство, перевозка, отходы, выхлопы и т.д.
Забавно, что работая в IT мы как-то перестали задумываться о реальном мире.
1. Чистая и очень дешёвая обработка пашни. Затрат на производство нет. Конь, пашет, тут же удобряет. Здесь же ест траву, нет затрат на пищу. Дёшево и чисто. Минус только в том, что надо трудиться, так что это плюс. Минус только для лентяев. И очень простое воспроизводство. Не нужно готовить супер-специалистов. Просто старики передают навык молодым. Нужен только конь и человек.
2. Грязная и дорогая обработка пашни. Разработка месторождений руды, добыча, литьё металла. На всё это нужно шахты, производство, оборудование. Огромные людские трудозатраты и огромное количество отходов, загрязнение и загаживание природы. При этом ещё нужно вспомнить о заводах, которые собственно делают станки, которые потом будут делать трактора. И всё это нужно по чему-то доставлять, а значит целая индустрия по строительству дорог. И это только одна стронона. А далее идёт топливо: добыча, производство, перевозка, отходы, выхлопы и т.д.
Забавно, что работая в IT мы как-то перестали задумываться о реальном мире.
Sign up to leave a comment.
Стоит ли оптимизировать обработку изображений на С++ при помощи SIMD?