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

[DarkMaster]

Именно дотошно - это скорее даже минус моей натуры

Мне слишком хорошо знакомы эти грабли. Это немаловажная причина, почему я стараюсь помочь вам и почему надеюсь на реализацию от вас (не в обиду кнайту ни коем образом). Я знаю по себе, что если такой человек берется за какое-то дело то, если это дело будет доведено до конца, то это на века. Очень мало у кого хватает желания и возможности писать подобным образом. Все бы так писали компы бы не меняли десятилетиями - ибо летало бы.

[sutra]

Код

local function FindMemRGB(addr,len,scrX1,scrY1,fx1,fy1,fx2,fy2,usl,numf)         -- ПОИСК ПИКСЕЛЕЙ ПО ЗНАЧЕНИЯМ RGB В ОБЛАСТИ ПАМЯТИ
-- addr,len : адрес в памяти, длина строки в памяти (то, что даёт getimage)
-- scrX1,scrY1 : координаты верхнего левого угла образа в памяти, должны быть аналогичны координатам getimage
-- fx1,fy1,fx2,fy2 : координаты поиска пикселей, абсолютные относительно рабочего окна. Должны быть внутри диапазона координат образа в памяти.
-- usl : ОДНО строковое условие поиска "R(10-255) G(70-100) B(50) R-G[50-150] R-B[-40 -20] G-B[15]". R-G,R-B,G-B - разность между каналами; G-B[15] идентично G-B[15 255]
-- numf : максимальное количество искомых пикселей
  local arr=ffi.new("xyrgb[?]",math.min(numf,(fx2-fx1+1)*(fy2-fy1+1)))
  numf=numf-1
  local r1,r2=usl:match("R%((%d+)%-*(%d*)")
  local g1,g2=usl:match("G%((%d+)%-*(%d*)")
  local b1,b2=usl:match("B%((%d+)%-*(%d*)")
  local rg1,rg2=usl:match("R%-G%[(%-*%d+)%s*(%-*%d*)")
  local rb1,rb2=usl:match("R%-B%[(%-*%d+)%s*(%-*%d*)")
  local gb1,gb2=usl:match("G%-B%[(%-*%d+)%s*(%-*%d*)")
  local r,g,b,R1,R2,G1,G2,B1,B2=ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t"),ffi.new("uint8_t")
  local  P,D,R,G,B,RG,RB,GB,k,i,j,indY,RG1,RG2,RB1,RB2,GB1,GB2=true,true,true,true,true,t
rue,true,true,-1,fy1
  if r1~=nil then
    P,R=false,false  R1=tonumber(r1)
    if r2=="" then  R2=R1  else  R2=tonumber(r2)  end
  end
  if g1~=nil then
    P,G=false,false  G1=tonumber(g1)
    if g2=="" then  G2=G1  else  G2=tonumber(g2)  end
  end
  if b1~=nil then  B=true
    P,B=false,false  B1=tonumber(b1)
    if b2=="" then  B2=B1  else  B2=tonumber(b2)  end
  end
  if rg1~=nil then
    D,RG=false,false  RG1=tonumber(rg1)
    if rg2=="" then  RG2=255  else  RG2=tonumber(rg2)  end
  end
  if rb1~=nil then  RB=true
    D,RB=false,false  RB1=tonumber(rb1)
    if rb2=="" then  RB2=255  else  RB2=tonumber(rb2)  end
  end
  if gb1~=nil then  GB=true
    D,GB=false,false  GB1=tonumber(gb1)
    if gb2=="" then  GB2=255  else  GB2=tonumber(gb2)  end
  end
  while i<=fy2 do
    indY,j=addr+(i-scrY1)*len+(fx1-scrX1)*3,fx1
    while j<=fx2 do
      b=rmem("unsigned char*",indY)[0]
      g=rmem("unsigned char*",indY)[1]
      r=rmem("unsigned char*",indY)[2]
      if(D or((RG or r-g>=RG1 and r-g<=RG2)and(RB or r-b>=RB1 and r-b<=RB2)and(GB or g-b>=GB1 and g-b<=GB2)))and(P or((R or r>=R1 and r<=R2)and(G or g>=G1 and g<=G2)and(B or b>=B1 and b<=B2)))then
        k=k+1 arr[k].x,arr[k].y,arr[k].red,arr[k].green,arr[k].blue=j,i,r,g,b
        if numf==k then return k,arr  end
      end
      j,indY=j+1,indY+3
    end
    i=i+1
  end
  return k,arr
end----------------------------------------------------------------------------

Если ошибок не найду, то это конечный вариант. Как ещё ускорить я не знаю. Выкинул всё лишнее из чернового варианта, добавил чутка для ускорения, получилось примерно в 2-3 раза быстрее. Не стал делать таблицу для задания параметров. Мне так удобней и привычнее. Поменять на таблицу при желании не сложно, если планируется крутить в огромных циклах критичных ко времени выполнения.

