Информация об изменениях

Сообщение Re[11]: 2D-Linq и оптимизация цифровых фильтров от 29.06.2018 16:01

Изменено 29.06.2018 16:22 Pavel Dvorkin

Re[11]: 2D-Linq и оптимизация цифровых фильтров
Здравствуйте, Sinclair, Вы писали:

PD>>Протестируй Берешь gray-scaled image и вперед.

S>Для этого нужно иметь образец, и результат его применения.
S>Рандомное-то изображение этот код прожёвывает на ура — но без образца непонятно, правильный ли получается вариант.

Попробовал залить на RSDN — 500. Видимо, размер его не устраивает — оригинальный (8bpp BMP) — 21 Мб, сжатый до JPG — 6.5 Мб. Примерно 5000 * 4000 пикселей.

Время обработки на моем стареньком Phenom II X4 955.

Оригинальный Sauvola (тот, что дал тебе) 2.5 сек
Оптимизированный и с потоками — 200-250 мсек.

Уменьшать не буду — неинтересно.
Как тебе его передать ?

PD>>Думаю, раза в 3 примерно больше. Во-первых, потоки (на чистом WinAPI, с ивентами) , во-вторых, я учел тот факт, что будет массовая обработка, поэтому все эти массивы не выделяются каждый раз, а вместо этого VirtualAlloc одного большого блока, и если в следующий раз больше не нужно, то он переиспользуется — это тоже дало некоторый выигрыш. Ну и ряд других хитростей.

S>Ужас какой.

Может, конечно, и ужас, но когда стоит задача выжать по скорости все, что можно (потому что если будет недостаточно быстро,то это все равно, как если бы и вообще не было — пойдешь на любой ужас).

PD>>Но в конце концов все это переписали под CUDA. Вот там я и занимался примерно тем же, чем ты сейчас — придумывал реализации для такого алгоритма, который обычно пишется не думая.

S>В райском мире светлого будущего переписывать прикладную программу не понадобится.

Может быть, но только не раньше чем в райском мире светлого будущего.

А пока что, когда я начал разбираться с CUDA , то я сразу понял одно — почти все, что я знаю о программировании, здесь не работает. Дело в том, что там аппаратные потоки, и написать надо так, чтобы они могли работать параллельно. А там очень жесткие (по крайней мере тогда) были требования к тому, чтобы работало параллельно. Шаг вправо, шаг влево — и все работать будет, но только последовательно, и получим хороший penalty. Вот мы его и изгоняли.
Re[11]: 2D-Linq и оптимизация цифровых фильтров
Здравствуйте, Sinclair, Вы писали:

PD>>Протестируй Берешь gray-scaled image и вперед.

S>Для этого нужно иметь образец, и результат его применения.
S>Рандомное-то изображение этот код прожёвывает на ура — но без образца непонятно, правильный ли получается вариант.

Попробовал залить на RSDN — 500. Видимо, размер его не устраивает — оригинальный (8bpp BMP) — 21 Мб, сжатый до JPG — 6.5 Мб. Примерно 5000 * 4000 пикселей.

Время обработки на моем стареньком Phenom II X4 955.

Оригинальный Sauvola (тот, что дал тебе) 2.5 сек
Оптимизированный и с потоками — 200-250 мсек.

Уменьшать не буду — неинтересно.
Как тебе его передать ?

PD>>Думаю, раза в 3 примерно больше. Во-первых, потоки (на чистом WinAPI, с ивентами) , во-вторых, я учел тот факт, что будет массовая обработка, поэтому все эти массивы не выделяются каждый раз, а вместо этого VirtualAlloc одного большого блока, и если в следующий раз больше не нужно, то он переиспользуется — это тоже дало некоторый выигрыш. Ну и ряд других хитростей.

S>Ужас какой.

Может, конечно, и ужас, но когда стоит задача выжать по скорости все, что можно (потому что если будет недостаточно быстро,то это все равно, как если бы и вообще не было — пойдешь на любой ужас).

PD>>Но в конце концов все это переписали под CUDA. Вот там я и занимался примерно тем же, чем ты сейчас — придумывал реализации для такого алгоритма, который обычно пишется не думая.

S>В райском мире светлого будущего переписывать прикладную программу не понадобится.

Может быть, но только не раньше чем в райском мире светлого будущего.

А пока что, когда я начал разбираться с CUDA , то я сразу понял одно — почти все, что я знаю о программировании, здесь не работает. Дело в том, что там аппаратные потоки, и написать надо так, чтобы они могли работать параллельно. А там очень жесткие (по крайней мере тогда) были требования к тому, чтобы работало параллельно. Шаг вправо, шаг влево — и все работать будет, но только последовательно, и получим хороший penalty. Вот мы его и изгоняли. В итоге это чудо занимало примерно 500 строк, зато время обработки было 50 мсек на дешевой NVidia карте того времени (2008 год).