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

[DarkMaster]

Код

local ffi      = require "ffi" -- в шапку.

local params = ffi.new("uint8_t[10]")
params[0] = 11
params[1] = 5
params[2] = params[0] + params[1]
log (params[2])

Создаем массив на 10 элементов по 8 бит.
Обратите внимание на изменившийся require. Раньше мы только часть ffi подключали, теперь весь.

fast/least не понимает. С оптимальным размером по поводу производительности нужно тестить. Весьма возможно, что это окажется не 8 бит, даже если будем сравнивать с 8 битами.

Сообщение отредактировал DarkMaster - 17.11.2018, 21:58

[sutra]

Тут прямо напрашивается, чтобы r1, g1, b1 и т.д. были сишными

Да сомнений нет, что чисто СИ-шный код (да хоть и паскалевский) всё это должен делать мгновенно. Я 30 лет назад ворочал эти массивы без всяких тормозов.

[DarkMaster]

Зависит от перераспределения памяти при обработке таблиц, за один оператор сразу выделяет памяти сколько надо, тормоза (как я понял) зависят именно от этого. Я ж чую уже эти таблицы.

Они unordered. Т.е. это не цельный кусок памяти, как в массиве. Там каждый элемент находится где угодно и поэтому удаление или добавление элемента не приводит к перестроению всей таблицы. Ключи скорее всего перестраивает при удалении, но не более того. А вот если индекс задан числом, то это в чистом виде массив единым куском памяти.

[sutra]

В любом случае, "внешних" функций нет и результат на лицо, конечно если "вылизать" получится супер-пупер!

Но без вашей помощи мне не вылизать.

[DarkMaster]

params[0] - это ваши r1, r2 и т.д.
Тут подставить по сути осталось =)

[sutra]

Ключи скорее всего перестраивает при удалении

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

[sutra]

params[0] - это ваши r1, r2 и т.д.

Эх, Дарк, у меня жесткий иммунитет, ежели нет понятия, то только на "неживых" данных, только на виртуалке. Это дети и внуки жмут не глядя, а меня воспитывали "в страхе". 7 раз отмерь - 1 отрежь. Лучше уж на конкретном примере покажешь и то не факт, что я пойму. Так это уже не так страшно, тупо скопирую без понятия и тупо буду пользоваться.

[DarkMaster]

local rmem = require "ffi".cast
это из тела функции лучше вынести в самый верх скрипта.

Код

local ffi      = require "ffi" -- в шапку.



function FindRGB(addr,len,scrX1,scrY1,fx1,fy1,fx2,fy2,usl,numf)                                  -- Функция поиска RGB в области памяти
  -- addr,len : адрес в памяти и длина строки в памяти (те, что даёт getimage)
  -- scrX1,scrY1 : координаты верхнего левого угла скрина в памяти, аналогичны координатам getimage (конечные X и Y не требуются)
  -- fx1,fy1,fx2,fy2 : координаты поиска, абсолютные относительно рабочего окна. Обязательно должны быть внутри диапазона скрина.
  -- usl : условие поиска ОДНО, по принципу ужесточения параметров "R(0-255) G(70-90) B(50) R-G[10 80] R-B[-40 -20] G-B[15]" (G-B[15] идентично G-B[15 255]
 -- разность между каналами с возможностью интервала)
  -- numf : максимальное количество искомых пикселей
  local rmem = require "ffi".cast

  local params = ffi.new("uint8_t[10]") -- сколько переменных не считал. 10 при необходимости поменяете.
  local _,_,params[0],params[1]=usl:find("R%((%d+)%-*(%d*)")  r1,r2=tonumber(r1),tonumber(r2)                    -- Получение синтаксических значений поиска по каналу RED

Поменял две последнии строчки. Остально по аналогии. Т.е. у нас теперь вместо r1 будет params[0].

[sutra]

ОК. Спасибо, попробую.

Дарк и "сочини" инициализацию СИ-шного массива, тормоза то ИМЕННО на нём. На досуге разумеется. Конечно это актуально только при поиске всех пикселей на большой зоне захвата. Конечно такое вряд ли потребуется, но если будет СИ-й массив - это сделает функцию абсолютно универсальной без потерь скорости.

[DarkMaster]

А зачем его создавать? Его же getimage создает, а мы фактически его перебираем.
Вообще я хз что там можно сочинить... На 1 000 000 000 элементов (гигабайт почти) у меня уходит 0.46 сек, на 2 400 000 уходит 0.001 примерно(иногда больше, иногда вообще 0 показывает).

[sutra]

Ну или я не понял чего-то, или ты меня не понял. Я имею ввиду операцию присваивания arr[k]={j,i,r,g,b} - именно этот оператор является признаком тормозов на 99%.

Вот нужно, чтобы он был СИ-шным.

[DarkMaster]

Размер arr как-то регламентирован? Допустимо ли его задать жестко?

[sutra]