В идеале конечно сделать бы приоритет сравнений, но я не знаю как это сделать, но путём введения доп. переменных типа boolean удалось свести к минимуму потери на условии анализа.

[DarkMaster]

Как ещё ускорить я не знаю.

https://github.com/torch/cutorch
https://github.com/torch/threads
В зависимости от ситуации. Первый вариант может добавить два нолика (при условии большой площади), второй вариант раз в 5 поднимет.

[sutra]

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

При нулевом опыте я могу только на примерах учиться более менее быстро. А с нуля - это очень долго. Я так понимаю ты имел ввиду писАть на чистом СИ?

В теории конечно второй вариант для меня бы очень даже подошёл, но слишком сложно для меня. Спасибо Дарк, что указал мне на моё место, под солнцем места уже заняты, так что я уж как-нибудь в тени ... (IMG:style_emoticons/default/biggrin.gif)

[DarkMaster]

писать на луа. Там лежат исходники либ для многопоточности (твои 6 ядер начнут работать все, а не только одно), и либа для использования cuda, т.е. обсчитывать это видюхой. На самом деле для видюхи это практически идеальная задача с максимальным приростом. Самые большие задержки будут при копировании изображения в память видюхи.
Многопоточность на ЦП и на Cuda можно сравнить, как автомобиль с несколькими пассажирами (цпу и ядра) и большой автобус-гармошку (едет медленнее, но ядер совсем много).

[sutra]

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

[sutra]

Подправил чистовой вариант (почему то строка одна там теперь съезжает). Была неточность в объявлении переменных. Слегка оптимизировал по скорости внутренний цикл. Поменял приоритет, ну и мелкая косметика. По сравнению с черновым вариантом скорость выше от 2,3 до 4,6 раза.

[sutra]

Конечно пока статистики маловато, но теперь обычно пробую оба варианта кодирования. И пока наблюдается такая закономерность, если не использовать внутри цикла оператор сравнения, то for работает однозначно шустрее чем while. В общем для себя пока закрепил такую модель, если использую if - перехожу на while.

Дарк, теперь по поводу "модуль не найден". Знаешь, я случайно забыл поставить увеличение индекса в вайле i=i+1 (тупо пробовал переход с фора) и получил такую вот ошибочку. Так что она не факт, что означает поиск модуля, косяк может быть какой угодно.

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

[sutra]

Допилил (без использования cuda) поиск картинок, прибавка в скорости приличная, потестирую всё ещё поподробнее, выложу код. Пока могу сказать только одно, на больших циклах влияет абсолютно всё. Даже такая мелочь в операторе сравнения как <= или просто < .

[DarkMaster]

Вы не представляете с каким интересом я слежу за вашими отчтами о том, что влияет на производительность. Тема получилась кладезь для меня =)

[sutra]

Тема получилась кладезь для меня

Так и для меня тоже. Но не было бы твоих мыслей - не было бы и темы. Что я могу? Только тестировать, ну немножко думать. Достоинство одно, я не кладу себе в кошелёк, а делаю достоянием всех. Но это наверное потому, что я уже стар и мне ничего уже не надо.

[DarkMaster]

А чтение памяти вместо временных переменных не пробовали? В самом теле цикла в частности.

[sutra]

Лично для меня теперь сакральным является число 56, которое обнаружил Сайрус. Я рассказал более опытным своим коллегам про это - они в шоке. Думаю будут новые анекдоты про число 56 и чем же оно отличается от 57. (IMG:style_emoticons/default/biggrin.gif) (IMG:style_emoticons/default/biggrin.gif)

А чтение памяти вместо временных переменных не пробовали

Да, конечно, именно так теперь и делаю.


Устал уже, не хочу опять лохануться, завтра покажу код, ничего там особенного нет. Но в простоте - сила.

rmem("unsigned char*",indg)[t]-rmem("unsigned char*",indl)[t]
теперь примерно так.

Влияет ВСЁ. Задача - свести к минимуму все операнды.

Даже тип переменных - на второй план.

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

Пока опять могу сказать одно. Думал про аккуратность. Но лично у меня всё ищется на ура, ОЧЕНЬ быстро. Можно лопатить 10 тысяч картинок, ну куда больше? Тут вопрос остаётся старым, сделать универсальную вещь или плюнуть и решить вопрос количеством картинок.

Скажем так. Проще сделать количеством картинок, всё равно будет всё мгновенно (менее 10 тысячных). Если работать на юзера - это твой вариант (не мой). То надо понимать, что любой оператор вызовет неизбежные тормоза, группа операторов - неизбежные тормоза. Поэтому надо понимать задачу. Я решал свою. Глобальную - решит Кнайт. Я верю - он сделает компиляцию и все проблемы по скорости останутся в прошлом.

[DarkMaster]

решить вопрос количеством картинок.

