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

[DarkMaster]

Кол-во ядер == кол-во потоков

Считается правильным делать 2x потоков на ядро для оптимальной производительности. Хотя в рамках наших задач (по сути чистая синтетика) может быть иначе.

Неэффективно будет иначе (на каждый поток луа свой пул потоков поиска).

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

посмотри внимательней, в закрепе есть они

В архиве которые что ли? Пилот и вырезка центра пилота?

[Cockney]

Код

findimage_benchmark_Release_x64 --s Big.bmp --i Small.bmp --d 0 --a 50 --sr > benchmark_test.txt

Найдено 0. При 50% должно находится 6 изображений.

вот это

https://forum.uokit.com/index.php?s=&sh...st&p=442963

[DarkMaster]

Ищем зеленый квадрат
Красная рамка - реально заданная область поиска, пиксели будут сравниваться только внутри этой рамки.
Оранжевая рамка - фактическая область по которой пилот будет "двигать" паттерн в поисках совпадений.
Синяя рамка - образей найденого квадрата с низким % точности.

В итоге имидж который мы заставили искать в области 100 100 109 109 возрващает координаты найденного изображения 95 95. Подобные приколы на последней версии пилота должны фильтроваться искуственно после окончания поиска, но сам алгоритм не был исправлен, на сколько мне известно.


посмотрел картинки. а что собственно не так? там 3 картинки с точностю 60%, две картинки с точностью 50% и одна каринка с точностью 100%

Это у меня завались генерированные рандомные картинки - может пригодятся.

[Cockney]

это пилот их так посчитал. я руками пытался и такое не выходит

[DarkMaster]

это пилот их так посчитал. я руками пытался и такое не выходит

Ну вообще я руками посчитал и такой результат получил) Что получал пилот я не знаю, с этими примерами не запускал.

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

[Cockney]

Странно, может я упускаю что

[DarkMaster]

Блин, более менее начал осмысливать твое видение. А как ты решил проблему с кол-вом найденных элементов -1, т.е. искать все что найдешь ? Тут как я вижу работает только если железно знаем сколько найдем.

Кстати с -1 проблемы условно нет, как я уже говорил заведомо большой буфер создать и не выносить мозг. А вот с ограничением N будут вопросы, возможные мьютексы и т.д. Но тут вообще есть очень опасный момент, что если каритнок реально много то в любой многопоточке проверка итогового количества изображений может мьютексами систему колом поставить. Взови миллион блокировок и разблокировок с реальным переключением потоков. Там боюсь проще будет найти все и выкинуть лишние. Вообще синхронизация количества и порядка найденных элементов для меня вопрос не имеющий однозначного ответа. Т.е. проделывая поиск на 10 элементов в области где этих элементов 100, то при многопоточке мы не можем гарантировать их порядок и непрервыность. Имхо в данном случае только передача локальных ограничений в 10 элементов в каждый поток даст фиксированный порядок. Но тут еще встает вопрос, а нужен ли будет этот фиксированный порядок? Вопросы откровенно говоря сложные и имхо очень сильно зависящие от конкретной ситуации и скорее всего подобные инструкции должны быть опциональными.

[cirus]

там 3 картинки с точностю 60%, две картинки с точностью 50% и одна каринка с точностью 100%

Всё верно.

Код

findimage_benchmark_Release_x64 --s BigRed.bmp --i Red.bmp --d 0 --a 100 --sr > benchmark_Red.txt

 ImageTest2.zip ( 850 байт ) Кол-во скачиваний: 76

Найдено 0.
Для теста через пилот нужно закрасить левый верхний пиксель, иначе вернёт -7.

[Cockney]

К слову об оптимизациях c++ компилятора от майкрософт.

Есть функция, в ней примерно такой код:

Код

