Новый js runtime mtjs

Что это? Название левое ибо это не js runtime реализация.

outperforming modern C++ solutions

Пахнет не очень хорошо такое заявление.

В общем, я не понял что ты навайбкодил с ИИ за два дня и зачем оно нужно

Запускать левый докер-образ без исходников, вместо которых в репозитории лежат примеры?

что тут непонятного, тесты лежат в репе, бери и гоняй.

-> Пахнет не очень хорошо такое заявление.

Ну тесты показывают, что сервер на boost.asio тормознее js в 2.5 раза. Причем тут как что пахнет? Даже userver чуток тормознее js. Гоша на обычно net/http тормознее, на fasthttp сильно быстрее.

Ну если не сильно брезгуете, то можно. Так то контейнер изолирован же от файловой системы.

Тем более, что если дать исходники, то все будет обосрано даже на этапе CMakeLists.txt до тестирование дело в любом случае не дойдет

Непонятно, как такое может быть. Только из-за каких-то кривостей реализации, либо на хорошо подобранных исходниках.

Я не против интерпертируемых языков (кроме JS, JS - отвратительная дрянь, которую нам навязали производители браузеров), сам пишу почти исключительно на интерпретируемых, но каким образом интерпретатор, даже с AOT/JIT, может быть быстрее компилируемого языка? Не может никак, ещё и учитывая сборку мусора, которая не может быть бесплатной по определению.

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

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

То есть там говнокод и срезанные углы?

Ну конечно, под капотом у js должен быть качественный код. Смысл в js - верхнеуровневый интерфейс, типа как ручки/кнопок управления автомобилем. Они одинаковые у всех авто - у тазика и бугатти. JS хорош тем, что при разработке на нем сильно сложнее ошибиться, до 11 сигнала надо сильно постараться. Плюс в нем отличная асинхронная модель. Мне если честно, нравится.

-> Да, можно написать плохой бенчмарк на компилируемом языке, и хороший на интерпретируемом, и сравнить их. Но выдавать это за преимущество….

На boost.asio бенч взят официальный с их сайта, поправлен только кипалив, поскольку бенчи все на кипаливе.

Разумеется вычислительные задачи на js будут тормознее. Их можно писать на js, но он будет в 10 раз тормознее сишника. Их можно и нужно потом пихать под капот js

Говнокод - это субьективный взгляд. Обьективность - это производительность кода, стабильность и т.п. Что такое boost.asio, если он тормознее js в 2.5 раз? Явно говнокод. Но для фаната boost мой наверняка будет говнокодом.

давай на пальцах поясню…

• ты пришел с громким заявлением, что твоя реализация js рантайма быстрее остальных (включая плюсовых)

• приложил какой-то набор тестов, а не сам рантайм

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

почему пахнет нехорошо - если бы я пришел с подобным заявлением, то приложил бы «пруфов» столько, чтобы вопросов не возникало.

чтобы не показаться голословным, вот тебе пример с моим проектом - я говорю что ерланг и его сетевой стек - средневековье по перформансу. и вот я прикладываю бенчмарки https://github.com/ergo-services/ergo?tab=readme-ov-file#benchmarks и предлагаю посмотреть примеры https://github.com/ergo-services/examples, а вот сами исходники моего чудо-фреймворка https://github.com/ergo-services/ergo, который можно посмотреть, потрогать.

Показывает скорость на простом хттп сервере в 13 раз быстрее node.js.

«Простые хттп серверы» - это баловство. Я не знаю, у кого какие задачи, а у меня боттлнек в БД. Потом, если CPU-intensive боттлнеки смотреть, есть аутентификация, но она по большей части перекладывается на nginx.

А вот, как быстро сервер HTTP и джейсон парсит вообще пофиг, копейки.

Ах да, а самые CPU-intensive задачи вообще на железо перекладываются.

-> ты пришел с громким заявлением, что твоя реализация js рантайма быстрее остальных (включая плюсовых)

В докере сам бинарник рантайма присутствует. Запустить тесты - нет проблем, даже при желании мой бинарь не вылезет за рамки контейнера докера. Берете и гоняете. Сам бенчмарк - apache benchmark, запускается он внутри контейнера. Вы можете модифицировать исходники js, выдать что-то осмысленное, убедиться, что там действительно работает js.

-> приложил какой-то набор тестов, а не сам рантайм

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

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

Ты бы лучше вместо «смотрите сами» написал, почему твой рантайм такой быстрый. И вообще, что унутри? Там какой-то готовый интерпретатор js модифицированый?

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

И вообще, что унутри? Там какой-то готовый интерпретатор js модифицированый?

