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

так что верхний потолок в лучшем случае 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/

Добро пожаловать в чат pro.lua, terminate all! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

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

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

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

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

Ну там, тебе нужна авторизация/парсинг запросов/защита от инъекций и форматирование ответов? Мути на 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.

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

для веба

Кстати, в openresty есть приличного размера база для веба, это как факт. Кодирования/декодирования есть, доступ в БД - есть, генерация шаблонов - тоже есть. Экранирование SQL и прочих запросов - ясен хрен. Уже написали : 0

MoonScript чем не сахар

ERROR: S client not available

такое случится только если луа начнёт покидать свою нишу (как и жабоскрипт, да) =) а ниша - это лёгкий скрипт, встроенный в большую систему, лишь СЛЕГКА изменяющий её поведение. в смысле, писать ОС на луа или целую игрушку со всей графикой и т.п. - можно, но это, по-моему, большая ошибка. модуль АИ, например, в той же игрушке - вполне себе ок

такое случится только если луа начнёт покидать свою нишу (как и жабоскрипт, да) =) а ниша - это лёгкий скрипт, встроенный в большую систему, лишь СЛЕГКА изменяющий её поведение. в смысле, писать ОС на луа или целую игрушку со всей графикой и т.п. - можно, но это, по-моему, большая ошибка. модуль АИ, например, в той же игрушке - вполне себе ок

openresty очень хорош

я даже не спорю с этим. конечно хорош =)

ибо в LuaJIT скорость почти как у чистых Сей + он прост для понимания

такое случится только если луа начнёт покидать свою нишу (как и жабоскрипт, да) =) а ниша - это лёгкий скрипт, встроенный в большую систему, лишь СЛЕГКА изменяющий её поведение. в смысле, писать ОС на луа или целую игрушку со всей графикой и т.п. - можно, но это, по-моему, большая ошибка. модуль АИ, например, в той же игрушке - вполне себе ок

Хе-хе, ты это говоришь человеку, который на jit пишет игрушки включая графику и всё остальное : 3 Love2d - тянет то что не тянут юнити (по шейдерам и постпроцесингу, например).

Будет ли юзать openresty каждый второй пхпшник - нет. Хорошее ли это решение для хайлоада - да.

вот именно, чтоб писать с луажит-ом, нужно ещё знать Ц. но ведь можно просто сразу забабахать модуль для энжинкса на Ц и жить счастливо. и для высоконагруженного проекта так будет даже лучше, не? =)

Зачем?

Если не выходить в ffi

Не нужно знать Ц чтобы просто писать на луаджыте. Оно и так будет трассироваться-компилиться.

луажит можно юзать без Ц

а писать сайт на Си слишком неподдерживаемо

В сайте написаном на луа разобраться проще чем в сях это очевидно

Считай что на Ц там только вставки, если тебе нужны всякие извращения вроде юзания с++-либ, на которых ещё не написали биндинг.

Хе-хе, ты это говоришь человеку, который на jit пишет игрушки включая графику и всё остальное : 3 Love2d - тянет то что не тянут юнити (по шейдерам и постпроцесингу, например).

я ж не говорю, что нельзя. можно! но это, с моей точки зрения (!), выход из ниши уже =)

Ну, кстати да. Я вообще довольно сильно извращаюсь с луями. Кстати, ты в курсе, что jit отлично себя показывает на микроконтроллерах? Луа такая маленькая - чтобы быть встраиваемой в микрухи.

есть, вон, пацанчики, которые ОС на жабоскрипте пишут. можно! получается! но это ж ой =)

и простое апи чтоб встраивать во внестраивоемое

именно! на МК луа вообще должна цвести и пахнуть =)

На счет встраивоемости, жс можно встроить используя Duktape но он слишком молод

Ой мама : ) Но тут одна большая разница между жытом и жаваскриптом: жаваскрипт тормознутый и делает кучу вызовов. Луажыт - быстрый и на лету компилится, разница с сишками и плюсами только в чуть более медленном запуске приложений, и невозможности вставок на асме (разве что как раз dll/so подрубать)

Как вообще удается заводить жит на микроконтролерах?

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

Он же привязан к архитектуре

есть и JS на микроконтроллерах

там интерпретатор скомпилен и во Flash сидит

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

Ну, а вставки на асме, для оптимизаций? Плюс, простите, но слой браузера - это уже жесть : ) Браузер - изначально не рутовое приложение.

емнип

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

но там дохренища памяти, чуть ли не полмегабайта, причем 300 КБ уходит на интерпретатор (емнип).

эх, а раньше искренне верили, что "640Kb ought to be enough for anybody" (c) =)

Maxx: Выстрелы себе в ногу, куча неочевидных действий для оптимизации и всё такое. Жабаскрипт слишком ногострелябелен. GNU/Плюшка: Микрухи сейчас с 2-4мб памяти есть, а к некоторым можно и флешку с кодом произвольного размера подрубать, подгружая необходимые модули на лету, получая логику произвольной сложности.