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

Рассмотрел это на конкретном примере недавно реализованной программы для изучения слов.

После этой статьи вы будете использовать туду-пункты через соответствующее расширение вашего текстового редактора (я надеюсь хаха).

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

https://optozorax.github.io/how-i-write-programs

Занимательная статья об оптимизации CRDT (Conflict-free replicated data type, один из многих вариантов реализации конкурентного редактирования).

5000x faster CRDTs: An Adventure in Optimization

Там есть немного раста, много js-а и всякие занимательные штуки, рекомендую к прочтению :p

https://matklad.github.io/2021/09/04/fast-rust-builds.html

matklad как обычно дело говорит, на этот раз про скорость компиляции

#prog #rust #моё #article

Здрасьте. Сегодня поста не будет — но только потому, что я решил написать статью для Хабра. Собственно, вот она.

И напоминаю: если вам это понравилось — поддержите копеечкой автора, я вам благодарен буду: 4274 3200 5402 8520.

Нередко в базах данных и вообще любой работы с массивами возникают сложения чисел с плавающей точкой. С ними вроде всё хорошо, IEEE 754 стандарт давно устоялся, но чем больше вы складываете чисел, тем больше накапливается ошибка. Ещё хуже, если вы суммируйте в разных потоках или машинах, результаты могут быть разные и надо писать отдельные проверки на сравнения. Ошибка, конечно же, идёт из округлений.

Кейс: вы работаете с данными и считайте порог для их удаления. Доверять только одному процессу с удалением строго нельзя, поэтому часто делают кворумные джобы, где запускают много одинаковых бинарей, которые обязаны договориться о том, что данные можно удалять. Это позволяет выкладывать новый код на staging, не боясь, что данные удалятся (например, кворум не наберётся, если из 3 реплик мы выложим новый плохой код только на одну). Нередкие проблемы, которые я видел в проде своими глазами были связаны с тем, что удаления не могли договориться из-за того, что вокруг порога X одни джобы считали X - eps, другие X + eps. В итоге данные не удалялись и репортились в алёрт о том, что всё разъехалось, не страшно для людей, но бесит разработчиков.

Я настоятельно рекомендую, конечно же, сравнивать с eps в общем случае, но если уж не получается, то наука приготовила для нас интересные алгоритмы, которые позволяют уменьшить ошибку очень сильно. В наивном сложении после сложения n чисел будет ошибка ~machine_eps * n * сумму_модулей, где machine_eps — машинная точность, для float это примерно 6*10^-8, для double это примерно 10^-16.

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

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

Часто забывают об алгоритме Кахана, который не требует ни дополнительной памяти, ни почти не зависит от порядка сложения, зато достигает намного более серьёзной точности, а именно ~(2 * machine_eps + n * machine_eps^2)*сумму_модулей. Самый сок идёт от квадрата машинной точности, что перебить количеством элементов становится уже сложнее (надо 10^16 и 10^32 элементов соответственно).

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

float Naive(const std::vector<float>& v) {
float sum = 0;
for (const float f : v) {
sum += f; // Problem that 'sum' can be big and 'f' is small.
}
return f;
}

float KahanSum(const std::vector<float>& v) {
float sum = 0.0; // Final sum
float err = 0.0; // Error compensation
float y; // v[i] - C
float t; // Temporary for sum
for (const float f : v) {
y = f - err; // Magic is here, error is compensated from input.
t = sum + y;
err = t - sum - y;
sum = t;
}
return sum;
}

Алгоритм требует в 4 раза больше float операций, но всё ещё векторизируется. Доказательство ошибки я выношу за рамки одного поста, оно сложное и даже написано в Кнуте. Плюсы от этого алгоритма в том, что теперь сравнивать можно с машинным epsilon, а не с достаточно большим как это было в обычном суммировании. Можно меньше боятся расхождений и делать более мягкие пороги на оценку с миллиардами элементов.

[1] Kahan summation wikipedia
[2] Лекция в Hamburg University про округления и KahanSummation доказательства
[3] Rust Kahan Summation crate
[4] ClickHouse KahanSum и документация по функции sumKahan
[5] Schewchuk algorithm for exact floating sum
[6] Theory behind floating point comparison
[7] What Every Computer Scientist Should Know About Floating-Point Arithmetic

#prog #rust #article

Статья о распространённых плохих практиках новичков в Rust

#prog #article

Статья про паттерн для работы с IO.

"There’s a pattern that I keep recommending to teams over and over again, because it helps separate concerns around I/O; sending and receiving things over a network, interacting with AWS, saving and loading things from data stores. It’s an old idea; you’ll find it filed under “Decorator” in your Gang of Four book.

<...>

Decorators are a great compositional pattern allowing the different concerns that inevitably cluster around I/O boundaries to be neatly separated and recombined. This opportunity presents itself several times in every app we write, and does not require any fancy language, type system, or framework."

