The ExtremeCode Times

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🤡 Тут анонимные источники подкинули закономерную претензию к моему посту про 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? Вообще беды с башкой? 🤡

PHP Developer moment ✌️

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

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

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

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

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

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

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

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

Прощаем?

😳 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

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

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

https://youtu.be/LOYpqjtsbic

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

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

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

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

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

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

🔹 Unity Software ТОЧНО ВСЁ

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

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

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

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

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

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

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

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

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

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

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

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

😂👍

🤡🤡 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™: Unity Software объявили о слиянии с ironSource за $4.4 млрд.

Почитал я, значит, комментарии об этой сделке на YCombinator и чуть не умер от кринжа 😑

ОКАЗЫВАЕТСЯ, что ironSource — печально известная компания, которая занимается распространением вредоносного ПО, типа malware, adware bundlers и приправлено всё это рассылочками спама: Пруф #1, Пруф #2.

Ранее я уже писал про сокращение сотрудников в Unity Software.

UPD: Почему это плохо? Если бы Unity Software полностью выкупила эту компанию, то вопросов бы ни у кого не возникло. Но это СЛИЯНИЕ двух крупных компаний, в результате которого акционеры ironSource получат примерно 26% акций Unity Software — дальше сами додумывайте, к чему это может привести.

Вычёркиваем?

👉 Почему так быстро?

В качестве причин, автор указывает 2 основных аргумента:
1. В качестве основы используется WebKit и JavaScriptCore
2. Из движка не вырезан Web API, поэтому сохраняется совместимость с браузерными API типа fetch

На основе fetch api кстати говоря и работает сервер в Bun.

И если несколько раньше я приводил Benchmark сравнение по результатам которых JSC не настолько быстрее, чем v8 в одинаковых условиях.

НО! Похоже именно реализация I/O, в частности Http + Web API даёт нам этот самый перформанс в серверном рендеринге - только за счёт сетевого взаимодействия от 50% до 300% но это не точно 🧐

Не стоит забывать, что чисто теоретически за счёт оптимизации WebKit под архитектуру M1 - именно Mac Os получит наибольший прирост в производительности, потому что условный Nodejs не имеет таких оптимизаций.

У Nodejs же еще вырезан Web API и в нём используется собственная реализация модуля Http. Видимо недостаточно быстрая, ну что поделать 🤖

ExtremeCode moment ✌️