Чтобы обогнать v8, там должен быть крайне эффективный JIT-компилятор

node.js достаточно быстрый. Быстрей не надо. Значит не нужно.

Во первых цитаты пишутся через символ >

JS хорош тем, что при разработке на нем сильно сложнее ошибиться

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

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

Ага, quickjs, под капот запихал свой фреймворк c++ и обертки над его функционалом сделал.

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

ты если откопал золотую жилу и хочешь монопольно ей владеть, то так и пиши не дразни несчастных землекопов «ля тут чо откопал!»

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

ну так это не сюда

и чем больше ты убеждаешь «не ссцыте пцаны, тут безопастно, зуб даю!»
тем сцыкотней становится

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

quickjs

Так он же в 50 раз медленнее node по производительности js: https://github.com/ahaoboy/js-engine-benchmark

Чтобы обогнать v8, там должен быть крайне эффективный JIT-компилятор

Ага, непонятно чего ОП обижается на скептицизм и не раскрывает, чего же он там намутил. Но тесты весьма специфичны, выжать максимум rps из сервера, который ничего не делает?)

Ага, у него там в тесте на жс своя либа для сервера, которая видимо под капотом написана на С++, и минимум полезной нагрузки на самом жс. Если там добавить полезного жс кода, то вылезут проблемы с производительностью quickjs, ну и даже если бы это был v8, go и остальные компилируемые не получится обогнать. https://github.com/akakist/mtjs/blob/main/test/mtjs/t_http.js

даже при желании мой бинарь не вылезет за рамки контейнера докера

Если там, конечно, не какой-нибудь 0day docker escape, чего мы конечно же не знаем, т.к. исходников рантайма нет, а контейнер собран путем копирования неизвестно откуда взявшегося бинаря и не воспроизводим

Между этим вариантом и чудесным рантаймом в 2 раза быстрее с++, более вероятно первое.

Я уже открывал сорцы примерно год назад, мне напихали чисто на этапе cmakelists.txt. Не вижу смысла открывать, поскольку конструктива нет никакого. Чисто хейт ради хейта. Eсли нормальное отношение будет, тогда другое дело.

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

Ну насчет производительности самого quickjs - вопросы есть. Я вот в его сорцах поковырялся и немного в V8, хочу сказать, что quickjs может быть и быстрее чисто за счет того, что нет c++. Eстественно сервер - это на плюсах, очень приближенных к чистым сям. Все под капотом.

QuickJS никак не может быть быстрее V8, потому что в нём только интерпретатор без JIT. А в тестах mtjs может быть быстрее, если тесты упираются в I/O.

Ну подобие JIT там есть, я байткод компиляется, как ни крути. Eсли честно, мне сложно представить, что на V8 может быть круче. Переменные все - один хрен мапы. Конструкторы там по индексу, всяко у quickjs быстрее. Надо придумать бенч какой-то чисто под язык. Опять же там много зависит от json/regexp парсеров. без них надо

Переменные все - один хрен мапы

Если не ошибаюсь, V8 как раз может оптимизировать кучи однотипных объектов в структуры.

Ну всё, иди в гугел, хром переписывать

Короче есть тест http_rpc Прилетает хттп запрос, сервер идет налево по рпц, получает ответ и генерит ответ хттп. Чисто такой шаблонный пример типо шардинга. На сях тест работает 240к рпс. На js - 90к. Возможно идут потери на мапе id->reponse. Интересно, как quickjs делает GC. Чтобы он в нее что-то отложил, нужно постараться. Обычные сишные обьекты типо запросов - не откладываются. Кстати bun дает на хттп - 70к на поток. Это в 3 с лишним раза тормознее mtjs. Вдумайтесь - mtjs успевает сходить по рпц налево перед отдачей ответа и делает он это быстрее bun - 90 vs 70.

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

Ну сама идея js как раз пихать все вычислительное под капот. Наружу торчат только ручки управления. Пример стримы - делаю стрим, один конец втыкаю в http request, другой - запись файла. Все пролетает мимо js и чанки сразу пишутся в файл. Нужно максимально разгружать тред (eventloop) js. Со стримами можно вообще извращаться - они работают по факту в своих тредах и не грузят js. (стрим и тред по русски одно слово поток) В идеале MVP пишем на ts, поскольку это быстрее и меньше ошибок. Затем отдаем куски мне, чтобы я запихал сложное под капот. Такой подход оптимизации после mvp рабочий, как ни крути. У меня был опыт переписывания одного инстант мессенджера. Eсли устаканена вся бизнес логика, сделан клиент, то переписать - месяц. Больше занимает возня с отработкой бизнеслогики, как ни крути. А это делается на ts, без геморроя с отладкой. То есть это вполне рабочий метод для постепенной реализации адекватного высоконагруженного бекенда. Причем нет секса при отладке бизнеслогики, нет sigsegv. Сроки разработки можно просчитать, особых подводных камней там нет. Затем оптимизация - тоже без особых фокусов. Тоже можно просчитать. В итоге имеется гарантия по дедлайнам.