Перформанс, как и security, в большой степени состоит в том числе и из процессов. Что надо сделать, чтобы не повторять ошибок, как найти плохие паттерны в коде на этапе компиляции или как мерить производительность, latency, как знать к каким сервисам обращаться, как сконнектить людей из hardware, firmware, software и тд. Как обучить людей, чтобы они писали быстрый код.

Это сложный и непростой процесс. Например, в Google мы всё больше и больше переходим на политику third_party live at head. Когда мы автоматически подбираем обновлённые версии веток того или другого контриба (библиотек из open source).

Например, мы релизим LLVM пару раз в месяц. Да, мы гоняем компилятор на всём коде Google, и откатываем то, что не работает сразу. Иногда ломаются другие контрибы, и мы патчим их. Иногда не работает наш код, и мы его фиксим. Эдакий стресс тест компилятора каждые пару недель. Зато мы можем компиляторным инженерам повысить velocity, они что-то комитят, а через две недели оно в проде на огромную кодовую базу. Об этом мы писали в книжке Software Engineering at Google.

Недавно пара наших инженеров ядра Andrew Delgadillo и Dylan Hatch поделились то, как мы переходим на жизнь at head в Linux.

Исторически так сложилось, что ядро Linux разрабатывалось отдельно и поэтому в проде до сих пор у нас версия 4.15, когда как уже вышла 5.15, несколько лет уже прошло, а мы всё ещё не можем переехать.

И да, остро вопрос не стоял раньше, взяли ядро, наложили пару патчей и обновили. А потом поняли, что оптимизация Linux стоит больших денег Google, и наняли людей на разработку ядра. Тем самым мы сейчас находимся в состоянии 9000 (9 тысяч) патчей поверх mainline. Многие из них драйвера для некоторого нашего железа, например, TPU, но есть и более сложные вещи, как Google Fibers (более лёгкие user-space треды), много патчей о том, как находить Out Of Memory проблемы быстрее и лучше (дада, мы считаем, что внутри мы пофиксили баг 12309), отключение сбора perf стеков из-за приватности и так далее. Называем мы это ядро Prodkernel, потому что оно ядро и работает в проде.

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

В последнее время всё больше и больше мы уделяем время тому, как обновлять ядро. Назвали мы этот проект Icebreaker, потому что это уже невозможно и надо ломать этот лёд.

Да, у этого есть риски. Иногда Linux community может сказать, что им что-то не надо, и мы останемся с патчами. Иногда мы что-то проглядим, и в проде будет упячка. Но разработчики ядра в Google нацелены на удаление ненужных патчей, апстрима всех нужных, ну а с драйверами как-нибудь разберёмся.

Prodkernel с нами ещё поживет несколько лет, но Icebreaker это то, куда мы стремимся и тратим очень много сил. Выкатка на супер боевое окружение ядра за считанные дни, нахождение всех багов, размазанный процесс фикса багов и апстрим многих фич от Google должны достаточно сильно прокачать как и open source, так и нас внутри.

Я точно знаю, что некоторые вице-президенты Google не очень любят такие решения, но их всё таки убедили более технические люди. Google не сможет нанять такую команду разработки, которая будет мощнее всего community большого опен-сорса. Мы за несколько лет едва сделали Fuchsia OS, которая ни разу не про серверы. И даже если писать свою, то это годы разработки и десятки лет обучения людей.

Некоторые низкоуровневые компоненты настолько важны для tech мира, что закрываться просто нельзя. Security патчи должны быть понятны всем, какие атаки могут быть сделаны в каких версиях, и какие патчи в каких версиях улучшали перформанс.

Я горд за команду ядра, что они наконец-то официально поделились об этом с миром.

[1] Заметка от Andrew Delgadillo и Dylan Hatch про разработку ядра в Google. Слайды
[2] Бесплатная книжка по Software Engineering at Google

Продолжается иммерсивный NFT-фестиваль от Flow: в дискорд Flowverse менее чем за неделю вступило более 40 000 человек, а команда Dapper Labs провела серию вводных панелей, которые можно посмотреть в записи на твиче The First Mint.

Через несколько дней начинаются розыгрыши Mystery Packs от Flow Fest, внутри которых будут классные коллекционные предметы, включая некоторые редкие NFT. Их можно только выиграть, не купить. Но зато можно продать 😉

Чтобы получить свой набор, нужно только «посетить» Flow Fest, вступив в тот самый дискорд, участвовать в мероприятиях и выполнять простые задания, вроде реакций к постам.

📆 Полный календарь дропов смотрите здесь

Как всё знать: ультимативный гайд по поиску информации 📖

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

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

По убыванию полезности:

0. Личные знакомства: Как бы ни хотелось всё делать самому, самую полезную информацию всё равно приносит кто-то другой. Часто спрашивают про первые 100х, но мне писать особо нечего: просто друзья рассказали про алгостейблы. Сейчас другие друзья рассказывают про вайтлисты НФТ. Чем дальше, чем выше уровень прошаренности друзей, тем больше альфы. Когда-то друзьями окажутся фаундеры. Друзья это важно, даже если лично вы не знакомы.

