Автокликер Clickermann :: Форум
Основной раздел => Общие вопросы => Topic started by: Hito on August 18, 2018, 10:26:34 AM
-
Ребят, я тут с потоками поигрался (нужда возникла скрипт ускорить) и у меня возник вопрос (может я просто чего-то упускаю) - а для чего вообще в кликермане потоки? Ведь по сути они не являются независимыми потоками и каждый поток стоит в очереди и ждет, пока закончит свой цикл предыдущий поток.
Время выполнения поиска картинки в этих условиях у меня = 400мс
GETSCREEN
COLORMODE(7)
$check_time=$_ms
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
LOGWRITE ($_ms-$check_time)
HALT
А тут у меня это время = 1200мс
THREAD(name1, 0)
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
WAITMS(50)
END_THREAD
THREAD(name2, 0)
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
WAITMS(50)
END_THREAD
GETSCREEN
COLORMODE(7)
$check_time=$_ms
SETTHREAD (name1, 1)
SETTHREAD (name2, 1)
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
LOGWRITE ($_ms-$check_time)
HALT
То есть время работы скрипта в три потока (в которых абсолютно равные условия) увеличилось ровно в три раза. В чем суть потоков? Или я чего-то не понимаю...?
-
ДА
GETSCREEN
COLORMODE(7)
$check_time=$_ms
IF_PICTURE_IN (1041,308, 1192,432, "KRS_10х10.bmp", -1, 90) // Где искать примерно и процент точности размер картинки
END_IF
LOGWRITE ($_ms-$check_time)
HALT
LCLICK(1041,308) // Alt+Q
LCLICK(1191,432) // Alt+Q
1041,308, 1191,432,
поставил бы процент 10 в обще думаю состарился ты. я ниже 80 не ставлю, чаще всего ищу такое место где можно было использовать 90 или 100 процентов
экран сам 1680х1050 = 0,0, $_xmax,$_ymax
зона поиска 1680х1050 картинка 107х106 %точности 50 вышло 432989 7-8минут БОЮСЬ НОВЫЙ ГОД ПРОЙДЕТ да и процессор подгружает не плохо
зона поиска 647х227 картинка 107х106 %точности 50 вышло 18408 замучаюсь ждать
зона поиска 647х227 картинка 20х20 %точности 50 вышло 1091 так себе
зона поиска 647х227 картинка 20х20 %точности 90 вышло 315 пойдет
зона поиска 647х227 картинка 20х20 %точности 100 вышло 98 хорошо
зона поиска 647х227 картинка 10х10 %точности 100 вышло 52 еще лучше
зона поиска 151х124 картинка 10х10 %точности 90 вышло 12 класс
зона поиска 151х124 картинка 10х10 %точности 100 вышло 7 супер
зона поиска 1680х1050 картинка 10х10 %точности 100 вышло 625 хорошо для всего экрана
сам решай что тебе надо
-
Ребят, я тут с потоками поигрался (нужда возникла скрипт ускорить) и у меня возник вопрос (может я просто чего-то упускаю) - а для чего вообще в кликермане потоки? Ведь по сути они не являются независимыми потоками и каждый поток стоит в очереди и ждет, пока закончит свой цикл предыдущий поток.
Потоками ты выполнение не ускоришь. Действия все равно идут по списку но параллельно.
Например есть какой то набор действий и в любой момент может произойти какое то событие. Так вот второй поток, не слишком тормозя первый, может постоянно проверять на это событие, и если оно произошло, остановить первый поток, избавиться от события, и продолжить выполнение первого потока.
Раньше приходилось всовывать в ключевые точки вызов подпрограммы. С потоками все проще стало. Если конечно понимать как их использовать.
-
KingDrakonov, я процент спецом занизил для эксперимента. Копаться между двумя и пятью-шестью мс не охота. Мне в данном посте важно не время, за которое скрипт выполняет операцию поиска картинки, а разница во времени, между двумя скриптами. Я думал, что это будет очевидно...
-
Oraven, не совсем понимаю... Для чего одному потоку контролить какое-то событие и управлять вторым потоком, если проверку на это событие можно установить в основном теле скрипта и дальше действовать исходя из результата...?
-
KingDrakonov, я сейчас твой пост дочитал... Выбрось свой процессор ;D
-
ты свой выбрось проц. мой справляется на ура оперативы маловато уже 6гиг,
сейчас мозал работает открыто 2 окна 54 вкладки, и куча дополнений стоит, и ты говоришь мой проц говно
я с этими скриптами уже неделю мучаюсь пишу для 2х игр одновременно и прочитал здесь кучу всего большинство пролистал
-
а да мне самому было интересно сколько времени пройдет и записал
к с тате как все работало так работает не чего не выключал хотя освободить нагрузку на проц магу другим образом
-
То есть время работы скрипта в три потока (в которых абсолютно равные условия) увеличилось ровно в три раза.
Очевидно, что при большем количестве потоков, комп начинает тормозить. Если исключить из времени теста этот зависон, то видно, что потоки работают правильно.
Нужно по другому организовать сам тест. У тебя после запуска двух потоков нет времени на их выполнение - сразу поиск картинки (нагрузка на проц) и остановка скрипта. Потоки с задержками 50ms просто не успевают отработать. Получается, что ты измеряешь не время работы трех функций IF_PICTURE_IN(), а по большей части время зависания системы.
Немного переделанный скрипт покажет время работы потоков точнее. Задержка в 500ms увеличивает общее время выполнения скрипта, но цель теста не в определении общего времени. Нам нужно узнать чистое время работы функций, а именно трех IF_PICTURE_IN() против одной.
Останавливаем отработавшие потоки - разгружаем проц. Иначе суммарный поиск картинки каждые 25ms, это тяжело (первый то твой скрипт работает без такой нагрузки, по этому и быстрее в 3 раза).
THREAD(name1, 0)
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
// WAITMS(50) // в этом тесте, задержка здесь не нужна
SETTHREAD (name1, 0) // останавливаем отработавший поток - разгружаем процессор
END_THREAD
THREAD(name2, 0)
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
// WAITMS(50)
SETTHREAD (name2, 0) // останавливаем поток
END_THREAD
GETSCREEN
COLORMODE(7)
$check_time=$_ms
SETTHREAD (name1, 1)
SETTHREAD (name2, 1)
WAITMS(500) // без задержки в этом месте, потоки не успевают найти картинки, но успевают вызвать зависон системы
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
// WAITMS(500) // если перенести задержку сюда, то от зависания не избавиться и время увеличится
LOGWRITE ($_ms-$check_time-500) // вычитаем из общего времени время отдыха 500ms
// HALT
Да, еще забыл сказать, что для всех потоков буфер графического анализа общий, он единственный. Тоже надо учитывать иногда.
-
к с тате как все работало так работает не чего не выключал хотя освободить нагрузку на проц магу другим образом
Мазила не только у тебя работает. Только у меня в ней вкладок чуток побольше... А тестировал я на виртуалке (у меня в ней игра просто работает), на которую выделено 2 ядра от всего процессора :) Так что цифры времени поиска картинки, которые я привел в посте, получены в ОДНОЙ ИЗ запущенных виртуалок :) И разрешение экрана у меня не многим меньше твоего - 1440x900.
-
Атеист, чую логику... Домой приеду - потестю...
-
Атеист, я скоро буду дома и вот, что я придумал... Ты говоришь, что идет напруга на процессор из-за отсутствия передышки (в моем варианте). Ок. Сделаем иначе... Запустим не три потока, а три кликера и в каждом абсолютно эденьтичное условие поиска. Вот три кликера точно будут, как три абсолютно независимых потока. И я больше чем уверен, что три кликера справятся с задачей намного быстрее, чем три потока. Функции поиска во всех трех кликерах будут запущенны практически одновременно. Разница будет если, то не более, чем в 10-20 мс.
-
Ну, вот как бы чего и требовалось доказать... Одно и то же условие запущено в трех кликерах одновременно. Трир кликера запускаются заранее и ждут в цикле команду на старт. Четвертым кликером мы даем им эту команду.
Скрипт в трех кликерах:
GETSCREEN
COLORMODE(7)
WHILE(INIREAD("variables.ini", "start", "timer") = 0)
WAITMS(20)
END_CYC
$check_time=INIREAD("variables.ini", "start", "timer")
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "file.bmp", -1, 50)
END_IF
LOGWRITE ($_ms-$check_time)
HALTВо всех трех кликерах код абсолютно одинаковый.
Код в четвертом кликере:
INIWRITE("variables.ini", "start", $_ms, "timer")
HALT
И, как результат:
(http://imglink.ru/pictures/18-08-18/94ee3a698247ddee7dc2198d93fdb2bc.jpg)
И, на сколько я понимаю (если я не прав, то пусть уважаемый Джони меня поправит), "потоки" в кликере реализованы, как таймеры? То есть - они по сути не являются полноценными, независимыми потоками, а динамически создаются в кликере, как таймеры? Просто поведение этих самых "потоков" очень на это похоже... Не знаю - где и как, но в delphi так ведут себя именно таймеры.
-
А моя версия твоего теста какое время показывает?
-
А моя версия твоего теста какое время показывает?
Извини - я даже не пробовал. Просто пока в автобусе возвращался, мне все это в голову пришло и я сразу намутил, как приехал. Просто как бы это все объясняет, что мощность и подвисание процессора тут ни при чем. Три кликера одновременно осуществляют один и тот же поиск и ничего не виснет и выполняется в три раза быстрее, чем три потока в одном кликере. Это говорит о том, что эти потоки все же просто ждут друг друга. А если это так, то я возвращаюсь к своему вопросу - для чего в кликере эти потоки...?
-
А моя версия твоего теста какое время показывает?
2900мс
-
Чето много. У меня это время почти такое же, как для одного потока.
А HALT закомментирован? Это среднее время, или эффект первой итерации вмешался?
-
Чето много. У меня это время почти такое же, как для одного потока.
А HALT закомментирован? Это среднее время, или эффект первой итерации вмешался?
Среднее время. HALT не разлочивал - скопировал код и вставил, как был.
-
У тебя все таки три независимых приложения, и как распределяет ресурсы между ними Windows я не в курсе. Могу только предположить, что у винды есть свои средства оптимизации на этот случай, которые могут быть эффективней оптимизаций работающих внутри процесса Clickermann.exe.
Но потоки в КМ заявлены как независимые.
UPD: Еще раз проверил у себя твой первый скрипт для одного потока и мою версию для трех потоков - время абсолютно одинаковое. За исключением 500ms, которые как бы в зачет не идут. При этом все 3 потока успевают сработать. Потоки вещь! :)
-
Но потоки в КМ заявлены как независимые.
Я просто знаю, как в delphi ведут себя независимые потоки. Начну с того, что я долго изучал эти потоки прежде, чем я написал первый. Это реально геморой для тех, кто это дело только осваивает. А про передачу переменных из тела основного скрипта в потоки я вообще промолчу... А если учесть, что при создании нового потока в скрипте кликера, настоящий поток в самом кликере еще должен создаться и динамически - это жопа... А если учесть, что этот - динамически созданный поток, еще и должен работать с компонентом TImage (чтобы онализировать картинку, которую кликер помещает в этот компонент), который находится на основной панели кликера и скрыт от наших глаз - это жопа в жопе... Я думаю, что уважаемый Джони просто бросил бы кликерман, если начал бы все это реализовывать ))
-
Я думаю, что уважаемый Джони просто бросил бы кликерман, если начал бы все это реализовывать ))
В том и прикол, что реализовал же таки. Прикинь, да? Мощь! :)
-
Я думаю, что уважаемый Джони просто бросил бы кликерман, если начал бы все это реализовывать ))
В том и прикол, что реализовал же таки. Прикинь, да? Мощь! :)
Ну... Благодаря сегодняшним тестам, я все же склоняюсь к тому, что эти псевдопотоки в кликермане реализованы, как таймеры...
-
Ну, раз вопрос был задан, то это не таймеры как потоки, а потоки как таймеры.
Они действительно не независимы* хотя бы потому, что работают с одной областью памяти. А именно переменными, гр.буфером и прочим. Следовательно нужны прерывания, поэтому потоки в КМ это не про быстродействие, это про распараллеливание. Заморочиться можно и сделать ТРУ потоки, но не в линейке 4.х. Там надо менять подход и синтаксис.
Насколько я помню примеры примитивных задач, которые адекватно можно решить ТОЛЬКО через [псевдо]потоки были мной приведены в поясняющей статье.
Должен работать с компонентом TImage (чтобы онализировать картинку, которую кликер помещает в этот компонент), который находится на основной панели кликера и скрыт от наших глаз
Здесь орнул)))
* не независимы полностью, но в ряде случаев могут выполняться параллельно не мешая друг другу
-
Здесь орнул)))
Прости - я не понимаю слова - орнул )) Что оно означает? В смысле - я ошибся? Допускаю ) Ты мог сделать и без TImage. Держать в рабочей памяти TBitmap и работать с ним. Заморочестей конечно - каждый раз высвобождать память и все такое, но за то качественней. Но... Тогда мне еще больше не понятно. Если бы эти потоки были настоящими потоками, то зачем им всем работать с одним буфером для онализа. Тот Bitmap каждый поток мог бы создавать сам для себя и работать каждый со своим буфером. Только пойми меня правильно - я ни в коем случае не хочу как-то поставить под вопрос твою работу. Я уже который год пользуюсь этим кликером и не перестаю ему удивляться. Более того - именно с него началось когда-то мое программирование.
-
Ну... Ладно... Может я и полез уже не туда. Если что - прости, Джонни...
-
Прости - я не понимаю слова - орнул )) Что оно означает?
LOL 2.0
меня просто позабавило само предположение, что у нас могут быть ТАКИЕ архитектурные ходы... а второй TImage, стало быть, прячется уже на окне редактора со свойствой visible = false))
нет, у нас давно все на динамическом управлении памятью, за рамки которой мы периодически выпрыгиваем, ломая все и вся
Если бы эти потоки были настоящими потоками, то зачем им всем работать с одним буфером для онализа.
не только одним буфером, но и одним пространством имен переменных. причем если по поводу первого можно еще поспорить, то преимущества второго весьма очевидны. тот же один поток, который через флаги управляет пятью другими.
не ломая синтаксис и не пугая народ, текущее решение ИМХО оптимально. в конце концов, монитор у пользователя то один.
потоки делались не сколько как потоки, сколько как решение для тех, кто запускает по десять копий кликера для распараллеливания задач.
-
стало быть, прячется уже на окне редактора со свойствой visible = false))
Просто я именно так когда-то и делал ;D
тот же один поток, который через флаги управляет пятью другими.
Вот про это, во всех своих корявых предположениях, я совсем и забыл... Да - там жопа в жопе и жопой прикрыта...
Ну, в общем-то что я могу сказать... Если бы я не был верующим, я бы сейчас тебе поклонился )
-
Господь - программист, которому я просто поклоняюсь... )
https://www.youtube.com/watch?v=OstmdJ_yuT0&t=4s (https://www.youtube.com/watch?v=OstmdJ_yuT0&t=4s)