Опять же взять json parse. nlohmann и yyjson - 2 большие разницы. Регекспы в quickjs тормозные, можно воткнуть побыстрее, но тогда не стандарт. В сампле телнета регексп регистрации команды - std::regex. Парсим уже внутренним регекспом js. std::regexp не понимает, например, \d.

url вроде уже парсится в массив парамс в гете. Eсли application/x-www-form-urlencoded пост - то не помню точно, но допилю быстро, если не сделано. Что там еще надо - jwt сделать валидацию. Тоже можно. Пейшите, что надо. RSA, ECC. Операции взять массив из сишного контейнера - быстрые. Могу закешировать в JSValue, чтобы один раз его создавать, а не на каждый геттер. По теме jwt можно подумать как-то сразу настроить сервер, чтобы он автоматом запросы проверял. Сейчас тупо сделано хттп на все урлы, как у нода в хттп. Можно это все разграничить.

В идеале MVP пишем на ts, поскольку это быстрее и меньше ошибок. Затем отдаем куски мне, чтобы я запихал сложное под капот. Такой подход оптимизации после mvp рабочий, как ни крути. У меня был опыт переписывания одного инстант мессенджера. Eсли устаканена вся бизнес логика, сделан клиент, то переписать - месяц. Больше занимает возня с отработкой бизнеслогики, как ни крути. А это делается на ts, без геморроя с отладкой.

Так в этом случае проще или написать прототип на ts+node, а затем переписать на go или rust, или сразу на них и написать безо всяких js.

Ну так многие и делают.

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

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

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

Разве что сейчас мода пошла, например, брать сразу спеца по Python + Go (именно в таком сочетании, других сочетаний, например, Ruby + C++, или PHP + Java, никогда не видел). Допустим, Авито сейчас набирает только таких - если знаешь Python, но не знаешь Go, то максимум получаешь грейд мидла, выше не прыгнешь.

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

Кстати, до раста руки дошли.

135591.40 * 2

Почти в 2 раза тормознее какого-то сраного javascript’a.

Мне бы конечно было классно модули под заказ клепать. А то без работы оказался. 10 лет такого не было. ппц

Почти в 2 раза тормознее какого-то сраного javascript’a.

Скорее всего ты что-то не так делаешь

Отчего такой вывод?

Жс-вм и так располагает полной информацией о типах. Что там можно добавить?

Жс-вм и так располагает полной информацией о типах. Что там можно добавить?

TypeScript:

type Foo = ...

type Bar = {
    fizz?: number;
    buzz?: number;
};

function foo(): Foo {}

const x = foo(); // <- тип x заранее известен

const y: Bar = {}; // <- тип y известен, компилятор мог бы аллоцировать структуру

y.fizz = 123;

if (t < 0) {
    y.buzz = 456;
}

JavaScript:

function foo() {}

const x = foo(); // <- хз что тут будет: ссылка на объект или примитивное значение

const y = {}; // <- может быть произвольная структура, нужно аллоцировать хеш-таблицу

y.fizz = 123;

if (t < 0) {
    y.buzz = 456;
}

тип x заранее известен

В вм нет понятия заранее. Заранее это в compile time.

тип y известен, компилятор мог бы аллоцировать структуру

В жс этот тип также известен. Если ты снова про «заранее» - в жс(и тс) компилятор ничего не может аллоцировать - понятия памяти там не существует и аллоцировать нечего.

Да и случай ты привёл слишком простой. В жс есть интроспекция/рефлексия и они основаны на динамичности языка. А ты хочешь эту динамичность убрать.

В вм нет понятия заранее. Заранее это в compile time.

Вот если бы ВМ сразу могла читать и компилировать TypeScript, то она знала бы возвращаемый тип, а соответственно и тип переменной.

В жс этот тип также известен.

В жс это просто object — ассоциативный массив. Если бы компилятор располагал информацией о структуре, он мог бы сразу завязываться на структуру из двух nullable-полей и дополнительной опциональной ссылкой на хеш-таблицу с другими полями.

В жс есть интроспекция/рефлексия и они основаны на динамичности языка. А ты хочешь эту динамичность убрать.

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