1. Каналы с подборками новостей и аналитикой: @thedailyape, @defiprime, @unfolded, @glassnode, @jarvis_labs – поочередно узнаю из них абсолютно всё, что улетает в @newcryptochat ссылками, типа сам нашёл. Лучше читать всё, что постят.

2. СМИ: The Block, Coindesk, Cointelegraph, Forklog. Ссылки не даю, сами решайте, где их читать. Лично я в последнее время читаю только заголовки и краткое содержание, за ними можно следить в тг-каналах и Твиттерах всех этих изданий. Этого достаточно, чтобы быть в курсе основных макро-событий, на которые я в последнее время обращаю больше внимания.

3. Рассылки и ресерчи: Bankless + их же Metaversal, Our Network, Week in Ethereum, CoinMarketCap News, Curve Market Cap, Nansen, Jarvis, Messari, Delphi Digital, Mechanism Cap, Paradigm. Я советую подписываться абсолютно на всё, что попадается на глаза, даже полный шизойдный биткоин-максимализм (сам читаю Pomp Letter), и регулярно пролистывать заголовки писем. Не копите их в ящике: прочитали – убрали в архив. Скорее всего, большего желания не появится, а полный шит так или иначе отпадёт сам.

4. Твиттер: обычно советую подписаться на все мои подписки и просто пару дней лайкать всё, что нравится – лента сама начнёт рекомендовать что-то актуальное. Альфы с прямым указанием действий там искать не стоит, очень токсичная среда. Нотификации у меня стоят на ~10 аккаунтов, в основном это тоже макро-мысли вроде Su Zhu, Nomad, Tetranode. Я отписался от всех проектов и оставил только людей с каким-то мнением и разработчиков. Проекты меняются, толковые люди остаются.

5. Подкасты: это долго и муторно, но очень полезно не только для поиска информации, но и общего развития. Раньше заставял себя слушать вдумчиво и через силу, теперь – фоном и за другими делами, второе лучше. Рекомендую без особого порядка подписаться на всё: Lex Fridman Podcast, Naval Podcast, Odd Lots (Bloomberg), The Scoop от шефа The Block, Market Meditations, The Delphi Podcast, UpOnly (Cobie), UncommonCore (Su Zhu + Hasu), FTX Podcast, Unconfirmed, Unchained, Into The Ether, Blockcrunch, Bankless, Базовый Блок.

6. Телеграм и Дискорд: на мой взгляд, единственные две стоящие группы это @lobsters_chat и @defiyield_app. Полезность поставил в конец потому, что уровень альфы там бывает даже немного преждевременный. Вопрос «что почитать в Дискорде» вообще не имеет никакого смысла: Дискорд это финальная стадия воронки изучения проекта и вливания в него, но начинаться она должна начаться с пунктов 1-4. Нашли – почитали – изучили – залетели в Дискорд – стали членом сообщества.

7. Авторские каналы: сказать честно, я не читаю каналы и не могу особо поделиться мнением о них. Но есть друзья и знакомые, о них не могу не написать: @notothemoon, @moni_talks_ru, @cryptolamer, @defiscamcheck, @banklessRU, @ghost_in_the_block. Ребята молодцы и явно делают новое крипто дерьмо умелее меня. Чатики у них тоже супер.

На этом моя просветительская деятельность пока что всё.

MetricsQL: PromQL compliance

https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e

#promql #metricsql #prometheus #victoriametrics

Newborn unicorn CTO разносит стартап смотреть в маркдаун без смс.

https://github.com/ClickHouse/ClickHouse/blob/master/benchmark/timescaledb/usability.md

ИМХ такое лучше бы в личном блоге постить.

Наткнулся в твиттере на анонс интересного инструмента:

> cargo-hakari

Он автоматизирует создание и поддержку "workspace-hack" крейтов, ускоряя компиляцию для больших воркспейсов. Что такое "workspace-hack" и зачем его используют в rustc и firefox — читайте в треде.

что делать в час ночи пятницы? Смотреть доклады про перфоманс оптимизацию. Неплохо расказано, хотя узко и совсем не было про современные техники типа флеймграфов. https://youtu.be/r-TLSBdHe1A

Решил с утра перечитать https://12factor.net/ Оказывается не так уж и много надо вещей сделать чтобы было приятно пушить вещи в прод. Но человек и тут накосячил.

Вот это еще понравилось:
> Processes should strive to minimize startup time

..и тут же вспоминаю, сколько раз встречал наполнение кеша™ при старте на минутку-две. Зато потом ответы быстрые, да.

Короч совет: пролистайте еще раз список, уверен что каждый найдет что-то, что в текущем проекте не совсем так.

(тут была шутка про 11й пункт о логах и про лог4ж2 с 3 CVE за пару недель)