🤡🤡 BLAZING SLOW 🤡🤡

Да ладно, вы и вправду подумали что я просто так это всё оставлю и не попытаюсь детально разобраться в чем же причина такой мега-скорости Bun?

В первую очередь мой острый взгляд пал на React - и в принципе я не прогадал: в марте вышло обновление 18.0 и в нём переделали Stream'ы для Nodejs в серверном рендеринге. Моментально я наткнулся на следующий Issue в github где чувак обратил внимание на то, что у него деградировал перформанс чуть ли не в 5 раз!

Почему это важно? Да всё просто - в Node используется своя версия реализации стриминга. В Deno используется другая реализация. А вот в Bun вообще нет официальной поддержки - авторы используют самопальный polyfill для стриминга отрендеренной страницы.

Поэтому, переписав код бенчмарка и заменив функцию renderToPipeableStream на renderToString результат Nodejs заметно улучшился и разрыв в среднем сократился уже до 25% — заметь, это не 300% разницы и даже не мои изначальные 45%, по результатам самых первых тестов.

Собственно продолжив копаться дальше, я обратил внимание на следующий момент: Bun с какой-то стати игнорирует Http заголовки которые указаны в бенчмарке — а Nodejs в свою очередь наоборот ДОБАВЛЯЕТ лишние заголовки. В итоге разница составляла в среднем: ~130 байт данных, которые приходилось гонять ноде.

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

В итоге разрыв сократился до 18-20% в пользу Bun — это мой максимум. Я не использовал никаких кастомных Http серверов, для меня было важно использовать средства чистой Node.js

Более того, если из этих переменных выкинуть React SSR и оставить голые байтики - разрыв будет точно таким же. Я понятия не имею каким образом сетевой код у разработчика Bun вышел на столько производительней, но факт остаётся фактом — это 20% дополнительного перформанса только за счёт I/O.

👉 IT KEKW NEWS™:
CEO Unity Software Джон Ричителло (экс CEO Electronic Arts) в интервью заявил, что все разработчики, которые не планируют включать в свои проекты монетизацию, цитирую - "Ёбаные идиоты", источник.

👉 При этом не стоит забывать, что Bun АБСОЛЮТНО не готов к Production разработке.

В процессе тестов он постоянно падал с разными ошибками, то сервер начнёт код 500 сыпать, то с Segmentation Fault упадёт, то JS код скомпилировать не сможет. Стабильности здесь НЕТ.

Ещё Bun не смог запуститься на WSL, якобы ему ядро Linux не подошло, хотя моя версия ядра попадала под системные требования.

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

К тому же, написана Bun на очень интересном языке программирования, который называется Zig (за шутки про зиги буду банить) - можешь посмотреть, прикольная штука!

👉 Знаете, разница между паттернами MVC и MVP примерно такая же как между куколдом и параноидальным шизом.

MVC(uckold) берёт модельку, знакомит её с вьюхой и наслаждается видом. В это же время MVP(araniod shiz) никого настолько жёстко не подпускает к своей модельке, что сам носится между ней и вьюхой, передавая данные.

Исправление багов в Bun идёт полным ходом. Всё Open Source сообщество сплотилось и начало усердную работу 🤡

🗞 Материалы прошлой недели

🔹 🪦 Надгробие для Internet Explorer

🔹 Интро про JS движки

🔹 Про преимущества WebKit и JavaScriptCore

🔹 Bun ⚡️ НЕВЕРОЯТНО БЫСТРЫЙ

🔹 Почему Bun такой быстрый

🔹 Unity Software ТОЧНО ВСЁ

🔹 Bun 🤡 НЕВЕРОЯТНО МЕДЛЕННЫЙ

🔹 Bun не работает как надо

Ну всё, недельная эпопея с JavaScript закончена, по такому поводу можно бахнуть 🍺🥴

Я тут, смотрю, айтишнички любят по выгорать в последнее время. Весь интернет мне засрали гайдами в стиле "Устал? Ну так пойди отдохни". Знаете, что я подумал? Раз выгоральщиков так много, значит им надо помогать.

P.S.
Ну и если я какой-то текст дочитываю до конца, то никогда не поленюсь поставить лайк и в комменте написать что-то типа: "Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?"

https://youtu.be/LOYpqjtsbic

😳 Rust способен залить в 3-х литровую банку 5 литров мочи или ВСЯ СУТЬ BENCHMARK ТЕСТИРОВАНИЯ

Анонимные источники подкинули мне контент, значит - есть web server под названием faf, что является сокращением от Fast as Fuck [вставить шутку про скорострела] - написан он на 100% с использованием Rust. В Benchmark тестах он показывает феноменальный результат нарушая все мыслимые и немыслимые законы физики.

Господа на GitHub уже обратили внимание, что физический предел протокола при данном Benchmark'е c каналом 10 gbit/s имеет следующие ограничения:
⏫ запросов - 7.2kk в секунду и ⏬ ответов - 9.4kk в секунду.

