Новый js runtime mtjs

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

Ты хотел сказать «все возможные в рамках логики кода типы» aka type return_type = type1 | type2 | type3 ...? Вообще, это может быть полезно, но не в случае жс. Точнее, полезно может быть не это, а мономорфизированный код как в С++. Это минус динамичность жс’а(и минус жс-рефлексия/интроспекция).

А простое знание множества типов ничего не даст.

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

Нет, просто object оно в typeof, а не в вм. Вм о структуре знает. Можешь посмотреть, как в жс делают копирование/сравнение объектов - там как раз полный обход этой структуры. Чем эта структура представлена не важно.

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

Это никак не вяжется с выше сказанным «заранее». Жит это не заранее. Жит вообще противоречит знанию типов заранее.

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

Жит это не заранее. Жит вообще противоречит знанию типов заранее.

язык статический(и тогда жит не нужен)

Расскажи об этом джавистам

Запушаю сампл, смотрите

ага лоханулся, дебужную версию затестил. Релизная ровно в полтора раза быстрее моего.

Но блин, буст то куда? В 5 раз медленнее раста.

Скорость как у го на фастхттп. Быстрее даже чем мегатрон. Придется мне его оптимизировать.

Усервер в отстое, как и все плюсы

Расскажи об этом джавистам

Ну а что именно я должен им рассказать? Что у них тоже рантайм рефлексия/интроспекция, как и в жс, поэтому и там и там жит? Они это и без меня знают(наверное).

А вообще верно - java язык не статический. И дело здесь не только в рефлексии. Можешь посмотреть как там реализован полиморфизм - генериками, основными свойствами которых являются динамический диспатч и потеря точного типа.

Кстати, это неплохой пример на тему того, что ты хочешь от ts’а. В java все эти типы(возврата и прочие) известны vm(все возможные имеется ввиду). Но производительности что-то нету. Дай бог тот самый жс обгонит.

ts - это не язык по сути. Это вспомогательный препроцессор для js, чтобы проще бы писать, чтобы можно было задать подсказки для IDE и т.п. У js неплоха концепция. Eсть JSValue - под ее капотом может быть что угодно, включая функции. Удобный механизм async. Как ни крути, то промисы в плюсы перекочевали из js. Не удивлюсь, что реализация js style асинка будет быстрее, чем у плюсов, поскольку в js для этого есть довольно простой механизм. Что там приходится городить на плюсах - еще не разбирался. Чисто по интерпретируемости - что нужно для вызова функции? Нужно по имени найти в мапе jsobject параметра, функции, передать его в JS_Call и все. В принципе не сказать, что так уж много операций. Проблема в том, что современные плюсы провоцируют городить огород, если чел неопытный, то он однозначно сольет js. Вот берем команду Яндекса, вроде программисты топовые, но сливают же.

ts - это не язык по сути.

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

У js неплоха концепция.

Плохая.

Eсть JSValue - под ее капотом может быть что угодно, включая функции.

Ну да, тип динамический, производительности нету(даже с житом), TypeError в рантайме. Вон выше как раз хотели от всего этого уйти(правда неудачно).

Да и это есть в любом динамическом языке. Да и даже в статическом тоже. Гордится здесь совсем нечем.

Удобный механизм async.

Который не нужен в нормальном языке.

Проблема в том, что современные плюсы провоцируют городить огород

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

если чел неопытный, то он однозначно сольет js.

Сравнение как обычно топовое - в стиле жопу с пальцем.

Вот берем команду Яндекса, вроде программисты топовые, но сливают же.

Понятия не имею, сливают или нет. Я задам один вопрос: за счёт чего?

-> Который не нужен в нормальном языке.

Ну как не нужен то. Утилизация процессоров по максимуму. В плюсах на мультитреде сразу такая дичь начинается. Могу рассказать. Причем сообщать лиду о концептуальных ошибках моветон.

-> Ну ты ничего не знаешь о современных плюсах. Да и в целом о языках.

Как сказать.

-> Который не нужен в нормальном языке.

Асинк в js сделан простенько и со вкусом. Иначе бы js не оттяпал 40% рынка бекендов.

