Разработка findcolor, findimage, Pure lua Опции

[DarkMaster]

Откуда я знаю ? Смысл в том, что ты искать причины замучаешься, если такая проблема всплывет.

Начнем с того, что луа - это язык который создавался, как интерфейс между сишными нагруженными функциями. Хочешь выжимать из языка больше, чем то для чего это предназначено? Ну твои (в данном случае мои) проблемы. Не нравятся проблемы джита? Ну так jit.off() и никаких неожиданностей. Будет обычный луа, расширенный ffi.

я лично бы после подобных фокусов от языка сгорел и выбросил его на помойку (с учетом того, что альтернатив куча)

Тут нужно четко понимать на что ты идешь. Я понимал. Хотелось подергать судьбу за хвост и получить джекпот, не получилось. Я вполне отдавал себе отчет в возможных причинах и ограничениях. Если брать производительность, то ирония в том, что даже при хреновом прогнозировании jit'ом ты получаешь производительность существенно выше, чем без него и крайне приятную в отношении альтернатив. Простота и удобство для луа лично для меня очень высоки. В стародавние времена когда я учил С/С++ меня напрягали очень многие вещи, которые мне даже на заре моего разума казались велосипедами, которые давно должны были быть решены в общем случае за исключением высоконагруженных участков кода. В силу своего характера я не привык тупо говорить "гадость", а прокручивал в голове то, как бы я хотел это видеть и как бы это могло быть решено. Лет через 5 после этого я впервые увидел луа (задолго до пилота) и сказать, что моему удивлению не было предела - ничего не сказать. Все было реализовано примерно на 90% именно так, как я видел и мечтал. Мои мысли с разрабами сошлись очень сильно и лично для меня существенных минуса всего два: разошедшиеся пути главной ветки луа и jit версии (и то в следствии того, что jit версия заглохла) и некоторая ограниченность готовых биндингов в следствии пункта первого. У каждого языка есть своя ниша и lua имхо со своей справляется отлично, просто он меня наказал за то, что я пытался из речного трамвайчика сделать атомный ледокол. Это уж точно не вина языка и еще раз - я понимал на что я иду и все риски.

[Cockney]

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

Пароль: uopilot

[cirus]

Координата X на 1 меньше чем нужно.
Red.bmp:

X: 29, Y: 31, accuracy: 100

На самом деле X: 30, Y: 31, можно в пейнте проверить.

Red.bmp обрежь снизу до размера 10*18. Результаты поиска:

Found: 13
X: 29, Y: 31, accuracy: 100
X: 29, Y: 50, accuracy: 100
X: 97, Y: 51, accuracy: 100
X: 97, Y: 70, accuracy: 100
X: 74, Y: 133, accuracy: 100
X: 74, Y: 152, accuracy: 100
X: 173, Y: 113, accuracy: 100
X: 173, Y: 132, accuracy: 100
X: 220, Y: 41, accuracy: 100
X: 220, Y: 60, accuracy: 100
X: 220, Y: 79, accuracy: 100
X: 257, Y: 153, accuracy: 100
X: 257, Y: 172, accuracy: 100

29, 50 - это конечная по Y координата найденной картинки. Т. е. нашлось что-то не то.

Не проще ли указывать цвет фона отдельным параметром? Никогда не понимал в чём удобство закрашивания левого верхнего пикселя.

[Cockney]

Не проще ли указывать цвет фона отдельным параметром? Ни когда не понимал в чём удобство закрашивания левого верхнего пикселя.

проще. удобств нет, осталось в наследство от поведения пилота.

[DarkMaster]

Не проще ли указывать цвет фона отдельным параметром? Никогда не понимал в чём удобство закрашивания левого верхнего пикселя.

Это удобно при машинной обработке изображения. Альтернатива разве что запись имени файла, но тут уже вопросы удобства еще бОльшие.

[Cockney]

Можете накидать картинки на которых свои поделки тестите ? Или из практики что-то.

[DarkMaster]

Я обычно в пеинте просто что-то рисовал, т.к. тестил весьма определенные моменты.

