все, теперь ясно... гуд!

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

Вот хорошее замечание

кстати, надо потестить насколько

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

тоже вариант, спасибо

Я тестил на телефоне, вставка в начало медленнее примерно на (n - маленькое с), где n - длина массива. Удаление из начала массива длиной в миллион элементов, чуть меньше чем в миллион раз медленнее чем удаление из конца.

ого... понятно

у меня таких масштабов нет

максимум тысяча примерно

у меня таких масштабов нет

Ну, я просто стараюсь учитывать подобные случаи, ибо пишу либы.

мне кажется, на тысячу сдвигов вполне хватит одной миллисекунды

а быстрее совсем не надо

Хватит, хватит :3

так что оставлю как есть.

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

зачем двусвязный список, если для таких задач есть B-tree? там сложность поиска логарифмическая. а тормоза с динамикой можно убрать, если свой аллокатор сделать: сначала выделить большой кусок памяти средствами системы, а там уже играться как-угодно по-своему

например https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BD%D0%BE-%D1%87%D1%91%D1%80%D0%BD%D0%BE%D0%B5_%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE

это да если миллионы-миллиарды объектов а у меня тупо миллион в принципе быть не может, разве что в эту игру будут играть все русскоязычные пользователи телеграма

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

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

не будет - это вспомогательный, а не основной бот

да и инвайта на хабр мне никто не дает (впрочем я и не прошу, и сам туда писать не особо собираюсь)

например https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BD%D0%BE-%D1%87%D1%91%D1%80%D0%BD%D0%BE%D0%B5_%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE

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

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

Всегда можно задействовать luajit и его ресурсы ;)

Всегда можно задействовать luajit и его ресурсы ;)

Да, на эту тему я уже тоже подумал : )

а кстати. как сам иерусалимский относится к luajit? я пытался гуглить, но не нашел фраз, которые бы говорили о таком

Я аналогично не видел

https://github.com/neomantra/lds

а кстати. как сам иерусалимский относится к luajit? я пытался гуглить, но не нашел фраз, которые бы говорили о таком

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

Кстати, если кому интересно, как именно пишут на ffi: https://github.com/luapower/libcurl/blob/master/libcurl.lua

кому если надо тестить свои приложения, дабы небыло ошибок ;) то есть однофайловый тестер https://bitbucket.org/zserge/gambiarra

@Snusmumriken скажи, а зачем ты писал сортировку, чем не устроила стандартная table.sort ?

Медленно : 3 Да, сишный квиксорт оказывается медленнее.

Сишная медленнее? Там же вроде qsort?

Что за чудеса....

Вопрос задач. На почти совсем отсортированных массивах, гномы быстрее.

А, понял

А теперь представь что у меня - миллион статичных кирпичей, и несколько сотен динамических объектов, которые только меняются местами со статичными кирпичами. Сортировать квиксортом - значительно медленнее, инфа сотка. Да, сортировка происходит по координатам вдоль какой-то из осей (x/y).

да, я посмотрел алгоритм... это понятно, это правильный подход )

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

Хотя сортировка рандомом - венец алгоритмов. Как и #define true random() > 0.5. И прочая стохастика. Осталось научиться приемлемо кодить в таких условиях.

Хотя сортировка рандомом - венец алгоритмов. Как и #define true random() > 0.5. И прочая стохастика. Осталось научиться приемлемо кодить в таких условиях.

для массива из 2-3 элементов ничем не хуже любого другого

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

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

ты про неупорядоченность элементов массива?

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

😆😆😆 нормальные измышления в чате по луа

😆😆😆 нормальные измышления в чате по луа

я люблю луа я люблю чат луа я люблю разговор про чат луа

Ехехехе, это стохастическое программирование. Пихаем как можно больше рандома во все щели, и получаем ПОЧТИ ГАРАНТИРОВАННО нужный результат за минимальное время.

Ехехехе, это стохастическое программирование. Пихаем как можно больше рандома во все щели, и получаем ПОЧТИ ГАРАНТИРОВАННО нужный результат за минимальное время.

за время в многократное раз превышающее возраст Вселенной?

Точнее *оно должно таким быть*, если хорошо вкурить матан.

Нет, как раз минимальное - быстрее любых существующих алгоритмов, чаще всего - O(1). То есть, ситуация в мировом эфире сложилась таким образом, что ты получил сразу нужный вариант :3

это ты Грега Игана начитался?

Это как глупая сортировка, которая каджый раз срабатывает идеально.

Не, расслабься :3 Хотя идея хорошая.

за время в многократное раз превышающее возраст Вселенной?

Неа, вот скажем один из самых шустрых алгоритмов выявления простых чисел - он нестрогий, и даёт правильный ответ всего лишь с вероятностью около 0.99999999(восемь девяток)

:3

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

Неа, вот скажем один из самых шустрых алгоритмов выявления простых чисел - он нестрогий, и даёт правильный ответ всего лишь с вероятностью около 0.99999999(восемь девяток)

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

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

