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

[sutra]

сишной объявите.

Так и была сишная. Играл с типами, но что-то толком не понял как быстрее, всё равно медленнее. Не стал забивать себе голову. Вообще убрал этот внутренний цикл. Стало некрасивей, но это оказался самый быстрый вариант.

Попрбуй использовать для сравнения наименьший и наибольший каналы

Я понял, понял. Но там и так всё быстро и надёжно. Может не так быстро, как можно сделать, но всё компактно и красиво. А когда в бешеном цикле вертеть картинки, то лишние операторы всё равно вызовут тормоза. На картинках главное сами картинки и упрощённая до безобразия функция сравнения. В общем я просто подстроил под собственные нужды, всё равно получается быстро, просто уже начал с жиру беситься. (IMG:style_emoticons/default/biggrin.gif) Спасибо за советы.

Имитировал наихудшую ситуацию, когда типа искало и ничего не смогло найти. 1000 картинок за 6 сотых секунды. Чего выпендриваться - достойная скорость.

Искало по всем пикселям 500х23 * 1000 картинок = 6 сотых сек..

Грубо говоря полный перевод на СИ, увеличил скорость в 2 раза. А тот внутренний цикл, хрен его знает. Там и ридмем и сравнение и цикл. На чём-то ускоряется, на чём-то замедляется. Выкинул цикл и всех делов.

[sutra]

Выбросил из кода if math.abs(sg[2]-sl[2])>cdev then return 0 end
Сделал код ещё некрасивей, но ещё быстрее на 30%. А это очень прилично. В "боевых" условиях, на "живых" картинках, что-то мне подсказывает поиск будет мгновенным.

[sutra]

Код

log "clear" log "mode compact"
local ffi=require "ffi"
local n=ffi.new("uint8_t[3]")
local m=ffi.new("uint8_t")
local s=""
m=tonumber(r1)
log(m)                -- nil
log(type(n[0]))       -- number
--n[0]=tonumber(r1)   -- если разремарить будет ошибка конвертирования
stop_script()

Вопрос, почему результат отличается, хотя тип вроде один и тот же. И возникает и другой вопрос, как лучше делать, какой вариант более быстрый, по логике вроде массив значит должен быть быстрей.

[sutra]

Непонятно почему при первом варианте с переменной m нет ошибки.

По логике типа её адрес не определён и следовательно nil, а как тогда хранится её адрес в памяти? Что-то я запутался.

Вроде понял, извините, затупил.

[sutra]

Код

--lua
local ffi=require "ffi"
log "clear" log "mode compact"
local n=ffi.new("uint32_t[3]")
local x,y,z=ffi.new("uint32_t"),ffi.new("uint32_t"),ffi.new("uint32_t")
x,y,z=0,0,0
tmc=os.clock()
repeat
  x=x+1
  repeat
    y=y+1
    if y>x then z=1 else z=2 end
  until y>100000000
until x>100000000
log(os.clock()-tmc)
tmc=os.clock()
repeat
  n[0]=n[0]+1
  repeat
    n[1]=n[1]+1
    if n[1]>n[0] then n[2]=1 else n[2]=2 end
  until n[1]>100000000
until n[0]>100000000
log(os.clock()-tmc)
stop_script()

Похоже я жестоко ошибся и нельзя делать массивы, придётся переделывать свои функции. Дарить более 100% скорости - грех.

[sutra]

Дарк, чего-то я вообще ничего не понимаю. Может я чего не то делаю? Вот тестани этот код. У меня получается медленнее на СИ-шных, на массиве разница вообще очевидная.

Код

log "clear" log "mode compact"
do
local n=ffi.new("uint32_t[3]")
local x,y,z=ffi.new("uint32_t"),ffi.new("uint32_t"),ffi.new("uint32_t")
x,y,z=0,0,0
tmc=os.clock()
repeat
  x=x+1
  repeat
    y=y+1
    if y>x then z=1 else z=2 end
  until y>100000000
until x>100000000
log(os.clock()-tmc)
tmc=os.clock()
repeat
  n[0]=n[0]+1
  repeat
    n[1]=n[1]+1
    if n[1]>n[0] then n[2]=1 else n[2]=2 end
  until n[1]>100000000
until n[0]>100000000
log(os.clock()-tmc)
end

do
local n={}
n[1],n[2],n[3]=0,0,0
local x,y,z=0,0,0
tmc=os.clock()
repeat
  x=x+1
  repeat
    y=y+1
    if y>x then z=1 else z=2 end
  until y>100000000
until x>100000000
log(os.clock()-tmc)
tmc=os.clock()
repeat
  n[1]=n[1]+1
  repeat
    n[2]=n[2]+1
    if n[2]>n[1] then n[3]=1 else n[3]=2 end
  until n[2]>100000000
until n[1]>100000000
log(os.clock()-tmc)
end
stop_script()

Понятно только одно, массивы однозначно медленнее!

Cirus, а у тебя как? Тоже медленнее?

Может нельзя использовать константы используя СИ??

