Здравствуйте, Sinclair, Вы писали:


S>Всё как раз наоборот. Стоит поменять задачу — скажем, увеличить радиус гаусс-блюра в фильтре — и код, написанный программистом "почти не думая", окажется не у дел.


Я под "поменять задачу" несколько иное имел в виду. Ты вторгся в матричные операции, а фильтры такого рода — это простейшее из того, что там есть. Для обработки изображения, может, этого фильтра и хватит, а вот для чего-то большего ?

Вот сейчас я со своими дипломниками как раз делал задачу, в которой хоть и есть простенький фильтр, но есть еще

Бинаризация по Sauvola (алгоритм со скользящим окном с целью как раз уменьшить число операций)
http://www.ee.oulu.fi/mvg/files/pdf/pdf_24.pdf

Нахождение линий по Хафу
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%A5%D0%B0%D1%84%D0%B0

и кое-что еще

Все это 99%, а простенький фильтр — 1%. Это тоже предложишь на LinQ переводить ? А если нет — зачем мне 1% кода переводить на LinQ ?

>А если он вдруг потратит время на оптимизацию этого "недумательного" кода, то всё станет ещё хуже: там же объём кода уже раз в 10 вырос — все вот эти loop unrolling, SIMD intrincics, это же всё не просто так. Теперь понять, куда воткнуть дополнительные коэффициенты, крайне тяжело.

Эээ, не передергивай. Он как раз потратил время на оптимизацию, потому что в алгоритмах обработки изображений O(N^2) — это очень хорошо, а зачастую бывает существенно хуже. А ты этой оптимизацией и не занимался, да и не ясно, сможешь ли вообще ей заняться.


PD>>Зачем ?
S>Затем, чтобы отучить людей бояться performance penalty.

И научить вот такому

http://rsdn.org/forum/flame.comp/4098976.1

Автор: Pavel Dvorkin
Дата: 29.12.10

Здравствуйте, Sinclair, Вы писали:


S>Всё как раз наоборот. Стоит поменять задачу — скажем, увеличить радиус гаусс-блюра в фильтре — и код, написанный программистом "почти не думая", окажется не у дел.


Я под "поменять задачу" несколько иное имел в виду. Ты вторгся в матричные операции, а фильтры такого рода — это простейшее из того, что там есть. Для обработки изображения, может, этого фильтра и хватит, а вот для чего-то большего ?

Вот сейчас я со своими дипломниками как раз делал задачу, в которой хоть и есть простенький фильтр, но есть еще

Бинаризация по Sauvola (алгоритм со скользящим окном с целью как раз уменьшить число операций)
http://www.ee.oulu.fi/mvg/files/pdf/pdf_24.pdf

Нахождение линий по Хафу
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%A5%D0%B0%D1%84%D0%B0

и кое-что еще

Все это 99%, а простенький фильтр — 1%. Это тоже предложишь на LinQ переводить ? А если нет — зачем мне 1% кода переводить на LinQ ?

>А если он вдруг потратит время на оптимизацию этого "недумательного" кода, то всё станет ещё хуже: там же объём кода уже раз в 10 вырос — все вот эти loop unrolling, SIMD intrincics, это же всё не просто так. Теперь понять, куда воткнуть дополнительные коэффициенты, крайне тяжело.

Эээ, не передергивай. Он как раз потратил время на оптимизацию, потому что в алгоритмах обработки изображений O(N^2) — это очень хорошо, а зачастую бывает существенно хуже. А ты этой оптимизацией и не занимался, да и не ясно, сможешь ли вообще ей заняться.


PD>>Зачем ?
S>Затем, чтобы отучить людей бояться performance penalty.

И научить вот такому

http://rsdn.org/forum/flame.comp/4098976.1

Автор: Pavel Dvorkin
Дата: 29.12.10

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

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