Open movpushmov opened 20 hours ago
И питона
Половина всего кода движка - интеграция с LuaJIT с соответствующими оптимизациями, обеспечивающими максимальную производительность при правильном использовании. В представленном по ссылке сравнении я не вижу никаких упоминаний LuaJIT, что используется в движке и демонстрирует крайне высокую производительность, в сравнении с обычным Lua. Так что пока не вижу убедительных причин рассматривать предложенный вариант.
Просто напомню, чистый Lua, без JIT, в проекте тоже не рассматривается, как и не поддерживается на уровне API проекта.
Половина всего кода движка - интеграция с LuaJIT с соответствующими оптимизациями, обеспечивающими максимальную производительность при правильном использовании.
не понял смысла этого тейка) работа разных машин исполнения едва ли будет аффектить друг друга
стоит упомянуть, что я не предлагаю вырезать и сжечь всю часть с луа, просто задался вопросом, могу ли я попытаться интегрировать JS)
Так что пока не вижу убедительных причин рассматривать предложенный вариант.
не разобран тейк с популярностью JS'a на рынке, что явно поспособствует притоку аудитории
Ну, если нет, то ок + можешь закрывать)
Попытка №2
не вижу никаких упоминаний LuaJIT, что используется в движке и демонстрирует крайне высокую производительность
полностью не читал, только циферки глянул, поэтому мог неправильно интерпретировать информацию
Это к тому, что интеграцию каждой существующей скриптовой функции нужно будет продублировать для интерпретатора JS + введение ряда дополнительных уровней абстракции для скриптинга, что только в идеальном мире не приведёт к ухудшению производительности в обоих языках.
А в последнем скриншоте Попытка №2
почему-то приведена Java, которая, как-бы не JavaScript, а другой язык, причём старой версии, что совсем не является скриптовым ЯП. Node JS же является браузерным движком.
Это к тому, что интеграцию каждой существующей скриптовой функции нужно будет продублировать для интерпретатора JS + введение ряда дополнительных уровней абстракции для скриптинга, что только в идеальном мире не приведёт к ухудшению производительности в обоих языках.
тут не уверен, что имею достаточную экспертизу, чтобы поспорить с тейком или поддержать его
насколько я слышал от знающих, можно наколдовать с LLVM и будет сильно проще подключить любой из огромного множества языков (вроде как)
А в последнем скриншоте
Попытка №2
почему-то приведена Java, которая, как-бы не JavaScript, а другой язык, причём старой версии, что совсем не является скриптовым ЯП.
а node.js 16.4 это не JS?) причём нода намного тяжелее, чем чистый V8
ну типо можем сделать в отдельной ветке и проверить, насколько это будет хуже)
если при норм перфе у этого есть шансы заехать в основную репу
если нет, то как бы и нет смысла как будто обсуждать
В любом случае, почему бы и не попробовать. Я и сам постоянно пробую различные оптимизации, так как производительность - это один из основных приоритетов проекта. Просто не нужно забывать про то, что проект уже требует обеспечения совместимости с прошлыми версиями, а лишнее легаси замедляет движение разработку проекта.
В любом случае, почему бы и не попробовать. Я и сам постоянно пробую различные оптимизации, так как производительность - это один из основных приоритетов проекта. Просто не нужно забывать про то, что проект уже требует обеспечения совместимости с прошлыми версиями, а лишнее легаси замедляет движение разработку проекта.
тогда как будет время и силы я попытаюсь занести ПР, а там глянем)
есть конкретные методички, как замерять производительность?
Сейчас из средств замера производительности есть лишь класс timeutil::ScopeLogTimer
- хедер util/timeutil.hpp
.
На ближайшие обновления я планирую ввести в движок Unit-тесты, имеющие полный доступ к API движка, которые можно выполнять в headless режиме GitHub Actions, что буду реализовывать самостоятельно.
Связан ли ваш запрос на добавление функции с проблемой? Пожалуйста, опишите. нет
Опишите желаемое решение Можно использовать V8 с libuv и встроенной поддержкой TypeScript для комфортной разработке на JavaScript, это расширит круг людей, которые могут создавать контент
Так же судя по тестам JS намного быстрее
Опишите альтернативы, которые вы рассматривали можно было бы попытаться использовать node api или bun, но они node тяжёлый, а bun не стабильный
Дополнительный контекст