[DarkMaster]

Попробовал с длл... В длл перебор получается 6.5 раз дольше... Что не так?

Код

DLLIMPORT int * shadow(int result[][5], int size_result)
{

    result [0][0] = 10;
    result [0][1] = 11;
    result [0][2] = 0;
    result [0][3] = 1;
    
    
    for (int i = 0; i < 1000000000; i++){
        if (result [0][0] < result [0][1]) {
            result [0][2]++;
            result [0][3]++;
        }
    }
    
    return result[0];
}

Код

local t = os.clock()
log(    array_comparator.shadow(result, 1024)   )
log("dll два инкремента:", os.clock()-t)
log(result[0][2])
log(result[0][3])
log""

result[0][0] = 10
result[0][1] = 11
result[0][2] = 0
result[0][3] = 1
local t = os.clock()
for i = 1, 1000000000 do
    if result[0][0] < result[0][1] then
        result[0][2] = result[0][2] + 1
    end
end
log("lua 1 инкремент:", os.clock()-t)
log(result[0][2])
log""

result[0][0] = 10
result[0][1] = 11
result[0][2] = 0
result[0][3] = 1
local t = os.clock()
for i = 1, 1000000000 do
    if result[0][0] < result[0][1] then
        result[0][2] = result[0][2] + 1
        result[0][3] = result[0][3] + 1
    end
end
log("lua 2 инкремента:",os.clock()-t)
log(result[0][2])
log(result[0][3])
log""

[DarkMaster]

Врубил оптимизацию в компиляторе (да-да, я мега сишник).
время выполнения изменилось с
dll два инкремента: 4.01
lua 1 инкремент: 0.624
lua 2 инкремента: 0.647

на
dll два инкремента: 0.75399999999999
lua 1 инкремент: 0.623
lua 2 инкремента: 0.648

Ну как-бы лучше, но как-бы все равно wtf...

[Cockney]

Попробовал с длл... В длл перебор получается 6.5 раз дольше... Что не так?

Код

DLLIMPORT int * shadow(int result[][5], int size_result)
{

    result [0][0] = 10;
    result [0][1] = 11;
    result [0][2] = 0;
    result [0][3] = 1;
    
    
    for (int i = 0; i < 1000000000; i++){
        if (result [0][0] < result [0][1]) {
            result [0][2]++;
            result [0][3]++;
        }
    }
    
    return result[0];
}

Код

local t = os.clock()
log(    array_comparator.shadow(result, 1024)   )
log("dll два инкремента:", os.clock()-t)
log(result[0][2])
log(result[0][3])
log""

result[0][0] = 10
result[0][1] = 11
result[0][2] = 0
result[0][3] = 1
local t = os.clock()
for i = 1, 1000000000 do
    if result[0][0] < result[0][1] then
        result[0][2] = result[0][2] + 1
    end
end
log("lua 1 инкремент:", os.clock()-t)
log(result[0][2])
log""

result[0][0] = 10
result[0][1] = 11
result[0][2] = 0
result[0][3] = 1
local t = os.clock()
for i = 1, 1000000000 do
    if result[0][0] < result[0][1] then
        result[0][2] = result[0][2] + 1
        result[0][3] = result[0][3] + 1
    end
end
log("lua 2 инкремента:",os.clock()-t)
log(result[0][2])
log(result[0][3])
log""

в сишном коде компилятор может не уметь выкинуть проверку условия, оно же константное (вообще оптимизация включена ?)

Врубил оптимизацию в компиляторе (да-да, я мега сишник).
время выполнения изменилось с
dll два инкремента: 4.01
lua 1 инкремент: 0.624
lua 2 инкремента: 0.647

на
dll два инкремента: 0.75399999999999
lua 1 инкремент: 0.623
lua 2 инкремента: 0.648

Ну как-бы лучше, но как-бы все равно wtf...

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

[DarkMaster]

Ну мне то, как раз бы понять именно скорость выпонения ифов. Сделал просто базовую синтетику чтобы понять разницу.
Типа в си время жрет иф, математика мгновенна, а в луа иф выкинут, матетматика тормоз?

