Помогите освоить LUA Опции

[sutra]

Ну никак я не ожидал, что элементарнейшие, БАЗОВЫЕ операторы цикла и сравнения, которым я не знаю сколько лет, настолько криво реализованы. Видимо пора завязывать со всем этим.

Попробую ещё с массивами почудить, уберу двойной индекс. Возможно у lua просто не хватает мозгов, на мои столь "сложные и заумные" (IMG:style_emoticons/default/ohmy.gif) алгоритмы. Хотя выбор очередности анализа каналов в данном случае даёт более, чем двукратный прирост скорости.

[DarkMaster]

Есть у меня теория, что обращение os.clock() в середине может портить эксперимент. Почти как кот шредингера =)

[sutra]

Есть у меня теория, что обращение os.clock() в середине может портить эксперимент. Почти как кот шредингера =)

ХА-ХА!! Не поверишь, внутренний цикл переделал на FOR - ВСЁ ХОККЕЙ!! Вывод, не надо злоупотр<вырезано анти-матом>ть ... больше 2-х не собираться ... чередовать их надо форы вайлы и репитами разбавлять, чтобы мозг у ЛУА начал "кипеть".

И клок - это просто в примере. Там тормозило при ПЕРВОМ вызове. А второй вызов - это я случайно обнаружил, что мозг у ЛУА просыпается в таком случае.

Так что это просто с циклами всё очень непросто, надо смотреть и проверять. Видимо на 3-ем и больших вложениях очень хитрая оптимизация при компиляции.

Короче обошёл этот косяк. Спасибо Дарк за терпение, что возишься со мной. Ну ничего, тебе для опыта тоже не повредит.

Можешь сам проверить, замени внутренний вайл на это for i=1,pic[0][0]do
и добавь break

Ну и инкремент индекса убери.

Ну вроде ВСЁ. Есть у меня ещё заготовка поиска по разности каналов, чтобы искать прицелы, меняющие цвет, объекты (день ночь). Могу и её прикрутить. Только вроде это всё никому неинтересно, так что не знаю, стоит ли этим заниматься.

Ну вот, все мишени (находит 6 штук) на 1920х1080 ищутся за 25 сотых на моём камушке, а если я ручками картинку за 1 минуту подрихтую, то менее 1 сотой секунды, вполне неплохо!

[sutra]

На низком уровне, думаю будет мгновенно. Там все инкременты на битовом уровне, кроме ИФ-ов ничего не делается, а они тоже быстро отрабатываются, ежели конечно не заставить компилятор обрабатывать все условия. Но низкий уровень я сам не осилю, мозги уже не те.

[sutra]

Всем ещё раз спасибо! Вам троим Гуру, не считая Кнайта моя стряпня не нужна, вы всё dll-ками можете сделать. Остальные на Пилотовском работают. Ну если кому понадобятся финды под lua, скажут.

[sutra]

Да, теперь все сомнения отпали. Нашёл ещё один случай тормозов, в совершенно простейшем и прямолинейном коде, при выполнении 3-х форов, один внутри другого. Только вот у меня какая штука произошла. Я просто укоротил имена переменных и получил падение скорости в 4 раза. Так что НЕ НУЖНО их делать короче. Да, чем длиннее имя, тем вроде как больше требует памяти, но видимо есть какая-то хитрая индексация этих имён, которая приводит к падению скорости. В общем я не знаю как всё реализовано, но факт на лицо. Может конечно просто совпадение случайных факторов. Короче, коллеги - глядите в "ОБА", костыль можно схлопотать на "ровном месте".

И что самое коварное ... вот на последнем найденном мной костыле. Нормальная скорость - 6 тысячных секунды, а тормозная - 24 сотых. Вот и отлови эти 24 сотых, по факту вроде одно и то же, а если надо будет это выполнить 1000 раз? 6 и 24 секунды, вот такой получится якорь.

По логике, получается, что надо избегать "однотипных" с точки зрения ЛУАшного компилятора действий. Поэтому, как я понимаю из личного опыта, надо давать уникальные имена переменным, варьировать типы циклов, короче "запудрить мозги" компилятору и тогда он делает всё как надо, в противном случае он включит свой мозг и не факт, что будет лучше, причём на какие-то проценты, а вот затормозить может и в 100 раз.

[DarkMaster]

Да, чем длиннее имя, тем вроде как больше требует памяти, но видимо есть какая-то хитрая индексация этих имён, которая приводит к падению скорости.

Все переменные - это часть таблицы в представлении луа. Порядок их хранения не регламентируется. Т.е. если у нас есть две переменные:
a
b
И b расположена первой, то к ней будет обращение быстрее. Но если:
bbbbbbbbbbbbbbbbb
a
будет расположение таким образом, то работать будет быстрее bbbbbbbbbbbbbbbbb.

