[C] IPP для OpenSource

Конкретно мне нужны алгоритмы преобразования цветовых пространств

В педивикии же все есть. Вычислений там немного, так что достаточно openMP применить, чтобы распараллелить вычисления. Ну, а если уж очень быстро надо считать и при этом визуализировать посредством openGL, можно и GPU привлечь. Там тоже совсем ничего сложного нет.

framewave от amd. почти полный аналог ipp, только халявный

openmp тут не поможет, данные вещи надо векторизовать с помощью sse, а opengl (а точнее glsl) полезен только при выводе на экран

http://intel.ly/yiDiH7 вот?

данные вещи надо векторизовать с помощью sse

И что, реально производительность повысится? А можно пример (или это и есть framewave)? Самому интересно встроить эти алгоритмы в свой велосипед.

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

И что, реально производительность повысится?

реально

А можно пример (или это и есть framewave)?

да

И да, все-таки, зацикливаться на недопроцессорах от штеуда - как-то хреново. ИМХО, надо архитектурно-независимый алгоритм реализовать, или же сразу оптимизировать еще по крайней мере под MIPS и ARM.

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

Спасибо, поковыряюсь - может, что-нибудь ценное оттуда можно будет стащить (правда, к сожалению, там все в плюсах - задолбаюсь в си конвертировать).

OpenMP для таких вещей не работает

Да ладно: просто вместо последовательного прохода одним потоком по всему изображению, пробегаться в N потоков по каждой из 1/N части изображения. У меня на четырехъядернике прирост производительности просто за счет использования openMP составлял до ~3 раз.

To Анонимус: Человечище, спасибо :) Помнил же что есть опенсорсная версия, а найти не мог.

To Reset: Спасибо за наводку, посмотрю, может и framewave использую

To всем: Выдыхайте :)

Во-первых изображение должно вмещаться в кеш, а если оно не влезает, то над каждым пикселем должно совершаться преобразование отличное от O(1) по сложности, тогда будет прирост. Для преобразований YUV->RGB и наоборот это не выполняется. А если алгоритм работает только для определенных размеров, то я считаю, что он не работает вообще.

Полазил в нутре framewave. Жесть! Даже просто при смене endianness алгоритмы не будут работать.

Конечно не будут, у них всё заточено под x86. Тебе скорость нужна или портабельность? Одновременно и то и то недостижимо.

А в gcc есть автоматическое преобразование кода с оптимизацией под SSEx?

Есть, но если бы оно работало эффективно, то таких монстров как framewave никто бы не создавал.

http://code.google.com/p/pixfc-sse/

Reset

над каждым пикселем должно совершаться преобразование отличное от O(1) по сложности

что ты такое говоришь-то!

Хорошо, с O(1) не очень корректно. Пусть будет некое сложное действие, которое занимает ощутимое время. Иначе всё упрется в память и никакого толку от потоков не будет. Для примера blas level 1,2 практически не параллелятся по этим причинам.