-> Понятия не имею, сливают или нет. Я задам один вопрос: за счёт чего?

Ну бенчи погоняй. У меня есть и для усервера тоже. Чуть быстрее гошки с простым net/http. Eсли берем fasthttp, то сливает гошке почти в 2 раза. Мало того, моему js сливают на 7%. жс слить это как-то не айс, согласись. Это они еще молодцы, я их вскипишил, они оптимизировались, обогнали гошкин net/http. До этого и ему сливали.

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

Вот 400к рпс на поток (сумма 800к) у фастхттп го и у раста - это сразу внушает уважение. Это называется уже искусство программирования.

Посмотрел исходники твоих тестов… Складывается ощущение, что я пропустил появление нового жанра - стэндап в гитхабе с шутками про жопу.

Это я еще не выложил исходники рантайма. Там вообще обхохочешься

Утилизация процессоров по максимуму.

Никак к асинку не относится.

В плюсах на мультитреде сразу такая дичь начинается.

В жс нет мультитреда. Хотя не так давно вроде была какая-то подготовка/попытки, чем кончилось не знаю - не следил. В любом случае у тебя снова неверное сравнение.

Как сказать.

Ну здесь как не скажи. Возможно, у тебя просто мало опыта/слабый бэкграунд/кроме скриптоты ничего основательно не пробовал. Но современный С++ - единственный полноценный язык, причём самый выразительный. И огорода там минимум.

Но распробовать вообще тяжело, да. Скорее всего сказывается уникальность парадигмы и множество рудиментарных методик(и при этом популярных до сих пор). Можешь поискать треды с царём здесь, на лоре - многое потёрто, но кое-что ещё осталось. Более скиловых пацанов я здесь не видел(да и не только здесь).

Иначе бы js не оттяпал 40% рынка бекендов.

Про долю не скажу - мне не известно. 40% сомнительно на самом деле. Но оттяпал он не из-за своих качеств, а по причине того, что очень удобно писать бэк и фронт на одном языке. А на фронте только жс(до относительно недавних пор, по крайней мере).

Ну бенчи погоняй.

Ну это мало что значит на самом деле. Бенчи есть - это хорошо, как бы необходимое условие, да. Но это даже не половина дела. Тебе ещё нужно результаты этих бэнчей правильно истолковать. А то полно бэнчей io/ffi, из которых делается вывод «язык (не)сливает», но это неверно. Поэтому я спрашиваю о причинах.

За счет чего - сложный вопрос.

Вот и разгадка. Даже если ты там обогнал кого-то(в корректном сравнении, что сомнительно при разнице в разы) - это не более чем везение.

Как происходит победа обычно: ты видишь слабые места оппонентов/возможности сделать более эффективно и используешь это. Т. е. причины «быстрее» ты уже будешь знать, ещё до того, как написал реализацию. Это и есть осознанный подход.

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

-> В жс нет мультитреда. Хотя не так давно вроде была какая-то подготовка/попытки, чем кончилось не знаю - не следил. В любом случае у тебя снова неверное сравнение.

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

-> Ну здесь как не скажи. Возможно, у тебя просто мало опыта/слабый бэкграунд/кроме скриптоты ничего основательно не пробовал. Но современный С++ - единственный полноценный язык, причём самый выразительный. И огорода там минимум.

Современный C++ - аццкий отстой, особенно то, что влито в него из буста. Скажем так, std::shared_ptr элементарно тормознее в 3 раза моего смартпойнтера, имеющего куда больший функционал. Слепая вера в стандарт - такое себе.

Огород в C++ - это костыли типа std::enable_shared_from_this. Это просто какой-то ад. В итоге сампл на буст.асио тормознее js в 2.5 раза.

-> Про долю не скажу - мне не известно. 40% сомнительно на самом деле. Но оттяпал он не из-за своих качеств, а по причине того, что очень удобно писать бэк и фронт на одном языке. А на фронте только жс(до относительно недавних пор, по крайней мере).

Гуглили недавно, вроде 40%.

-> Ну это мало что значит на самом деле. Бенчи есть - это хорошо, как бы необходимое условие, да. Но это даже не половина дела. Тебе ещё нужно результаты этих бэнчей правильно истолковать. А то полно бэнчей io/ffi, из которых делается вывод «язык (не)сливает», но это неверно. Поэтому я спрашиваю о причинах.