faf обработал 8.6kk запросов/ответов в секунду 🙉

Каким образом сервер смог выйти за рамки отправленных запросов — история умалчивает. Но факт остается фактом, faf отправляет ответ раньше, чем от клиента приходит запрос на сервер 🙈

ВОТ ОНА ВСЯ СУТЬ БЫСТРОТЫ RUST!
Ну и конечно же, PRESS 💩 FOR BLAZINGLY FAST

👉 IT KEKW NEWS™:
CEO Unity Software Джон Ричителло (экс CEO Electronic Arts) извинился за то, что назвал разработчиков, которые не планируют включать в свои проекты монетизацию, цитирую — "Ёбаными идиотами", источник.

Прощаем?

Каждый раз кринжую, когда читаю что-то вроде "Учи зык Х, а не язык Y, потому что он быстрее", просто потому что за одно предложение, мало чего, советчик умудряется спиздеть дважды, так ещё и дать дерьмовый совет.

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

"Скорость" определяется, в первую очередь реализацией этой спецификации. Nodejs может быть медленным, JVM может быть медленной, JavaScript быть медленным не может.

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

Никому в хер не впёрлась "скорость", если ОНА НЕ ОКАЗЫВАЕТ ЗНАЧИТЕЛЬНЫЙ ЭФФЕКТ НА ВЫПОЛНЯЕМУЮ ЗАДАЧУ. Какая разница, выдаёт тебе приложение обратную связь за 200мс или 100мс? Пользователь просто не в состоянии заметить разницу.

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

И именно поэтому рекомендовать кому-то учить какой-то язык, только потому что он 🤡🤡 БЛЕЙЗИНГЛИ ФАСТ 🤡🤡 тупейшая затея. Учите что хотите. Излишний перфоманс нужен только под узкий пул задач, для остальных достаточно будет и не самого перфомансного перфоманса.

PHP Developer moment ✌️

🤡 Тут анонимные источники подкинули закономерную претензию к моему посту про Benchmark сервера на Rust, ну типа вот - есть же HTTP/2 и вот может же сервер реализующий этот протокол отправлять файлы клиентской стороне до того момента, как браузер их запросит.

Приведу последовательность, для примерного понимания происходящих процессов. Обычная, "сильно-упрощенная" схема в классическом Http "из 90-ых", которая работает следующим образом:

Браузер запрашивает index.html ->
Сервер отправляет index.html ->
Браузер парсит разметку, строит DOM и определяет какие файлы нужно дополнительно догрузить ->
Браузер производит запрос на сервер по каждому файлу (или параллельно или последовательно) ->
Сервер последовательно или параллельно отправляет все запрошенные файлы ->
Браузер отображает страницу с учетом всех ресурсов.

Разница HTTP/2 в том, что серверная сторона может заранее определить, распарсив исходный HTML (или захардкодив их в конфиге) — какие файлы могут понадобиться клиенту и сразу же начать их отправку без дополнительных запросов с клиентской стороны.

Под файлами, там понятно — что угодно может быть, и JS и CSS и JPEG'и, вообще не суть.

Только вот проблема в том, что все эти процессы никакого отношения к бенчмарку не имеют - там, как правило, используется статичный Hello World на HTML размером в ~110 байт и без дополнительного контента в виде вышеупомянутых JPEG'ов.

Весь процесс клиент/серверного взаимодействия упрощается до примерно следующего вида:
Клиент запрашивает index.html ->
Сервер отправляет index.html ->

Более того, исходник faf открыт, это не rocket science, а элементарнейший веб сервер. Изучив код в течении 30-и секунд, сразу становится понятно, что там реализован стандартный HTTP/1.1 без выпендрежей.

И даже какой-нибудь хитровыебаный Pipelining конкретно в этом случае физику не обманет — запрос от клиента в любом случае должен произойти. Сервер не может слать ответ на опережение, ОСОБЕННО в случае использования мультиплексирования, как бы ты все клиентские сессии в единый поток не совал, это не так работает.

КАКИМ ОБРАЗОМ это вообще можно представить?

Типа, я как клиент, ОДИН РАЗ запросил страницу, а сервер по приколу решил мне заслать 10/100/1000 абсолютно одинаковых экземпляров страницы, предварительно запихнув их в один Stream? Вообще беды с башкой? 🤡

👉 Короче, пошарился в самых глубоких частях DarkNet'а и накопал чисто для тебя нормальный и самое главное — халявный гайд по сетевому кодингу в *nix, на нормальном мужицком C.

Если интересно — можешь полистать и ознакомиться, чтобы шарить в теме, и не нести дичь как 🤡🤡 БЛЕЙЗИНГ ФАСТ 🤡🤡 дебилы.

https://beej.us/guide/bgnet/

