Новый js runtime mtjs

А мы(человечество) разве не пришли к такому «моменту», что по сути скорость выполнения кода уже «не важна»?

Частично. Иначе всякой муры(хттп/жсон/хмл/любой другой текст, жс/жава/руст/прочая скриптуха, веб/субд-серверы, тцп/тлс) не существовало бы.

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

Но ты можешь попробовать собирать софт с O0(и не гцц, а тиниц или чем-то подобным, лучше как можно более древним), выпилить житы и прочие попытки добавить скорости. Это конечно очень далеко от состояния «скорость кода не важна», но типа первая стадия экспиремента.

Ну хости условную телегу на «норм компе», чо.

Ну вот как раз ТГ это пример «программы», которая настолько крупная, что какой «быстрый» язык не бери, да хоть на ассемблере пиши…

Все равное придется делать «масштабирование» и «разбивать софт и данные» на несколько серверов по всему миру…

Так что возвращаясь к теме этого топика. ИМХО, но все эти «супер быстрые языки и вот это все». Ну «не особо нужны». Если в итоге эти «инструменты» неудобные и усложняют разработку и поддержку ПО… или еще хуже: начнешь писать на них чо-нибудь, а через пару лет этот инструмент «умрет» и перестанет поддерживаться…

Лучше уже взять условно говоря какую-нибудь: Java спрингбут и все такое…

Но зато это будет гарантировано проверенная «технология», которая скорее всего не умрет в ближайшие 10-20 лет…

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

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

Но зато это будет гарантировано проверенная «технология», которая скорее всего не умрет в ближайшие 10-20 лет…

Что значит «проверенная технология» и «не умрёт в ближайшие 10-20 лет»?

Если посмотреть за развитием отрасли, то можно увидеть, что за редким исключением, срок жизни технологии как раз около 10-20 лет. За исключением каких-то базовых и/или суперудачных идей.

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

Если же где-то сервис завязан на пропиетарную технологию, то без обновлений и поддержки от вендора, будет тяжело до невозможности.

В начале 2000-х на одном заводе видел PDP-11, которая работала без остановки лет 30-40. При любых ремонтах, изменениях в ДЦ завода, приходилось как-то извращаться, и придумывать схему, как произвести ремонт в обход неё, потому что все уверены, что если она выключится, то уже никогда не включится снова.

Лучше уже взять условно говоря какую-нибудь: Java спрингбут и все такое…

Ну, не знаю, мне кажется не лучший выбор. Популярность Java уже прошла, причём прошла, мне кажется, лет 10-15 назад. Да, мне тут будут доказывать, что есть и сервисы и предложения о работе. Но это уже легаси. Работать можно, только неприятно. Все ушли куда-то вперёд, а ты возишься с тем, что никому не интересно, и у которого пускай ещё долгая, на десятилетия, но всё же дорога на погост.

Ну так ты же продукт продаёшь, а не результаты тестов. Если CMakeLists кривые так что его нельзя собрать и опакетить, то какой смысл дальше смотреть?

А так, нарисовать тесты и выложить малварь под видом «js рантайма» любой дурак может.

А мы(человечество) разве не пришли к такому «моменту», что по сути скорость выполнения кода уже «не важна»?

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

Ну тесты показывают, что сервер на boost.asio тормознее js в 2.5 раза

ты бы ещё покринжовее пример нашёл

boost - практически синоним говнокода, пример как делать не надо

boost - практически синоним говнокода, пример как делать не надо

Не везде так. Буст проник в стандарт и отравил его, если ты не юзаешь std::shared_ptr, то сразу расстрел. Поэтому я сейчас рассматриваю вариант работы на чистых сях. Проще фаллоимитировать классы, контрукторы, деструкторы на сях, чем устраивать хиливары по теме буста и его говна в стд..

на докерхабе дохрена малвари, ты каждую сборку проверяешь чтоле?

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

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