Я же их рассказал - std::shared_ptr тормознее моего в 3 раза на конструкторе. Плюс еще архитектурные косяки. Вот и набирается. Не надо сильно надувать щеки, мол мы в комитете и поэтому самые крутые - покажите результат.

->Как происходит победа обычно: ты видишь слабые места оппонентов/возможности сделать более эффективно и используешь это. Т. е. причины «быстрее» ты уже будешь знать, ещё до того, как написал реализацию. Это и есть осознанный подход.

Бенчи - самый простой способ. Eсли ты не можешь помериться пиписькой в простом бенче, то какой смысл смотреть что-то еще? У меня код просто не имеет косяков совеременного эффективного c++, поэтому и скорость. Заметь, что гошка и раст выглядят ну очень достойно.

В жс мультитред имплементируется асинком.

Не имплементируется, а костыляется.

Выполнение асинковых функций под капотом происходит в воркерах.

Ну да, в С/С++ рантайме. В самом С/С++ никакие воркеры и асинки не нужны.

Современный C++ - аццкий отстой, особенно то, что влито в него из буста. Скажем так, std::shared_ptr элементарно тормознее в 3 раза моего смартпойнтера, имеющего куда больший функционал. Слепая вера в стандарт - такое себе.

Из буста невозможно влить что-то в язык. shared_ptr - это не язык, это либа.

Что-то вспомнилось мне одна ветка в телеге, которую я читал ранее. https://t.me/cpptogether/261878 - это не ты случайно? Там выше и ниже тоже - ветка длинная. А то тот пацан бахал свой any, который тоже был быстрее std. Напомнило как-то.

Я же их рассказал - std::shared_ptr тормознее моего в 3 раза на конструкторе.

Так это фигня. shared_ptr в «быстром» коде не используется(либо по минимуму) и выиграть на этом можно пару процентов(и то не факт). Ну и вопрос тот же самый: за счёт чего твой ptr быстрее?

Бенчи - самый простой способ.

Не, это не способ. Я тебе писал выше, что сами по себе бэнчи без верного толкования ничего не значат.

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

Как всё запущено. Мультитрединг не равен асинхронности, даже если асинхронные вызовы разбрасывать по тредам.

Ну да, в С/С++ рантайме. В самом С/С++ никакие воркеры и асинки не нужны.

Скажу по секрету, что в C++ нереализуемой задачей является задача создания элемнтарного таймера. Обычно делают так - создают поток и передают ему коллбек. В потоке спят и вызывают коллбек. Можешь загуглить, так рекомендуется официально. Что имеем по итогу - коллбек вызывается из другого потока. ОК, оставили все как есть, вышли на прод и началось - SIGSEGV. Многопоточность, туды ее. Потом доступ ко всем членам класса оборачиваем мутексами. Это через несколько лет отладки мутексов. По итогу получаем по факту однопоточную прогу, которая типо php. Инвестор - лох.

Из буста невозможно влить что-то в язык. shared_ptr - это не язык, это либа.

Это часть стандарта, поэтому по сути - это must have. Все должны им пользоваться. Eсли не пользуешься - расстрел на месте.

за счёт чего твой ptr быстрее? у шареда есть oveоверхед, который не нужен в большинстве случаев.

Так это фигня. shared_ptr в «быстром» коде не используется(либо по минимуму) и выиграть на этом можно пару процентов(и то не факт). Ну и вопрос тот же самый: за счёт чего твой ptr быстрее?

У меня сложилось впечаление, что тормоза из-за использования стандартных фич. Сильно не исследовал этот вопрос, поскольку мне лично ответ на него не особо нужен. В усервере есть паттерн защиты мутексом членов класса (мутекс - член класса), вот он кривой, поскольку к каждому доступу надо его лочить. Из-за этого все вырождается в однопоточную прогу. Видно, что просто опыта у людей маловато.

Как всё запущено. Мультитрединг не равен асинхронности, даже если асинхронные вызовы разбрасывать по тредам.