Когда их две - да. Когда 10, тоже да, но будет не приятно, когда окажется, что нужно было 11 и ночью скрипт встал. Когда их будет 100-200-300, то каждое утро будете находить новые картинки и добавлять их. Это начнет утомлять и скрипт станет отказоустойчивым со всеми возможными перезпусками подвисаний. А потом настанет понимание того, что все это было мелочами, когда картинки из-за схожести и количества начнут давать ложные срабатывания =) Печальная это история была)

[sutra]

то каждое утро будете находить новые картинки и добавлять их

Согласен - утомляет. Идеал - иллюзия. Поиск идеала - бесконечность. Отказ от поиска - смерть или инфантильность. Есть факты, есть действительность, есть локальные решения и пока мы не стали роботами решения будем выбирать МЫ. Что мешает сочетать алгоритмы? Нашло в стандартном исполнении - всё нормуль. Не нашло, включаем искусственный интеллект.


И ты, Дарк, не вник в один из моих предыдущих постов. Сглаживание шрифтов писали не роботы, а люди, я не считаю, что они умнее меня, если я понял их алгоритм. Надо понять и вопросы будут решены. Алгоритм вычисляется. Можно и аккуратностью играть. Вопрос? Встраивать в БАЗОВЫЙ алгоритм или написать надстройку? Ведь нужно всё-таки разделить два действия: собственно поиск реальной картинки или поиск угадывания символа, возможно и даже я считаю нужно учитывать этот фактор.

Лет через 20 вопрос будет не актуальным, будет искать всё и всегда, но эти 20 лет были бы невозможны, если бы 30 лет назад мы не придумали компьютер, и + ещё 15-20 лет - калькулятор, и плюс ещё N лет - арифмометр ... логарифмическую линейку, таблицы Брадиса и т.д.

[sutra]

Вот ведь прикол. Вопрос про камеру - уже более 2 тыс. просмотров, вопросы иного плана, в данной теме - видимо не так интересны. У меня вопрос ... ... Ответ, надо быть ближе к людям и они потянутся к нам.

Слово "Камера", "Сэлфи", как магнит притягивает неокрепшие умы... Интересно, что ассоциируется у нового поколения со словами: "Колыма", "Магадан"...

[sutra]

Одел на уши свои любимые наушники, Байеры t5p. Набрал в инете t5p и чуть не упал, 85 тысяч. Куда мы катимся, где НАШИ уши ... Как всё изменилось ...

Кстати, всё, что пишут про кабель - абсолютная правда. Тыщу лет стоит другой кабель.

[sutra]

и ночью скрипт встал

Дарк, не встаёт, просто идентифицирует нераспознанное событие. Фиксирую, помещая в нужный каталог нужные картинки, затем моя внешняя прога (которая джипеги отрабатывает (до сих пор быстро и чётко, хоть тысячи нераспознанных) обрабатывает новые условия и т.д. Спустя какое-то время таких ситуаций не возникает. Сейчас 15-20 тысячных секунды, при максимум 7 (обычно и 2-х не бывает) вариантов картинок. С новым инструментом хоть 10 тыс. картинок будет обрабатываться мгновенно , завтра выложу тесты ... Предварительно - мгновенно. Менее 5 тыс. секунды. И вообще скрипт недолжен вставать. Если есть риск остановки и скрипт "встал" ... Значит устали и мозги.

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

А никто не обещал, что при переходе от социализма к коммунизму нечего будет жрать, в пути кормить никто не обещал. Вопросов быть не должно, скрипт должен быть неубиенным, какой он у меня и есть, ещё и с анализом времени возникновения ошибок. Любая ошибка скринится, время обработки ошибок увеличивается, чтобы не скринить ошибки бесконечно и не "засрать" мой солид (винт), в общем всё всегда под полным и тотальным контролем... Только так и не иначе путь проложим мы к удаче!


Я даже поклонюсь Кнайту. Я бывает такое делаю ... всё должно умереть давно. А параллельный скрипт в игре - играет, хотя уже Пилот давно умер и только перезагруз спасает.

[sutra]

Я использую Пилот,
Может он, что я не смог.
Делает он всё точно,
То, на что он и заточен.

Я лишь только наблюдаю,
Что игрушка не лагает.
Остаётся поклониться,
Удивиться, восхититься.

Дарк - он тоже лепту внёс,
Человеческий понос ...
Выслушать ведь тоже надо
Не надеясь на награду.

Всем удачи и терпенья,
В 19-ом году везенья!
Чтобы всё всегда играло,
Конкурентов опускало.

[DarkMaster]

Можно и аккуратностью играть. Вопрос? Встраивать в БАЗОВЫЙ алгоритм или написать надстройку?

Я считаю это должно быть форком, и в этом форке уже встравивать в базовый. При таком подходе никто не отберет скорость базового, при этом появится полноценный комбайн. Ну будет там не 1, а 2 функции подгружаться, ничего в этом страшного нет.

Дарк, не встаёт, просто идентифицирует нераспознанное событие.

Сначала встает, а потом когда у программиста приходит осознание, что это стабильно работать не будет, начинает "идентифицировать" =)