[Cockney]

Ну мне то, как раз бы понять именно скорость выпонения ифов. Сделал просто базовую синтетику чтобы понять разницу.
Типа в си время жрет иф, математика мгновенна, а в луа иф выкинут, матетматика тормоз?

иф жрет везде. непонятно что под капотом у луа и что сгенерил сишный компилятор

[DarkMaster]

Круто) Как променять непонятное поведение ffi на компилятор (IMG:style_emoticons/default/crazy.gif) (IMG:style_emoticons/default/laughingneqw.gif)
Ну запихаю весь перебор и будем посмотреть. Но пока реально сижу и ржу)

[Cockney]

Круто) Как променять непонятное поведение ffi на компилятор (IMG:style_emoticons/default/crazy.gif) (IMG:style_emoticons/default/laughingneqw.gif)
Ну запихаю весь перебор и будем посмотреть. Но пока реально сижу и ржу)

Майкрософтовский компилятор ожидаемо вырезал все что тормозит. Весь цикл просчитал за 0,3 миллисекунды. Не СЕКУНД, а именно 300000 наносекунд

И да, я даже не сырые указатели использовал, а std::array - обертку над массивами, что по идеи должно утяжелить код.

Майкрософтовский компилятор ожидаемо вырезал все что тормозит. Весь цикл просчитал за 0,3 миллисекунды. Не СЕКУНД, а именно 300000 наносекунд

И да, я даже не сырые указатели использовал, а std::array - обертку над массивами, что по идеи должно утяжелить код.

Железо i3 2ghz

[DarkMaster]

Майкрософтовский компилятор ожидаемо вырезал все что тормозит. Весь цикл просчитал за 0,3 миллисекунды. Не СЕКУНД, а именно 300000 наносекунд

Не ну компилятор молодец, догадался и оптимизировал. Как это даст представление о количестве ифов/сек в реальных задачах?
Ну собственно вердикт прежний: докидаю - будет видно.

Код

DLLIMPORT int * shadow(int result[][5], int size_result)
{

    for (int i = 0; i < 1000000000; i++){
        if (result [0][0] < result [0][1]) {
            //result [0][0]++;
            result [0][1]++;
        }
    }
    
    return result[0];
}

а так?
можно 0 0 раскомменитить, если будет умничать)

[Cockney]

Не ну компилятор молодец, догадался и оптимизировал. Как это даст представление о количестве ифов/сек в реальных задачах?
Ну собственно вердикт прежний: докидаю - будет видно.

Код

DLLIMPORT int * shadow(int result[][5], int size_result)
{

    for (int i = 0; i < 1000000000; i++){
        if (result [0][0] < result [0][1]) {
            //result [0][0]++;
            result [0][1]++;
        }
    }
    
    return result[0];
}

а так?
можно 0 0 раскомменитить, если будет умничать)

А смысл считать ифы в секунду ? Мне кажется это странный подход к измерению производительности решения в целом. В реальных то задачах данные не синтетический: Оно может 5 раз на удачную последовательность попасть и закешировать, а может и не попасть.

[DarkMaster]

дык а что он закэширует то? адреса то постоянно будут смещаться на каждой итерации. По сути это ад для всех оптимизаций.

[Cockney]

дык а что он закэширует то? адреса то постоянно будут смещаться на каждой итерации. По сути это ад для всех оптимизаций.

Так бренч предикшн процессора

[DarkMaster]

Ну он на чтение сработает. А ветвления он вообще никак не просчитает ибо там просчитывать просто нечего.

[Cockney]

А причем тут чтение ? Там механизм не связан с доступом к памяти вообще. Там статистика переходов ведется. Чем больше переходов по одной из веток, тем быстрее проверка будет в ифе, скажем досрочный прыжок. А чтобы такое было возможно нужно хорошие данные дать на вход.


Вообще все это не важно. Кол во ифов ты не посчитаешь, да и это не надо. Бери за эталон какое то время и старайся снизить асимптотику алгоритма. Все остальное за машиной. Лучше не сумеешь.