Асинк - это вполне рабочий метод раскидать по тредам и загрузить все процы. В контексте жс, разумеется. Поэтому жс и любят на бекендах. Хотя когда я услыхал первый раз про js на бекендах, я покрутил пальцем у виска. Проблема в том, что раскидываются по тредам не все асинки, а только подкапотные. У меня были идеи сделать многопоточный жс, но с учетом асинков игра совсем не стоит свеч, поскольку и так все прекрасно распределяется.

Скажу по секрету, что в C++ нереализуемой задачей является задача создания элемнтарного таймера. Обычно делают так - создают поток и передают ему коллбек. В потоке спят и вызывают коллбек. Можешь загуглить, так рекомендуется официально.

Так никто не делает, даже среди ламерков.

Что имеем по итогу - коллбек вызывается из другого потока. ОК, оставили все как есть, вышли на прод и началось - SIGSEGV. Многопоточность, туды ее.

Что к чему. Какой-то SIGSEGV взялся. Ты пытался забацать многотред на цпп и не смог? А далее пошли оправдания про таймеры, мутексы(которые в цпп не нужны, кстати) и, конечно же, SIGSEGV.

Потом доступ ко всем членам класса оборачиваем мутексами.

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

Это часть стандарта, поэтому по сути - это must have. Все должны им пользоваться. Eсли не пользуешься - расстрел на месте.

В фантазиях.

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

Я не сомневался, что ты в очередной раз сравнивал жопу с пальцем. Подкину тебе идею - забэнчь T* vs shared_ptr. shared_ptr в большинстве случаев не нужен(и это не шутка кстати, я писал ещё выше об этом).

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

Ну это типично. Зачем ответы на вопросы/связь с реальностью/доказательства, если можно просто написать на форум «я смог/у меня быстрее».

Ладно, ты просто болтаешь и не отвечаешь на вопросы(потому что ответить нечего, не потому что не интересно). Болтовня уже мне не интересна.

ну Семён Семеныч…!

+----------------+----------------------+------------------+--------------------------------+
| Компонент      | Операция             | Мин. задержка    | Примечания                     |
+----------------+----------------------+------------------+--------------------------------+
| CPU            | Кэш L1               | <100 циклов      | ~0.2-0.3 нс (3-5 ГГц)          |
| CPU            | Кэш L2               | ~200 циклов      |                                |
| CPU            | Кэш L3               | 400-800 циклов   |                                |
| RAM            | Доступ к памяти      | 50-100 нс        | Тайминги (напр., CL18)         |
| NVMe SSD       | Случайный доступ     | 10-100 мкс       |                                |
| SATA SSD       | Случайный доступ     | 50-150 мкс       |                                |
| HDD            | Случайный доступ     | 5-15 мс          | Механическая задержка          |
| LAN            | Локальная сеть       | 0.1-1 мс         | Внутри дата-центра             |
| WAN            | Глобальная сеть      | 10-100 мс        | Межконтинентальная передача    |
+----------------+----------------------+------------------+--------------------------------+

причем тут ЯП?
хоть на горилла басике пишите (шутка юмора, не пишите)
потери на передаче в сеть на порядки выше, чем все вычисления вместе взятые

успехов

Скажу по секрету, что в C++ нереализуемой задачей является задача создания элемнтарного таймера. Обычно делают так - создают поток и передают ему коллбек. В потоке спят и вызывают коллбек. Можешь загуглить, так рекомендуется официально.

Так никто не делает, даже среди ламерков.

Подтверждаю.

Мимо-LamerOk

Реакция «лицо клоуна»: static_lab

Поплыл.

Так никто не делает, даже среди ламерков. Хз у меня на одном проекте лид так рукой водил, я делал. Понимал, что говно.

Что к чему. Какой-то SIGSEGV взялся. Ты пытался забацать многотред на цпп и не смог? А далее пошли оправдания про таймеры, мутексы(которые в цпп не нужны, кстати) и, конечно же, SIGSEGV.

таймер - это база. Eсли нет решения как его сделать, то нахрена вообще c++?

Ну это типично. Зачем ответы на вопросы/связь с реальностью/доказательства, если можно просто написать на форум «я смог/у меня быстрее».

