Сообщение 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. Вот мы его и изгоняли.
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 год).
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 год).