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

S>Ну, это можно оставить на потом. Ну, там, заменит diff/area на уже посчитанный mean; заменить деление на area-1 на area, т.к. в интересующих нас случаях эффект пренебрежимо мал (полпроцента для w=15 и меньше 0.1% для w=25).

Там существенно сложнее. Там были алгебраические преобразования, в результате которых не осталось ни sqrt, ни деления.
И эффект был совсем не пренебрежимо мал, иначе я бы это все выкинул, как выкинул многое другое, что пробовал и что эффекта не дало.

PD>>В результате получилось нечто вообще плохо читаемое и малопонятное, но работало на 30% быстрее. Это была последняя оптимизация — после введения потоков и прочего.
S>Ну, после Кармаковского кода меня трудно таким удивить.

А это не было предназначено для того, чтобы удивить. Это было сделано с одной целью — выжать все, что можно. Кстати, это преобразование никакой компилятор сделать не сможет, потому что там фактически изменен алгоритм, хотя математически он и эквивалентен прежнему.

PD>>К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далеко от задачи "напишите мне красиво и изящно".
S>Так не может быть Хорошее инженерное решение — всегда красиво.

Ты когда-нибудь отлаживал релизный код Visual Studio на C++ ? Это когда баг в Dеbug найти не удается (или он там почему-то не проявляется), и остается дебажить Release. Задача не для слабонервных. Исходники есть, вот только они соотносятся с машинным кодом совершенно непонятно как. Для Debug машинный код вполне соответствует тому, что на С++, а для Release — темный лес, все настолько оптимизировано, что пойди пойми. Совсем некрасиво. Зато быстро

S>Ладно, отложим это до момента, когда будет что предъявить

Ok. Жду 200-300 мсек.

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

S>Ну, это можно оставить на потом. Ну, там, заменит diff/area на уже посчитанный mean; заменить деление на area-1 на area, т.к. в интересующих нас случаях эффект пренебрежимо мал (полпроцента для w=15 и меньше 0.1% для w=25).

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

PD>>В результате получилось нечто вообще плохо читаемое и малопонятное, но работало на 30% быстрее. Это была последняя оптимизация — после введения потоков и прочего.
S>Ну, после Кармаковского кода меня трудно таким удивить.

А это не было предназначено для того, чтобы удивить. Это было сделано с одной целью — выжать все, что можно. Кстати, это преобразование никакой компилятор сделать не сможет, потому что там фактически изменен алгоритм, хотя математически он и эквивалентен прежнему.

PD>>К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далеко от задачи "напишите мне красиво и изящно".
S>Так не может быть Хорошее инженерное решение — всегда красиво.

Ты когда-нибудь отлаживал релизный код Visual Studio на C++ ? Это когда баг в Dеbug найти не удается (или он там почему-то не проявляется), и остается дебажить Release. Задача не для слабонервных. Исходники есть, вот только они соотносятся с машинным кодом совершенно непонятно как. Для Debug машинный код вполне соответствует тому, что на С++, а для Release — темный лес, все настолько оптимизировано, что пойди пойми. Совсем некрасиво. Зато быстро

S>Ладно, отложим это до момента, когда будет что предъявить

Ok. Жду 200-300 мсек.