Ну я шмог и у меня быстрее того же усервера, на 7%, но за то на js, что само по себе офигенный понт. Хороший понт, как известно, дороже денег.

Тут я ничего не понял, видимо это не для средних умов

На проекте лид такой таймер делал, я тихо сползал под стол, но ничего сказать не осмелился.

Что к чему. Какой-то SIGSEGV взялся. Ты пытался забацать многотред на цпп и не смог? А далее пошли оправдания про таймеры, мутексы(которые в цпп не нужны, кстати) и, конечно же, SIGSEGV.

вызов коллебка из другого потока внезапно является мультитредом и требует оберток всего в мутексы. Либо не мутексуешь. Потом потихоньку отлаживаешь года 3 на проде и получаешь баблишко

Тут я ничего не понял

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

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

Дык в этом вся и фишка. На сети все и вылазиет

На сети все и вылазиет

и-и-и…?
вот поэтому надо сравнивать не ЯП,
а то как реализация на этих ЯП юзает сетевой стек

У jvm главная проблема, что не примитивы всегда работают по ссылке. Плюс косвенность, минус локальность.

Впрочем, у ts тоже была бы такая проблема. Но он бы всё равно был бы побыстрее, чем сейчас.

Там не только сетевой стек. Сильно важнее работа с потоками. Провисание на мутексах. То есть дело в архитектуре. Под капотом всех и гошки и раста все равно C, C++.

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

Хз. Может и так. Однако очень большая affected area

Результат в чем именно?

Давай сравнение с seastar::httpd

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

Сбилдить нереально на виртуалке, там надо гиг 20 памяти.

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

Выскажу крамольную мысль - исходники нужны не для исследования, а для того, чтобы захейтить. Меня в прошлый раз захейтили уже на уровне CMakeLists.txt. Даже никто не собрал проект. Ну и в коде нужно прибираться, форматировать, убирать закомментированный код и т.п.

Просто посмотреть 5.5 мб сорцов это как? Кто будет время тратить? Кто смотрит код nginx, curl и т.п.?

Давай сравнение с seastar::httpd

На 6гб не билдится, памяти не хватает. Там очень крутое метапрограммирование.

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

Попроси ИИ все поприбирать. Copilot в режиме edit или agent, или gemini cli, или аналог. На худой конец копипастить сорцы в chatgpt, но это муторно.

Просто посмотреть 5.5 мб сорцов это как?

Прям именно 5.5 Мб сорцов? А что говорит, например, какой-нибудь tokei?

Кто будет время тратить? Кто смотрит код nginx, curl и т.п.?

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

Так никто не делает, даже среди ламерков.

Я работал в одном проекте. Лид был препод программирования, он так делал. Я посмеялся про себя, поскольку понимаю, чем это грозит.

Что к чему. Какой-то SIGSEGV взялся. Ты пытался забацать многотред на цпп и не смог? А далее пошли оправдания про таймеры, мутексы(которые в цпп не нужны, кстати) и, конечно же, SIGSEGV.

Я знаю, как правильно надо пейсать. Можешь убедиться в этом сам, погоняв mtjs.

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

Mutex в цпп нужен в многопоточке.

Я не сомневался, что ты в очередной раз сравнивал жопу с пальцем. Подкину тебе идею - забэнчь T* vs shared_ptr. shared_ptr в большинстве случаев не нужен(и это не шутка кстати, я писал ещё выше об этом).

Рефкаунт нужен, иначе устанешь лики отлаживать. Хотя может ты фанат геморроидального стиля программирования, откуда мне знать

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

Чатам я не особо доверяю. После них проверять все нужно досконально

Прям именно 5.5 Мб сорцов? А что говорит, например, какой-нибудь tokei?

Моих 2мб, 3.5 - quickjs

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

Я закрыл код не из-за нежелания поделиться, а из-за желания заблокировать возможность захейтить необоснованно. Говорю же, выкладывал код, на котором этот рантайм основан. Обосрали уже на уровне cmakelists.txt. Никто его даже не собрал, чтобы затестить скорость. Между прочим потенциальные заказчики гуглят сначала такие дискуссии, а это прям совсем не айс.