Новый 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 задепрекейтили

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