В Proxmox Perl ещё очень даже жив. Не уверен, что сами разработчики этому рады, но ключевые части продукта пока на нём. Сильно не слежу, но думаю, что желание переписать на Rust (у них есть опыт) там может быть. В Debian тоже некоторые базовые компоненты не спешат переписывать с Perl на что-то другое, но тут возраст проекта намного больше, и это выглядит как классическое legacy.

Знаю. Proxmox недавно выделил 10 тысяч евро на развитие Perl.

Ещё знаю, что значительная часть Booking.com когда-то была написана на Perl, и вряд ли им удалось всё переписать.

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

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

Но понятно, что десятки миллионов строк кода уже написаны, и будут жить ещё десятилетиями - что там говорить, если до сих пор в США, Австралии, Новой Зеландии, живы проекты на КОБОЛ.

Я привык под расстрел пускать за использование std::shared_ptr.
Места, где бы он был полезен (в текущей его реализации) днём с огнём не сыщешь. Это должно быть многопоточное приложение, нетребовательное к производительности, в котором этот самый шаренный указатель будет дёргаться с разных потоков без захваченного мьютекса. Так что ты привёл пример, только подтверждающий бесполезность boost.
Более полезными альтернативами можно назвать:
1. Всё то же самое, но без попыток сделать thread safety. Конечно неэффективно, но дёшево и сердито. Многопоточный код всё равно может захватить мьютекс пока работает с объектом
2. Андройдовый wp/sp, который реализует аналогичную штуку, но ref counter хранит внутри объекта, на котрныц указывает. Даже многопоточный вариант будет эффективнее т.к меньше шансов false sharing, а размер указателя там как у обычного указателя получается
3. Другие способы управления памятью вроде пуллов или gc. Здесь нет основного недостатка: каждый доступ к указателю не делает ложного условного перехода в деструктор

Что же касаиельно STL - так он вслед за бустом тянет неудачные решения одно за другим, да и вообще был всегда скорее примером как можно сделать, а не реальной рабочей реализацией. Чего стоит то, что увеличение std::vector не может использовать realloc? Любой чувствительный к производительности проект рано или поздно делает свой вектор с блекджеком и кастомным аллокатором

Я привык под расстрел пускать за использование std::shared_ptr.

Не слыхал что такое бывает, может еще скажешь, что ты не муваешь std::unique_ptr? Вот это ппц ебанина, даже похлеще шаред_птр.

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

Вот за это респект, прям как с языка снял. Я цитату твою пожалуй спизжу.

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

У меня на уровне фреймворка дает 680к рпс, жс - 480к. Топ раст или гошка фастхттп - 800к. Ненамного отстаю.

3. Другие способы управления памятью вроде пуллов или gc. Здесь нет основного недостатка: каждый доступ к указателю не делает ложного условного перехода в деструктор

Мне понравилось как сделано в quickjs. Ручками инкать рефкаунтер. Довольно неплохо отлаживается на сях, поскольку шаблонно все и ошибка сразу видна. Я неплохо наблатыкался, хотя признаюсь честно память в моем жс немного течет, надо еще с бубнами танцевать, люблю чтобы был полный фертиж

unique_ptr не удобен в использовании, но не имеет проблем с эффективностью (есл нормально реализован). Реализации в STL я не смотрел, пользоваться умею, но в своих проектах не использую т.к предпочитаю избегать динамической аллокации по возможности. Т.к up не предполагает доступа из разных мест, то по идее там не должно быть какой-то избыточной синхронизации
В STL одно хорошо: можно написать на нём прототип, потом заменить реализации на сторонние, совместимые с ним по API, убрав какие-то излишества.
Но мне в его апишке даже стиль кода не нравится, потому обычно пишу что-то своё (но это уже моя личная хотелка)