В том то и фишка, что нет - это массив найденных пикселей, конечно можно задать по максимально возможному по переменным fx1,fy1,fx2,fy2

[DarkMaster]

Использовано на практике может быть любое количество совпадений? Например, я не представляю себе ситуацию, когда будет использовано хотя бы 100 совпадений по findimage, не говоря уже о миллионах =)
Просто учитывая определенную тормознутость выделения памяти это может быть узким местом, если выделять лишнюю. В противном случае нужно прикручивать массив в котором будут содержаться указатели на другие массивы. В рамках луа возникнет много вопросов.

[sutra]

Использовано на практике

Условие R(0-255) должно вернуть массив всей области поиска. На практике, раньше я только так анализировал окно игры, при нынешнем (моём) файнде - это гипотетический случай.

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

local ffi = require("ffi")
ffi.cdef[[
typedef struct { uint8_t red, green, blue, alpha; } rgba_pixel;
]]
Вот про какую вещь я спрашиваю, как я понял фишка именно в этом, в том примере, ссылочку которого ты мне дал.

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

[DarkMaster]

Код

local t = os.clock()
ffi.cdef[[
typedef struct { uint16_t x; uint16_t y; uint8_t red; uint8_t green; uint8_t blue; } rgba_pixel;
]]

function FindRGB(addr,len,scrX1,scrY1,fx1,fy1,fx2,fy2,usl,numf)   
local arr = ffi.new("rgba_pixel[?]", (fx2 - fx1)*(fy2-fy1) )
....
....
if r>=r1 and r<=r2 and g>=g1 and g<=g2 and b>=b1 and b<=b2 and r-g>=RG1 and r-g<=RG2 and r-b>=RB1 and r-b<=RB2 and g-b>=GB1 and g-b<=GB2 then
arr[k].x=j  arr[k].y=i  arr[k].red=r  arr[k].green=g  arr[k].blue=b

как-то так

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

Надо проверять. Это в первую очередь зависит от конкретной архитектуры процессора. У меня там 16 и 8 бит заданы, но еще раз оговорюсь - надо тестить.

[sutra]

Спасибо, вот это я и хотел, попробую, хотя сегодня уже башка не варит, ну если не сегодня, то завтра потестирую.

[DarkMaster]

Мне на самом деле очень интересно, что по скорости получится.

[DarkMaster]

Произвел синтетический тест. Результаты местами неожиданные.
1) Время выполнения операций межу си типом и lua типом меньше, чем между одинаковыми си типами.
Скорее всего при сложении производится конвертация обоих параметров в double, в double же производится вычисление и потом конвертится обратно. При этом должна теряться точность целочисленных вычислений, что плохо(очень).
Косвенно в пользу этой версии говорит то, что сложение long double и lua переменной оказалось невозможно(сохранение производилось в long double).
Так же за эту версию говорит результат сложения двух double. Время практически идентичное сложению lua.
2) uint32_t / unsigned int. Просто какой-то дикий невероятный тормоз, которому я не могу вообще никакого оправдания придумать. u_int64_t и unsigned long long int идут с минимальным отставаением. При этом знаковые 64 битные вычисления оказываются быстрее беззнаковых 32 битных (хоть и не на много). Т.е. если нам нужно хранить число которое не помещается в int, но помещается в unsigned int, то для быстродействия лучше использовать не unsigned int, a long long int. Как? Жесть какая-то. При этом в double 52 бита отведены под целочисленные значения. Там даже привидения типа как такового быть не должно. Ужас...
3) Вычисления на чистом lua. Скорость вычислений слабенькая. Этого по сути и следовало ожидать - операции с плавающей запятой всегда были не очень шустрыми, сейчас вроде получше, но камушек у меня древний. Минимальное отставание от double - видимо какие-то накладные расходы есть (возможно при обращении к массиву). А вот инициализация поистине медленная - дикое отставание от всего, плюс согласно данным luajit.org там идет огромный оверхед по памяти, чем легко можно объяснить время инициализации.

В целом могу оценить результаты кроме unsigned int вполне логичные.

Код. Где ошибка?

Код

print = log
print "clear"
print "mode compact"


local ffi      = require "ffi" -- в шапку.

local t, t2 = nil, nil

local count = 1024*1024*1000
--local count = 1



local data_type ={
    {"int8_t"},
    {"char"},
    {"uint8_t"},
    {"unsigned char"},
    {"int16_t"},
    {"short"},
    {"uint16_t"},
    {"unsigned short"},
    {"int32_t"},
    {"int"},
    {"long int"},
    {"uint32_t"},
    {"unsigned int"},
    {"unsigned long int"},
    {"int64_t"},
    {"long long int"},
    {"uint64_t"},
    {"unsigned long long int"},
    {"float"},
    {"double"},
    }

local my_var = random(10) + 1
for i = 1, #data_type do
    type = data_type[i][1]
    log(type)