Пришел один программист к мудрецу, и попросил программу без ошибок. - Глупец! - вскричал мудрец - Почему ты не попросишь у меня ошибку без программы? И хрясь, винчестером по голове.

))))))

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

Парни, в геймдеве сегодня промелькнуло сообщение о том что https://www.cgpeers.com/ доступен для регистрации на 48 часов. Это трекер с геймдевскими штуками, плагинами, паками и прочим... кому надо, в общем.

Парни, в геймдеве сегодня промелькнуло сообщение о том что https://www.cgpeers.com/ доступен для регистрации на 48 часов. Это трекер с геймдевскими штуками, плагинами, паками и прочим... кому надо, в общем.

а чё там? текстурки, модельки?

модели есть точно

Да и текстуры тоже )

В общем зарегался, вдруг когда пригодится.

Спс

https://habrahabr.ru/post/321864/

Кстати, openresty реально быстр... Тестировал как-то

мне openresty отдавал страницу за 5-7 мс на очень среднем железе. это было круто во времена РНР5, который на том же железе был раз в 15 медленнее. но потом вышел РНР7, и время отдачи страницы стало очень сравнимо с. практически те же 10+ мс, но с намного более оптимизированным под веб-дев инструментарием.

Ну это понятно, если надо что-то большое, одним опенрести сыт не будешь... А если стоит nginx и надо что-то мелкое и по быстрому, то почему бы и нет

угу, но не хватает ещё одного "если": если уже есть под рукой хорошая/удобная библиотека для вебдева. типа там, парсинг запросов, защита от инъекций, форматирование ответов, и т.п.

угу, но не хватает ещё одного "если": если уже есть под рукой хорошая/удобная библиотека для вебдева. типа там, парсинг запросов, защита от инъекций, форматирование ответов, и т.п.

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

Ну там, тебе нужна авторизация/парсинг запросов/защита от инъекций и форматирование ответов? Мути на php. Нужны сложные штуки типа ускоренного ресайзинга картинок через imagemagic? Вот тебе специальный адрес для этого, где всё калькулируется на луях. В моём примере, в одних случаях грузится http-шка, в других - скрипт lua как текст (для моего webrequire), в третьем - выполняется скрипт на луях. Ну, ещё лишняя плюха для css. Регулярки тащат.

да я к тому, что чтобы сделать хоть что-то серьёзное, уровня выше, чем "поделка на коленке", нужен нормальный веб-фреймворк с парсингом сырых запросов/ответов, работы со всякими там chunked encoding, gzip и т.п. а иначе оно так и останется на уровне "ма! смотри как я могу!" =)

да я к тому, что чтобы сделать хоть что-то серьёзное, уровня выше, чем "поделка на коленке", нужен нормальный веб-фреймворк с парсингом сырых запросов/ответов, работы со всякими там chunked encoding, gzip и т.п. а иначе оно так и останется на уровне "ма! смотри как я могу!" =)

>chunked encoding, gzip Это как раз отлично готовится на луях. Хз как там с php7, но это офигенно быстро. С JIT-кешированием - гарантированно офигенно быстро. Учитывая подрубание сишных либ. Если научиться в FFI - к твоим услугам будет всё что уже изобрели для C/C++. Это гарантированно больше и быстрее php7. Хотя мб не такое сахарное, но сахар можно мутить на стороне lua.

ключевое слово - "будет" =) ну, и когда всё это действительно будет, получится "тот же РНР, только не РНР, но прям почти как РНР" =)

Тут прекол в "ма смари я умею в микросервисы, пережёвывающие пяцот тыщ запросов в секунду с матаном и лазаньем в бд". Да, надо пилить то что тебе нужно, потому что луи пока не доминируют в вебе, хотя ничто особо не мешает заменять ими жаваскрипт с пхп, кроме поддержки луёв в браузерах : ) Другое дело, что если луи станут популярными - появится огромная тонна говнобиблиотек, написанных криворукими макаками, поэтому придётся десять раз думать, что выбирать, вместо того чтобы брать то что нашёл, ибо сейчас - почти гарантированно всё ок. Общество расширится до всякой гопоты, которая вчера впервые открыли учебник роберто иерузалимши, из-за чего общество (за редким исключением) перестанет быть таким милым и отзывчивым, появятся толпы говнофреймворков с мерзейшим АПИ, и не будут брать на работу без знаний десятка этих мудацких штук. Всё как в JS : ) https://habrahabr.ru/post/321864/

>chunked encoding, gzip Это как раз отлично готовится на луях. Хз как там с php7, но это офигенно быстро. С JIT-кешированием - гарантированно офигенно быстро. Учитывая подрубание сишных либ. Если научиться в FFI - к твоим услугам будет всё что уже изобрели для C/C++. Это гарантированно больше и быстрее php7. Хотя мб не такое сахарное, но сахар можно мутить на стороне lua.

в луа полно сахара