if (arr[0] != r && arr[1] != b && arr[2] != g) {//....}

Замеряю эту функция профилировщиком. 0,3мс, общее время выполнения программы 29мс. Запомнили ?

теперь меняем в этой функции код на этот:

Код

if (arr[0] != r || arr[1] != b || arr[2] != g) {//....}

Замеряю эту функция профилировщиком. 0,3мс, общее время выполнения программы 390мс.

Отмечу, что время самой функции не меняется, а изменяется общее время работы.
Такое себе не позволяет даже jit самый плохой.

[Cockney]

Всё верно.

А как оно верно может быть. Реально найти только 3, пилот это подтверждает

Код

Найдено изображений: 3
Координаты изображений:
1 - 7 2     % совпадения: 100
2 - 1 3     % совпадения: 66
3 - 9 5     % совпадения: 66

Все остальные изображения либо совпадают менее чем на 50% (левый верхний угол, левый нижний угол), либо являются строкой, которая вообще не найдется, т.к. сверху ничего более нет (правый верхний угол)

Кстати с -1 проблемы условно нет, как я уже говорил заведомо большой буфер создать и не выносить мозг. А вот с ограничением N будут вопросы, возможные мьютексы и т.д. Но тут вообще есть очень опасный момент, что если каритнок реально много то в любой многопоточке проверка итогового количества изображений может мьютексами систему колом поставить. Взови миллион блокировок и разблокировок с реальным переключением потоков. Там боюсь проще будет найти все и выкинуть лишние. Вообще синхронизация количества и порядка найденных элементов для меня вопрос не имеющий однозначного ответа. Т.е. проделывая поиск на 10 элементов в области где этих элементов 100, то при многопоточке мы не можем гарантировать их порядок и непрервыность. Имхо в данном случае только передача локальных ограничений в 10 элементов в каждый поток даст фиксированный порядок. Но тут еще встает вопрос, а нужен ли будет этот фиксированный порядок? Вопросы откровенно говоря сложные и имхо очень сильно зависящие от конкретной ситуации и скорее всего подобные инструкции должны быть опциональными.

А проблема оверлеев ? Когда при низкой точности совпадений находит на одном участке много картинок. Тут нужно выбирать лучшее. Я вообще решил это нахождением всего возможного и потом отбором лучших

[cirus]

пилот это подтверждает

Я бы вообще не брал поиск пилота за эталон.

Реально найти только 3

Дарк же увидел что их 6. В подтверждение (поиск через мою длл):

[Cockney]

Давай возьмем твой за эталон. Как он найдет правое верхнее изображение ? То что куски изображения есть, я не спорю, как они находятся с точки зрения перебора пикселей

судя по отрицательной координате область поиска сдвигается за пределы области поиска ?

[cirus]

Как он найдет правое верхнее изображение ?

Также как все остальные.
Берётся первый пиксель искомого изображения, если такой пиксель найден на большой картинке, то в этом месте ищётся вся искомая картинка.
Если не найдено нужное количество изображений, то берется второй пиксель искомого изображения, снова поиск и т. д.
Правое верхнее изображение найдётся при поиске 6-го пикселя.
Разумеется добавлены проверки чтобы не выйти за пределы массива.

[Cockney]

Также как все остальные.
Берётся первый пиксель искомого изображения, если такой пиксель найден на большой картинке, то в этом месте ищётся вся искомая картинка.
Если не найдено нужное количество изображений, то берется второй пиксель искомого изображения, снова поиск и т. д.
Правое верхнее изображение найдётся при поиске 6-го пикселя.
Разумеется добавлены проверки чтобы не выйти за пределы массива.

странное решение. надо осмыслить.

[DarkMaster]

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

Код

jit.opt.start(
"maxtrace=4000",    --Max. number of traces in the cache
"maxrecord=16000",  --Max. number of recorded IR instructions
"maxirconst=2000",  --Max. number of IR constants of a trace
"maxside=400",      --Max. number of side traces of a root trace
"maxsnap=125",      --Max. number of snapshots for a trace
"hotloop=24",       --Number of iterations to detect a hot loop or hot call
"hotexit=10",       --Number of taken exits to start a side trace
"tryside=4",        --Number of attempts to compile a side trace
"instunroll=4",     --Max. unroll factor for instable loops
"loopunroll=15",    --Max. unroll factor for loop ops in side traces
"callunroll=3",     --Max. unroll factor for pseudo-recursive calls
"recunroll=2",      --Min. unroll factor for true recursion
"sizemcode=256",    --Size of each machine code area in KBytes (Windows: 64K)
"maxmcode=8192")    --Max. total size of all machine code areas in KBytes

Сообщение отредактировал DarkMaster - 30.4.2022, 5:50

[Cockney]

проще, имхо, взять предсказуемый c#, а не подбирать десяток параметров джита.

[DarkMaster]

проще, имхо, взять предсказуемый c#, а не подбирать десяток параметров джита.

Честно говоря беспонятия какой из них сработал или их сочетание. Сделал нативно - сработало. Ну и я уже высказал свое мнение - перебор должен быть на, скажем, си, чтобы не было никаких оглядок на джит и было полное понимание происходящего. Собственно пребор на дллке имхо убирает все проблемы. Осталось побороть лень и дернуть студию чтобы сделать это так, как это нужно именно мне =)

[Cockney]

Ну оно может выстрелить в любом безобидном месте, где думаешь ну не может такого быть здесь.

[DarkMaster]

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

[Cockney]

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

Откуда я знаю ? Смысл в том, что ты искать причины замучаешься, если такая проблема всплывет. Если перечитать беседу, то там вроде начиналось все с вполне регулярного кода, который вопросов не вызывает.

ты предлагаешь вообще луа убрать из пилота что ли?

это уже каждый должен сам решать, я лично бы после подобных фокусов от языка сгорел и выбросил его на помойку (с учетом того, что альтернатив куча). Да и причем тут пилот ? У каждого уже своя реализация пилота по ощущениям, поэтому нет ограничений.