Сообщение Re[3]: 2D-Linq и оптимизация цифровых фильтров - 3 от 03.07.2018 12:53
Изменено 03.07.2018 13:08 Pavel Dvorkin
Re[3]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Sinclair, Вы писали:
S>2. Во-вторых, есть подзадача с рекуррентным определением. Она сулит феерические впечатления при поисках возможности параллелизации.
S>Пока что нахожусь на этапе мучительных поисков синтаксиса.
А мы на этапе ожидания феерических результатов.
Для затравки, кстати — в своем коде я оптимизировал вот этот кусочек. Не понравился мне тут квадратный корень, да и деления тоже.
std = sqrt((sqdiff — diff*diff/area)/(area-1));
threshold = mean*(1+k*((std/128)-1));
if(gray_image_ptr[j][i] <= threshold)
bin_image_ptr[j][i] = 0;
else
bin_image_ptr[j][i] = 255;
В результате получилось нечто вообще плохо читаемое и малопонятное, но работало на 30% быстрее. Это была последняя оптимизация — после введения потоков и прочего.
К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далека от задачи "напишите мне красиво и изящно".
S>2. Во-вторых, есть подзадача с рекуррентным определением. Она сулит феерические впечатления при поисках возможности параллелизации.
S>Пока что нахожусь на этапе мучительных поисков синтаксиса.
А мы на этапе ожидания феерических результатов.
Для затравки, кстати — в своем коде я оптимизировал вот этот кусочек. Не понравился мне тут квадратный корень, да и деления тоже.
std = sqrt((sqdiff — diff*diff/area)/(area-1));
threshold = mean*(1+k*((std/128)-1));
if(gray_image_ptr[j][i] <= threshold)
bin_image_ptr[j][i] = 0;
else
bin_image_ptr[j][i] = 255;
В результате получилось нечто вообще плохо читаемое и малопонятное, но работало на 30% быстрее. Это была последняя оптимизация — после введения потоков и прочего.
К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далека от задачи "напишите мне красиво и изящно".
Re[3]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Sinclair, Вы писали:
S>2. Во-вторых, есть подзадача с рекуррентным определением. Она сулит феерические впечатления при поисках возможности параллелизации.
S>Пока что нахожусь на этапе мучительных поисков синтаксиса.
А мы на этапе ожидания феерических результатов.
Для затравки, кстати — в своем коде я оптимизировал вот этот кусочек. Не понравился мне тут квадратный корень, да и деления тоже.
std = sqrt((sqdiff — diff*diff/area)/(area-1));
threshold = mean*(1+k*((std/128)-1));
if(gray_image_ptr[j][i] <= threshold)
bin_image_ptr[j][i] = 0;
else
bin_image_ptr[j][i] = 255;
В результате получилось нечто вообще плохо читаемое и малопонятное, но работало на 30% быстрее. Это была последняя оптимизация — после введения потоков и прочего.
К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далеко от задачи "напишите мне красиво и изящно".
S>2. Во-вторых, есть подзадача с рекуррентным определением. Она сулит феерические впечатления при поисках возможности параллелизации.
S>Пока что нахожусь на этапе мучительных поисков синтаксиса.
А мы на этапе ожидания феерических результатов.
Для затравки, кстати — в своем коде я оптимизировал вот этот кусочек. Не понравился мне тут квадратный корень, да и деления тоже.
std = sqrt((sqdiff — diff*diff/area)/(area-1));
threshold = mean*(1+k*((std/128)-1));
if(gray_image_ptr[j][i] <= threshold)
bin_image_ptr[j][i] = 0;
else
bin_image_ptr[j][i] = 255;
В результате получилось нечто вообще плохо читаемое и малопонятное, но работало на 30% быстрее. Это была последняя оптимизация — после введения потоков и прочего.
К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далеко от задачи "напишите мне красиво и изящно".