[sutra]

Порядок их хранения не регламентируется

А есть способ определения порядкового номера элемента таблицы, то есть? я могу определить что например элемент B имеет порядковый номер 2 в таблице {G=12,B=7,R=59} ?

[DarkMaster]

А есть способ определения порядкового номера элемента таблицы, то есть?

Подозреваю, что можно попробовать для этого использовать next или pairs(обертка над next бессмысленная). Тем не менее это тоже не регламентировано, но может и сработать.
Чтобы избежат плясок может быть выгоднее использовать массив с цифровыми ключами - тогда их порядок жестко регламентирован и является по сути единым куском памяти, т.е. классический массив, который можно перебирать чтением памяти по указателю со смещением. Чтобы было проще задавать параметры - имхо лучше задавать таблицей, а при входе в функцию переформировывать в массив.

Сообщение отредактировал DarkMaster - 25.2.2019, 10:32

[sutra]

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

pairs перебирает в том порядке, в каком оно легло в память. Кстати, как оно туда ложится, логики я не понял. Интересная мысль с переформированием, надо попробовать, вот только опять лишние телодвижения получаются и будет ли выигрыш перед вариантом, если задавать параметры строкой. Я плохо понимаю таблицы, наверняка можно в таблицу впихнуть уже готовую функцию, которая бы упростила обработку. Мысль то простая. Если задано ДВА параметра, то должно выполняться ДВА действия ... задано ШЕСТЬ, должно выполняться ШЕСТЬ, желательно в том порядке, в каком заданы параметры. Вот только алгоритма без нагромождений и лишних вычислений никак не могу придумать.

[sutra]

Я тут запихнул возможность поиска картинки вообще в любых комбинациях RGB. Получается как бы работает findcolor внутри. То есть можно искать абсолютно что угодно, вот и хотел ускорить до максимума обработку, в принципе получилось, но приходится тащить балластом ещё темповый массивчик из 6 значений. В общем да, если перекрутить перед поиском параметры, можно и порядок поиска задать.

[sutra]

Ха. Никак не сделать порядок обработки. Как я пойму какой параметр обрабатывать первым??? Либо отдельным параметром тащить порядок, либо задавать строкой, как я раньше делал. Или вы подскажете как иначе можно это сделать.

А порядок обработки ОДНОЗНАЧНО нужен. Тот же прицел и те же мишени, если искать в приоритете каналом RED - намного быстрее. В общем lua типа гибкий, но на поверку не такой уж и гибкий. Конечно можно всё сделать по-колхозному, но хотелось бы по уму. Ну или у меня ума не хватает для реализации задуманного.

Самый простой и быстрый способ задавать ВСЕ параметры, типа {nil,nil,15,20,nil,nil}, но получается громоздко и некрасиво.

[sutra]

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

А с практической точки зрения, вся эта универсальность обходится серьёзными тормозами. Я бы для конкретной игры, просто сделал бы свою функцию. И те же мишени искались бы несопоставимо быстрее, достаточно было бы анализа разности каналов RED-GREEN.

[rinat84]

А может кто научит как dll-ку подцепить написанную на Делфи,

держи пример плагина для lua  delphi_lazarus_lua.7z ( 107,63 килобайт ) Кол-во скачиваний: 72

испытал на delphi 5-7 и на lazarus 2.0 собирается. других версии delhi нет в наличии. (IMG:style_emoticons/default/smile.gif)

[sutra]

держи пример плагина для lua

Спасибо большое, попробую.

[xolost]

Офигеть сколько тут всего добавилось, просто охренеть))
Приветы всем! Кнайт, Дарк! Здрасте Господа!

[DarkMaster]

С возвращением =)

[sutra]

Дарк, я тут чисто для себя решил сделать мини-функцию. Взял уже готовую универсальную основу. Выкинул из неё кучу операторов. ИФ-ов стало меньше в 2 раза и математики тоже поменьше, и выделение памяти под массивы меньше, а результат по скорости упал на 25%. Стал искать методом исключения причину. А причина вот какая. Вот так: d1,d2=ffi.new("int16_t"),ffi.new("int16_t") - медленно. Переделал: d=ffi.new("int16_t[2]") - стало на 50% быстрее. Надо ещё попробовать посмотреть всё внимательно. Короче, проверять надо всё, если требуется скорость.

Получается что с массивом адресация получилась быстрее, вот только не факт, что это всегда быстрее.

[DarkMaster]

Я предупреждал, что там лучше массивы использовать, т.к. в противном случае там очень странное поведение при переполнении. Массив кстати можно и на 1 элемент создать.

[KaZaK]

Доброго!
Подскажите, findcolor для LUA есть вариант функции?