--    Время присвоения одного элемента статического массива
    local arr = ffi.new(type.."[".. count / 1000 .."]")
    t = os.clock()
    for j = 1, 1000 do
        for i = 0, count / 1000 - 1 do
            arr[i] = my_var
        end
    end
    t2 = (os.clock() - t)
    data_type[i][2] = t2


    --Время сложения двух элементов статического массива
    arr[0] = random(10) + 1
    t = os.clock()
    for j = 1, 1000 do
        for i = 0, count / 1000 - 1 do
            arr[i] = arr[i] + arr[0]
        end
    end
    t2 = (os.clock() - t)
    data_type[i][3] = t2

    --Время сложения элемента статического массива и переменной lua
    t = os.clock()
    for j = 1, 1000 do
        for i = 0, count / 1000 - 1 do
            arr[i] = arr[i] + my_var
        end
    end
    t2 = (os.clock() - t)
    data_type[i][4] = t2
    arr = nil
end


-- pure lua
for i = 1, 1 do
    local data_type = {{}}
    data_type[i][1] = "lua"
    type = data_type[i][1]
    log(type)

--    Время присвоения одного элемента статического массива
    local arr = nil
    t = os.clock()
    for j = 1, 1000 do
        arr = {}
        for i = 1, count / 1000 do
            arr[i] = my_var
        end
    end
    t2 = (os.clock() - t)
    data_type[i][2] = t2


    --Время сложения двух элементов статического массива
    arr[1] = random(10) + 1
    t = os.clock()
    t = os.clock()
    for j = 1, 1000 do
        for i = 1, count / 1000 do
            arr[i] = arr[i] + arr[1]
        end
    end
    t2 = (os.clock() - t)
    data_type[i][3] = t2
--    data_type[i][3] = "  -  "

    --Время сложения элемента статического массива и переменной lua
    t = os.clock()
    for j = 0, 1000 do
        for i = 1, count / 1000 do
            arr[i] = arr[i] + my_var
        end
    end
    t2 = (os.clock() - t)
    data_type[i][4] = t2
    arr = nil
    log ("           type                 init   sumC   sumLua")
    log(string.format("%-27s:    %.3f %.3f  %.3f", unpack(data_type[i])))
end


for i = 1, #data_type do
    log(string.format("%-27s:    %.3f  %.3f  %.3f", unpack(data_type[i])))
end

t = os.clock()

for i = 0, count do
end
t2 = (os.clock() - t)
log("Время перебора пустого for :    " .. string.format("%.3f",t2))

log ("")
log ("done.")

Результаты

Код

тип данных        инициализация        сложение с массивом того же типа         сложение с lua массивом
           type                 init   sumC   sumLua
lua                        :    16.324 3.161  3.192
int8_t                     :    0.653  0.682  0.653
char                       :    0.650  0.675  0.650
uint8_t                    :    0.648  0.678  0.650
unsigned char              :    0.650  0.678  0.651
int16_t                    :    0.660  0.690  0.665
short                      :    0.660  0.704  0.669
uint16_t                   :    0.660  0.691  0.669
unsigned short             :    0.660  0.689  0.676
int32_t                    :    1.463  1.481  1.463
int                        :    1.468  1.486  1.550
long int                   :    1.442  1.474  1.483
uint32_t                   :    1.445  2.505  1.673
unsigned int               :    1.446  2.502  1.676
unsigned long int          :    1.448  2.503  1.678
int64_t                    :    3.127  3.214  3.167
long long int              :    3.113  3.178  3.173
uint64_t                   :    3.131  3.206  3.183
unsigned long long int     :    3.119  3.174  3.241
float                      :    1.449  1.905  1.635
double                     :    3.103  3.126  3.152
Время перебора пустого for :    0.322

Надо бы еще на си через ffi написать аналогичный тест. Там можно функции создавать. Если есть желающие - буду рад.

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

[cirus]

но камушек у меня древний

Походу очень древний.

i7 7700K, результаты

Код

           type                 init   sumC   sumLua
lua                        :    4.458 0.625  0.541
int8_t                     :    0.266  0.344  0.343
char                       :    0.284  0.353  0.329
uint8_t                    :    0.265  0.469  0.328
unsigned char              :    0.266  0.468  0.328
int16_t                    :    0.266  0.359  0.468
short                      :    0.282  0.359  0.469
uint16_t                   :    0.286  0.355  0.339
unsigned short             :    0.269  0.370  0.340
int32_t                    :    0.281  0.344  0.343
int                        :    0.282  0.359  0.344
long int                   :    0.281  0.468  0.328
uint32_t                   :    0.282  0.953  0.843
unsigned int               :    0.265  0.929  0.859
unsigned long int          :    0.281  0.938  0.849
int64_t                    :    0.578  0.734  0.656
long long int              :    0.578  0.734  0.687
uint64_t                   :    0.578  0.735  0.656
unsigned long long int     :    0.563  0.734  0.656
float                      :    0.281  0.594  0.491
double                     :    0.312  0.500  0.485
Время перебора пустого for :    0.231