В чём основной плюс gc перед прямым управлением памятью: тяжёлый код деструкторов вызывается отдельно и не забивает кэш процессора. В случае с shared_ptr я ещё сталкивался с раздуванием кода из-за инлайнинга деструктора. Можно вставить noinline, но это не избегает анализа потенциального вызова деструктора компилятором и возможности неправильноой оценки вероятности. Получается, ещё это надо обмазывать likely/unlilely.
А с gc деструкторы вызываются отдельно. Можно даже гонять в отдельном потоке их.
Ещё gc высвобождает память пачками, увеличивая вероятность больших непрерывных участков освобождённой памяти. Это уменьшает фрагментацию и потребления памяти в целом.
То же касается и пуллов - если модель данных ложится на пулы, можно деструкторы дёрнуть для всего пула сразу, избегая пляски с рефкаунтерами в процессе

В managed языках «деструкторы» у объектов - обычно довольно плохая идея кроме очень ограниченной пачки сценариев. В той же Java например натыкались с финализацией и метод finalize у Object задепрекейтили

А как освобождать внешние ресурсы, связанные с объектом?

Например можно хранить weak ссылку на объект в некотором реестре (а-ля «все открытые файлы»), в котором периодически проверять ассоциированным с ним cleanup thread(-ами) что ссылка жива и что например тот же файл не держит еще один объект и закрытием его в «деструкторе» одного мы не поставим в неловкое положение другой объект, ожидающий что файл-то точно его и открыт. Если умрет и владение было эксклюзивным - освобождать ресурс. Но это в самом крайнем случае - в 95% случаев условного try with resources хватит с головой

С одной стороны это та же финализация, только на уровне нашего приложения, а с другой - мы сами управляем ее стратегией и не забиваем системный кривой finalizer thread. Ну и эта стратегия, повторюсь, для самых экзотических сценариев - обычно все решается try with resources в правильном месте

я думаю можно попробовать в ГЦ, только на thread_local. Чтобы не париться с блокировками. Кстати под капотом маллока пользуется мутекс,

Ну вот интересный способ недавно обсуждался - отдельный тред, котррый пробегается по пулу объектов, смотрит у них reference counter и удаляет объект, если он обнулился. Получается, никаких блокировок (ну кроме аллокатора) и максимально эффективно используется кэш процессора. Это же получается как finalize? Ну разве что мы можем начинать финализацию непосредственно при обнулении у некоторых объектов - дабы гарантировать высвобождение внешних ресурсов сразу, до запуска gc. А в случае кастомного аллокатора можно и в нём блокировок избежать используя какую-нибудь lock-free структуру

Деликатный вопрос. А кто автор этого рантайма? Вы?

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

Да я. Короче скоро выложу сорцы наверно. Eще fs воткну асинковый и может БД одну с разными адаптерами, тоже асинковый. Идея построить какой-то бизнес вокруг этого явно отдает утопией. Даже для выдачи в гугле надо бабки платить google.ads

Вроде работу нашел, только на чистых сях. Able я c++, если честно. Там сразу начинается все говно бустовское. Мне проще инкать рефкаунт ручками в чистых сях, как Беллард это делает в quickjs. Типо так явно быстрее разрабатывать, нежели устраивать холивары вокруг современного c++.

ЗЫ. Eще фетч надо из курла сделать

мютекс там как раз не обязательно, достаточно будет атомиков.
Мютекс нужен чтобы заблокироваться на ожидании ресурса. gc не надо блокироваться, он пропустит ресурс и пойдёт проверять следующие. Конечно можно сделать мьютекс и try_lock, но по идее atomic_bool с указанной семантикой доступа должно хватить. В случае аллокаторов/пулла нужна ещё threadsafe структура, позволяющая гарантированно перейти к следующему объекту, если тот занят. То есть скорее всего там какие-нибудь next pointer'ы тоже должны быть атомарными

В сорцах маллока именно что есть мутекс. К чему он там не разбирался. Eсли thread_local, то там вообще мутексы не будут нужны, атомики тоже. Я делал тест мутекс vs атомик. Atomic вышел всего в 2 раза быстрее, хотя понятно, что тест специфичен. Т.е. атомик - не панацея ни разу.

