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

[Cockney]

Если чесловек вместо int сует double, то он скорее всего идиот, уж простите =)

Ну почему, вот ситуация - имеем хеш мапу. Получили хеш. Получаем индекс корзины, т.е. просто деление хеша на кол-во корзин. Результат дробный. Дальше по этому индексу (а он обрежется до целого) вставляем элемент. Вопрос в том предупредит ли компилятор об этом или нет. Таких мест может быть миллион на 100 строк кода.

[cirus]

Код

for i=1,100000000 do
a=8%3
-- a=math.modf(8/3)
end

Такие тесты вообще ничего не отражают. То что выполняется быстрее в одном цикле может выполняться дольше в скрипте где несколько циклов, много переменных и т. д.

[DarkMaster]

Ну с другой стороны, ошибок на пустом месте тоже не бывает, так ?

Бывают и очень много. Ошибок от непонимания, как "оно" должно работать лично у меня очень мало. Невнимательность, звонки, перерывы - топ причин.

Я вот сейчас поигрался с виндовым LPCSTR и некоторыми типами из библиотеки c++ - не вижу проблем. Можно проблему как-то воспроизвести ? Кусочек кода там показать.

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

Код

    BOOL WriteFile(
        HANDLE       hFile,
        LPCVOID      lpBuffer,
        DWORD        nNumberOfBytesToWrite,
        LPDWORD      lpNumberOfBytesWritten,
        void*        lpOverlapped
    );

Вызови без кастов передав void*, void*, unsigned long, unsigned long*. А еще лучше вместо unsigned long* передать тот же void* - указатель это указатель, ничего нового в нем не будет. А можно и довести и вовсе до предела - передать вместо void* любимый и красивый unsigned int. Матом крыть не будет?

Ну почему, вот ситуация - имеем хеш мапу. Получили хеш. Получаем индекс корзины, т.е. просто деление хеша на кол-во корзин. Результат дробный. Дальше по этому индексу (а он обрежется до целого) вставляем элемент. Вопрос в том предупредит ли компилятор об этом или нет.

На мой взгляд приведение разных типов данных должно быть явным, если возможна потеря данных. Касатаельно плавающей точки, так и вовсе возможно 3 приведения: отброс мантиссы, округление вверх, округление до целого. И лично мое мнение, если подобное преобразование используется, то оно должно быть явным.
Преобразование же из 4 байтов беззнакового целого в 4 байта беззнакового целого (обозванного иначе) - для меня это бред сивой кобылы. При всем моем очень глубоком уважении к си (без иронии). Понятно, что может быть преобразование little/big endian, можно вообще выдумать другой формат хранения целого в этих 4 байтах, но речь то не об этом, речь о полностью идентичном формате, переобъявленном 10 раз.

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

[cirus]

Матом крыть не будет?

Нет, если объявишь void, то будет принимать всё подряд.

LPCVOID lpBuffer,

Код

void*  lpBuffer

[DarkMaster]

Нет, если объявишь void, то будет принимать всё подряд.

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

Сообщение отредактировал DarkMaster - 10.4.2021, 9:56

[sutra]

Эта идеология умерла минимум 30 лет назад.

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

Такие тесты вообще ничего не отражают

Я же абсолютно ясно сказал - для смеха (IMG:style_emoticons/default/biggrin.gif) Возможно что-то где-то и тормозит, вопрос а на сколько? на 1 миллионную долю секунды? Тут такие якоря люди делают, такие вещи, совершенно не думая ни о какой скорости, что этот примитивный оператор - это просто невинное дитя.

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

Моя общая мысль очень проста, я не собираюсь изобретать колесо. Напротив, хотелось бы применять это колесо, создавая например автомобиль, а не неся это колесо на своей спине. Ну вот ведь очень забавно, ты Cirus взял и откопал способ получения битовой маски. А что 2-3 года назад этой возможности не было?? Была, просто мы о ней не знали. А про звук? Да наверняка такая же элементарщина, просто мы не знаем как к ней получить доступ. Вот про что я говорю, а не про синтетику тестов.

[Cockney]

Бывают и очень много. Ошибок от непонимания, как "оно" должно работать лично у меня очень мало. Невнимательность, звонки, перерывы - топ причин.

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

Код

    BOOL WriteFile(
        HANDLE       hFile,
        LPCVOID      lpBuffer,
        DWORD        nNumberOfBytesToWrite,
        LPDWORD      lpNumberOfBytesWritten,
        void*        lpOverlapped
    );

Вызови без кастов передав void*, void*, unsigned long, unsigned long*. А еще лучше вместо unsigned long* передать тот же void* - указатель это указатель, ничего нового в нем не будет. А можно и довести и вовсе до предела - передать вместо void* любимый и красивый unsigned int. Матом крыть не будет?

VC++ 2017 CE, C++17

Код

const unsigned long l = 0;
WriteFile(l, l, l, l, l);