P.S.
Даже перевод на русский есть, если что. Но там старая версия, апдейты на оригинале выходят чаще, да и свёрстана она лучше.

Поэтому инглиш версия предпочтительней, рекомендую её в первую очередь.

Разработчик веб сервера faf — 4 дня назад обещал разобраться с причиной этих паранормальных явлений и пропал (видимо в параллельное измерение "Rust-Borderworld" провалился).

Я подписался на этот Issue, буду следить за обновлениями. Даже самому интересно чем всё закончится 😂👍

P.S.
А, ну и еще - я обратил внимание, что очень много интересного контента приходит от вас, мои дорогие отпищечки. Так что не стесняйтесь накидывать в комментарии подобные кейсы. Я буду периодически мониторить и отбирать самые интересные/скандальные вещи.

Всё это в последствии так или иначе перерастёт в часть публикаций здесь. Ну и отбей 👊

👉 Большинство бенчмарков, которые ты повстречаешь в интернете — всратые.

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

begin = текущая дата
// Код, у которого замеряем время исполнения
log(begin - текущая дата)

И в консольку вывалится время исполнения кода. Но на самом деле доверять этому результату не очень хорошая затея. Просто потому что на время исполнения влияет множество факторов.

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

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

Как вы думаете, обычный чел из интернетов знаком с этими нюансами? Может да, может нет. Это абсолютный рандом. Поэтому прежде чем верить бенчмаркам, ознакомься с методологией их проведения и вообще всё перепроверь сам. А то каждый рисует циферки, кто какие захочет и носятся потом со своей 🤡🤡БЛЕЙЗИНГ ФАСТ🤡🤡 хернёй по всему интернету.

По-поводу бенчмаркинга и перфоманса в кокнете могу порекомендовать доклад Андрея Акиньшина на ютабе.

👉 Тут в ядре самой безопасной операционной системы в мире нашли АНАЛЬНУЮ ТРЕЩИНУ [Это я про Linux, если вдруг кто не понял].

В подсистеме netfilter, которая является по сути фреймворком для работы с сетевыми пакетам, и предоставляет инструментарий для фильтрации трафика (прим. грубо говоря обычный системный firewall). На его базе работает известный почти всем красноглазикам iptables.

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

Крч, в зоне риска все пользователи Ubuntu-22.04, так шо если ты патч на ядро еще не накатил, то накати. А то тебя взломают злые хакеры. 🥸

📄 Материалы прошлой недели

🔶 ЛЕЧИМ ВЫГОРАНИЕ НАРОДНЫМИ МЕТОДАМИ

🔹 ВСЯ СУТЬ BENCHMARK ТЕСТИРОВАНИЯ

🔹 Не учи язык, только потому что он "быстрее"

🔹 Производительность HTTP/2 и мультиплексирование в тестах

🔹 Нормальный, бесплатный гайд по сетевому кодингу в unix

🔹 Про всратые бенчмарки

🔹 Злые хацкеры взломали linux. Вычёркиваем.

Всем чиловых выходных🍦🥴

Ну и если у тебя есть какой-то интересный материал, новость или инфоповод, закидывай его в комменты, самое интересное на следующей недельке разберем👇

👉 Вот, знаешь, некоторые неопытные молодые люди регулярно спрашивают про не слишком распространённые платформы/языки. Они делают это для того, чтобы попытаться влезть в программирование через низкоконкурентную нишу. Типа, "вот ща, выучу Q#, через 10 лет весь рот в квантовых компьютерах будет и сразу станут нужны квантовые программисты! Я буду такой востребованный! Мне будут платить миллиарды и никакой конкуренции, недобор же!".

Если у тебя когда-нибудь возникали подобные мысли, то соре. Ты закомплексованный омежка, который ссыт вступить в конкуренцию с челами, которые ложкой в рот попадают через раз. Вместо того, чтобы пердолиться со скалой или эликсиром, возьми старую добрую Java, на которую вакансий в 10000 раз больше, так будет пролазить легче.

Всякие модные сорта говна лучше оставить исключительно опытным бойцам. Они с ними пердолятся ради забавы и стимулирования эрекции путём прямого вливания ПЕРСПЕКТИВНЫХ технологий в чертоги своего разума. Неопытные маслята делают это из-за жизненной необходимости и потому что ссыкуны. Они не одинаковые.

Мораль: Хочешь в айтишку - не выпендривайся, выбирай из популярного, там больше чайников, которых легко уделать. А уже потом, когда станешь большим и крепким, тогда и можешь совать нос в это болото перспективности. В противном случае, за то немногое, что остаётся в области ПЕРСПЕКТИВНЫХ технологий тебе придётся закусываться с сеньорами-помидорами, которые выкормились на популярных технологиях.

P.S. Ставь + в каментах, если тоже хотел влезть в непопулярную залупу, чтобы там не пришлось толкаться локтями с толпами джунов.

ЕхтримЦоде на страже ментального здоровья отпищеков ✌️