так malloc - не gc. Ему нужно дождаться аллокации и освобождения.
я же про кастомные пулы с gc, в которых вместо free deref, а потом отдельный поток сканирует пул и чистит уже unreferenced объекты периодически

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

У меня такая архитектура - service oriented, event driven. Eсть куча сервисов, каждый из который есть eventloop, но он однопоточен, т.е. внутри сервиса нет локов. Eвент прилетает в сервис и мутекс есть только на очереди событий сервиса, больше нет. За счет этого идет минимизация локов до минимума и за счет этого скорость. Чистый фреймворк выдает скорость 680к рпс, внутри js он же выдает 480к. Гошка на фастхттп выдает 800к. Но с учетом того, что у меня service oriented все выглядит довольно неплохо. Писать на такой архитектуре сложные проекты - милое дело. Наружу сервиса торчат только события. Их отрабатываешь и все.

Поэтому у меня легко делается тот же телнет. Это просто послать в сервис телнет событие registerCommand. RPC я считаю неплохо сделан. Запоминание маршрута есть. Eсть еще облако иерархическое, но я к нему врапперы на js не делал. Eсли кому сильно надо будет - можно сделать.

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

Атомик это по сути тот же мутекс, только видом сбоку, ненамного быстрее

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

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

Фишка в том, что директор действует на мейнстриме, он не вкупается в непроверенные вещи. Проверенные вещи те, которые раскручены, то есть в которые вложены охулиарды денег в рекламу.

Пример - я умею лечить хронические болезни, но никто из обычных людей не вкупится, пойдут к врачам и благополучно сдохнут. Реклама все решает. Бюджет на рекламу должен отбиваться схемой бизнеса. Eсть вещи, которые вкатывают в бизнес, а есть те, которые не вкатывают, даже если они лучше. Поэтому нужно оставить программирование для удовольствия. На работе нужен только говнокод - кафки, редисы, раббиты и т.п. Вот выбился js в язык для бекендов - можно его, но только node.js

У меня был случай в практике - я написал видеоплейер на libsdl2 за пару недель. Инвесторы меня решили проинспектировать силами одного эксперта. Он задал вопрос - почему ты изобретал велосипед и потратил деньги инвестора вместо того, чтобы закостылять на VLC. Аргумент, что я потратил всего 2 недели вместо полугода как минимум в случае VLC - не возымел никакого действия. В итоге я проиграл. Поэтому все сложно. Из-за этого проекты в большинстве своем разваливаются. Но это жизнь - деньги пилятся. Эффективность программирования оценивается исключительно количеством заработанных (распиленных) денег, а не качеством кода.

Попробую поэкспериментировать с аллокаторами на mtjs. Самому интересно стало.

Фишка в том, что директор действует на мейнстриме, он не вкупается в непроверенные вещи.

Ну хорошо, вы меня убедили. Тогда так: если бы я был техническим директором крупной софтверной компании…

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

Пример: вы просто аноним из Интернета. Где могут быть гарантии, что вы не шизик или не мошенник, пообещавший вылечить болезни, но на самом деле, лишь вообразивший, что может вылечить?

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

На работе нужен только говнокод - кафки, редисы, раббиты и т.п. Вот выбился js в язык для бекендов - можно его, но только node.js

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

У меня был случай в практике - я написал видеоплейер на libsdl2 за пару недель. Инвесторы меня решили проинспектировать силами одного эксперта. Он задал вопрос - почему ты изобретал велосипед и потратил деньги инвестора вместо того, чтобы закостылять на VLC. Аргумент, что я потратил всего 2 недели вместо полугода как минимум в случае VLC - не возымел никакого действия.

Здесь слишком мало информации, чтобы оценить. Непонятно, какая именно была задача, и что было сделано.

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

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

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