Разработка findcolor, findimage, Pure lua Опции

[DarkMaster]

По чтению всмысле в кэш загонит и не выкинет раньше времени. Все парюсь по сколько байт с памяти читается минимально сейчас.

По ветвлению не знаю. Для меня реально загадка, как проц может просчитать ветвления поиска по сути одного дапа рандома в другом дампе рандома еще и паттернами со смещением (y координата). Да касательно имиджа там условно есть за что цеплятся в плане именно оптимизаций, которые сделал в свое время кнайт, вот только беда в том, что эти оптимизации иногда вылетают в трубу и искать приходится влоб (например при ч/б изображении). Теоретически можно даже убрать переход по Y координате и искать линейно, но вот только логика и запоминание результатов может при этом выполнятся реально дольше, чем прямой перебор. Кароче тестить надо. Сейчас это вилами по воде.

[Cockney]

По чтению всмысле в кэш загонит и не выкинет раньше времени. Все парюсь по сколько байт с памяти читается минимально сейчас.

По ветвлению не знаю. Для меня реально загадка, как проц может просчитать ветвления поиска по сути одного дапа рандома в другом дампе рандома еще и паттернами со смещением (y координата). Да касательно имиджа там условно есть за что цеплятся в плане именно оптимизаций, которые сделал в свое время кнайт, вот только беда в том, что эти оптимизации иногда вылетают в трубу и искать приходится влоб (например при ч/б изображении). Теоретически можно даже убрать переход по Y координате и искать линейно, но вот только логика и запоминание результатов может при этом выполнятся реально дольше, чем прямой перебор. Кароче тестить надо. Сейчас это вилами по воде.

предсказание переходов

покажет куда улетает время

[DarkMaster]

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

[Cockney]

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

Ну как бы есть разделение: то что видит компилятор, его задача сделать так, чтобы код был предсказуем по максимуму (тут как он оптимизирует и строит код вообще), и процессор - он в любом случае будет пытаться предсказать куда прыгать, ибо нет у него информации больше.

[Cockney]

Кстати вот че вспомнил. тут можешь смотреть выхлоп разных компилей и время выполнения

https://godbolt.org/

[DarkMaster]

пытаться предсказать

То, что он будет пытаться это понятно. Впорос в том будут ли эти попытки рабочими (IMG:style_emoticons/default/smile.gif)
Спасибо за линки.

[Cockney]

То, что он будет пытаться это понятно. Впорос в том будут ли эти попытки рабочими (IMG:style_emoticons/default/smile.gif)
Спасибо за линки.

Так я же пишу, что чем лучше сгенерирован код и чем больше "удачных" данных, тем лучше результат. например, условно, 2 раза был переход по result[0] < result[1], а 6 раз нет - результат такой себе, кеш предиктора сбит и он вынужден просчитывать переход заново. А вот в ситуации когда все 8 раз был переход по result[0] < result[1] - все супер, следующий прыжок скорее всего будет вытянут из кеша без проверок.

Тут нельзя ничего гарантировать, надо просто программу приводить к минимуму по сложности ветвлений (циклы тоже ветвления)

джит работает по такому же принципу: чем горячее блок кода, тем он больше вероятность реальной компиляции, но только с тем набором аргументов (если мы говорим о функции), которые чаще всего используются

[DarkMaster]

дык

result[0] < result[1]

будет вызван 1 раз, потом смещение по адресам. я об этом и говорю.

Сообщение отредактировал DarkMaster - 4.6.2022, 15:17

[Cockney]

дык

будет вызван 1 раз, потом смещение по адресам. я об этом и говорю.

в цикле - не один

[DarkMaster]

сейчас имеет какое-то значение по производительности использование int/short и double/float? А то помню uint поюзал - скорость в пару раз просела....

[Cockney]

сейчас имеет какое-то значение по производительности использование int/short и double/float? А то помню uint поюзал - скорость в пару раз просела....

Double точно не нужен, а инты должны быть по размеру машинного слова процессора, т.е. либо 32 либо 64. Знаковый тип или нет не имеет значения.

[DarkMaster]

Знаковый тип или нет не имеет значения.

Имеет =)
Там где-то в или в этой теме или в схожей я тесты на типы выкладывал. Там uint оказался намного тормознее чем int и еще что-то не логичное было. Не то short или char оказались такими же, как инт или float оказалося медленее, чем double. Кароче были нежданчики.

Сообщение отредактировал DarkMaster - 5.6.2022, 22:59

[Cockney]

Имеет =)
Там где-то в или в этой теме или в схожей я тесты на типы выкладывал. Там uint оказался намного тормознее чем int и еще что-то не логичное было. Не то short или char оказались такими же, как инт или float оказалося медленее, чем double. Кароче были нежданчики.

в нормальных яп - не имеет

[DarkMaster]

Ты разгадал фишечку accuracy? Если делать полный перебор - тормоз получается. Если каждый раз проверять прошло ли порог совпадений - где-то до 90% accuracy быстрее, меньше - медленнее. У кнайта accuracy вообще не влияет на время выполенения... Полный перебор без ifоф просто счетчиком не сработал.

Сообщение отредактировал DarkMaster - 7.6.2022, 1:05

[Cockney]

Ты разгадал фишечку accuracy? Если делать полный перебор - тормоз получается. Если каждый раз проверять прошло ли порог совпадений - где-то до 70% accuracy быстрее, меньше - медленнее. У кнайта accuracy вообще не влияет на время выполенения... Полный перебор без ifоф просто счетчиком не сработал.

Я и не гадал. Для меня это просто отношение совпавших пикселей к общему кол-ву.

[DarkMaster]

Я и не гадал. Для меня это просто отношение совпавших пикселей к общему кол-ву.

Это конечно гениально) Но суть то в том, что у кнайта это делается как-то странно и шустро на низкой точности.

[Cockney]

Это конечно гениально) Но суть то в том, что у кнайта это делается как-то странно и шустро на низкой точности.

Ну а толку гадать то ? ) Тем более если работает странно, и возможно не всегда

[DarkMaster]

Тем более если работает странно, и возможно не всегда

Ну как бы в том то и дело, что всегда. Кнатовскому аккураси вообще пофиг на всех и вся. Причем это я тестил и много лет назад и на прошлом подходе к имиджам и сейчас. Как часы.

Ну а толку гадать то ?

Повторить хочу. На высокие точности у меня есть шустрый вариант, но забрать скорость на низких я хочу. Пока эксперименты ни к чему не привели.

[Cockney]

Чем меньше точность, тем меньше точек проверяет ? Это предположение.

А вообще я как то с трудом понимаю твои месседжи.

[DarkMaster]

Чем меньше точность, тем меньше точек проверяет ? Это предположение.

Ну у меня это так. И вполне логично от этого меняется время выполнения. Соответственно 99% - пуля, 1% - тормоз. Это логично.
У кнайта это НЕ так. У него время проверки всегда константа. Время выполнения всегда равно примерно 90% точности в моем методе.

Я предположил, что он просто создает некоторый массив счетчиков для каждой точки, а не смотрит if'ы. После прогона просто смотрит на этот массив и выбирает нужные данные. Но при таком подходе у меня получилось все достаточно медленно.

Сообщение отредактировал DarkMaster - 7.6.2022, 2:19