[DarkMaster]

local m=ffi.new("uint8_t")

Там какие-то грехи водятся за этой конструкций. Оно вроде валидная конструкция, все дела. Вот только там при переполнении переменной начинает писать в соседние байты. То ли проверок просто нет, то ли сама конструкция не корректная я не знаю. Надо посмотреть биндинги какие-нибудь, как там реализуют. Мне не горело, я просто массивы объявлял.

0.50599999999395
1.1109999999753
0.50699999998324
0.76400000002468

Там кстати после скольки-то нулей циклов начинает расти время не прямолинейно. По крайней мере в for.

[sutra]

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

[cirus]

Раз уж тесты на скорость, зачем repeat, когда есть while.

код

Код

--lua
local ffi=require "ffi"
log "clear" log "mode compact"
local n=ffi.new("uint32_t[3]")
local x,y,z=ffi.new("uint32_t"),ffi.new("uint32_t"),ffi.new("uint32_t")
x,y,z=0,0,0
tmc=os.clock()
repeat
  x=x+1
  repeat
    y=y+1
    if y>x then z=1 else z=2 end
  until y>100000000
until x>100000000
log(os.clock()-tmc)

x,y,z=0,0,0
tmc=os.clock()
while x<=100000000 do
    x=x+1
    while y<=100000000 do
        y=y+1
        if y>x then z=1 else z=2 end
    end
end
log(os.clock()-tmc)
stop_script()

[sutra]

Но от массива надо однозначно избавляться. На СИ - 100% потери - это ни в какие ворота не лезет. Я стараюсь выжать крохи, а тут такой костыль...

Раз уж тесты на скорость, зачем repeat, когда есть while.

Слушай думал на эту тему, но никак не думал что и тут костыли.

[DarkMaster]

У меня получается медленнее на СИ-шных, на массиве разница вообще очевидная.

Я над этим на самом деле очень долго голову ломал. Так ничего умного и не понял. Вообще судя по докам там должно быть промежуточное приведение к double, что существенно должно замедлять скорость работы. Однако в тех тестах, что я тут выкладывал получилось совсем не так. Думаю, просто нужно соблюдать типизацию, если хочется скорости. Т.е. все операции производить между одинаковыми типами. Кстати ты проводишь операции над unsigned int 32, который по тестам был самым невероятно тормознутым. Убирай unsigned, если пролазит максимальное значение. Там даже int 64 был шустрее(или столько же?), чем unsigned int 32. Если значения позволяют, то уменьшай до 8/16 бит.

[sutra]

Спасибо Cirus. Ладно, переделаем, ну блин, я выжму до последней капли - будет 10 махов.

Слушай Дарк, у меня наоборот на беззнаковых быстрее. Здесь 32 бита, просто чтобы "влезли" циклы. Но на самом деле я пробовал ВСЕ типы. ПРИНЦИПИАЛЬНОГО выигрыша нет. А здесь то 100%!!!

Принцип я понял. Кстати я ведь тестировал кое-что и прироста тоже не обнаружил между СИ и LUA. Там реальный прирост при вызове ридмема, так сказать родное на родном работает, а на остальном надо действительно просто смотреть, ни хрена не понятно.

[DarkMaster]

https://forum.uokit.com/index.php?showtopic...255&st=120#
В синтетике одназначно есть разница. Возможно if'ы все тормозят ибо хз как их там реализовывали, может приведение идет.

[sutra]

Огромное спасибо. Две пилюли есть, вместо репита вайл и вместо массива - переменные. Прирост будет супер.

Возможно if'ы все тормозят ибо хз как их там реализовывали

Да, там действительно не совсем понятно, наверняка есть приведение типов. Только на своём финде я прирост получил. Надо проверять каждый оператор. Живой пример подкинул Cirus.


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

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

А вот на вайле - целочисленный индекс.

Возможно из-за этого репит так тормозит, потому что делают то одно и то же. Короче костылей тут хватает, надо проверять ну абсолютно ВСЁ. Это братцы не Паскаль.

Ещё раз парни спасибо, за науку.

[sutra]

Переделал свою функцию поиска на вайл - прирост НУЛЬ, там сравнение с переменными и тормозов нет.

Так что с константами надо поаккуратнее.

[DarkMaster]

в double отведено 52 бита под целые. Аккуратнее с нулями.

Сообщение отредактировал DarkMaster - 21.12.2018, 3:05

[sutra]

Убрал из функции массивы, в ридмем читаю в переменные. Прирост скорости 11%.

[DarkMaster]

А ты стариной не тряхнешь и не перепишешь этот кусок на асме в итоге?) Скорость будет существенно выше (IMG:style_emoticons/default/smile.gif) Кстати в этой шутке только доля шутки.

[sutra]

А ты стариной не тряхнешь и не перепишешь этот кусок на асме в итоге?)

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


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

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

[DarkMaster]

Но я наверное плюну на мелочи

Я все-таки надеюсь, что допилишь поиск по мин/макс каналу и точность =)