Ни одного предупреждения даже на самом строгом уровне компиляции. Единственное, что не вышло это отправить unsigned int в lpBuffer, причина - LPCVOID объявлен как const char*, т.е. константный указатель, и передача без явного каста запрещена. Я же просто добавил const к переменной l. Из этого становится очевидно, что компилятор кроме размерности данных отслеживает еще и другие свойства их.

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

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

[sutra]

Не о том господа думаем. Про скорость. Мне вот совершенно не нравится такая вещь: j=j+1. В Паскале была такая незаменимая для счётчиков вещь как инкремент (inc и dec). Там отсутствует контроль выхода за допустимый диапазон типа данных, а он в нашем случае как раз и не нужен. Наверняка ведь можно прикрутить такую штуку и в нашем финде.

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

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

Это понятно, что Илону Маску наплевать на наши битовые маски. Но вот только для нас это как раз и есть реальная задача. С которой мы как-то очень плохо справлялись до недавнего времени.

[DarkMaster]

Ни одного предупреждения даже на самом строгом уровне компиляции.

Блин аж руки чешутся старую студию налить. Было больше 10 лет назад, как раз на границе перехода на 2011 стандарт, может уже и что-то путаю, но вообще был уверен прям ну совсем. А может прогресс все-таки дошел. Тем не менее переобъявления сами по себе от этого имхо умнее стали, хотя проблем безусловно меньше. А handle вместо, скажем dword сожрет?)
А на функции работы со строками которые нормальные сишные, на не _s материться перестал?)

[Cockney]

Блин аж руки чешутся старую студию налить. Было больше 10 лет назад, как раз на границе перехода на 2011 стандарт, может уже и что-то путаю, но вообще был уверен прям ну совсем. А может прогресс все-таки дошел. Тем не менее переобъявления сами по себе от этого имхо умнее стали, хотя проблем безусловно меньше. А handle вместо, скажем dword сожрет?)
А на функции работы со строками которые нормальные сишные, на не _s материться перестал?)

Не сожрал)

А в чем ругань заключалась ?

[sutra]

И у меня есть ощущение, что if-ы слишком медленны. 250 лямов выполняются 2 секунды. Наверное как раз на битовом уровне это и можно было бы ускорить. Собственно что надо, узнать попадает ли конкретное число в заданный диапазон (всего в пределах 1 байта). Число целое - всё должно просто летать. А этот lua кто знает чего он там сравнивает, какие типы там у него.

[DarkMaster]

А в чем ругань заключалась ?

Да я бы не сказал, что ругань. Скорее наоборот, я поддержал sutra в некоторых старперских взглядах, которые мне близки =)

[sutra]

Вот ещё интересная вещь. Заменил if j==sim на if rawequal(j,sim) и получил тормоз более 15%. Было 1.98 сек. а стало 2.34. Хотя по логике вроде бы должно быть наоборот.

Не понимаю я lua, от слова совсем. Надо попробовать полностью всё перевести на СИ. Просто интересно посмотреть на результат.

[sutra]

Короче, компилятор тут мама не горюй, как он чего делает, совершенно не понятно.
Простенький тестик, для смеха.

for i=1,200000000 do
if 8%3 ==2 then a=a+1 end -- 187 - 219 тысячных сек.
-- if 8%3 ~=2 then break end -- 60 - 70 тысячных сек.
end

ВОПРОС. А чего он у меня целых 2 секунды делает, если там ещё всё проще. Обычное сравнение. Сравнил - пошёл дальше. Вот вам и тормоза на абсолютно ровном месте. Или это так вайлы тормозят.
ОТМЕЧУ! Тестик на так называемом тормозе под названием процент.

Короче, однозначно надо прикручивать инкремент, наверняка это можно сделать. И очень внимательно пересмотреть всю математику циклов.

Или он так долго шарится по памяти. Ведь на порядок медленнее в финде.

[sutra]

Тестанул цикл в цикле - результаты не изменились

for k=1,100 do
for j=1,100 do
for i=1,20000 do

Возникают вопросы, на которые не могу дать ответа.

[DarkMaster]

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

[sutra]

Ты читаешь мои мысли. Я тоже хотел попробовать всё это сделать на Дельфине. Чтобы точно понимать все причины. Если честно, мне просто лень, поскольку меня то лично всё устраивает, я ничего не ищу при 80%. Но что-то мне подсказывает, что дело то именно в математике. Хочется всё-таки окончательно разобраться в этом вопросе, чтобы в будущем не наступать на те же грабли. Плюс там ещё вдобавок есть директивы компиляции, то же бы невредно посмотреть разницу. Не знаю, смогу ли себя заставить сесть за это дело.

[DarkMaster]

Ну я себя в любом случае заставлю. Надо ставить точку и хотя бы в бета-релиз все выводить.

[sutra]

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

[DarkMaster]

начинает с самого уникального "цвета" (наиболее редкого) и так в порядке уменьшения уникальности

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