#list
0. [talk] Modernizing Compiler Design for Carbon Toolchain.
Chandler Carruth рассказывает про базовый дизайн современных компиляторов, который уходит в решения 50летней давности, и делится ограничениями такого подхода, после чего рассказывает про новые подходы и решения, применённые при реализации компилятора для Carbon, что позволило научиться компилировать язык очень эффективно и быстро.
Нормальная такая волына этот доклад.
1. [article] Diff Algorithms.
Солидный пост про алгоритмы поиска диффа в текстах (и последовательностях в общем). Автор рассказывает, что он хотел от подобной библиотеки, чем не устраивают существующие на Go, как это всё счастье работает.
Понравилось, что при проектировании API либы автор пошёл от пожеланий юзера и потенциальных хотелок по использованию библиотеки, а не с конца разработчика. Сделать хорошую API даже с точки зрения кода это целое искусство. Я в последнее время всё больше и больше про это думаю. Ничего правда не придумал. Может надо погрузиться в тему глубже.
2. [article] Life Altering Postgresql Patterns.
Набор рекомендаций, которые могут сильно облегчить жизнь при работе с postgres. Там что-то вида: юзайте uuid, всегда имейте created_at и updated_at, юзайте енамы, используйте схемы и др.
Местами база, местами я ещё не думал и не встречал связанных проблем. Но там где встречал, на сто процентов уверен, что рекомендации к месту и не раз экономили мне кучу времени и нервов.
3. [article] Build Your Own Database.
Интерактивный пост, в котором автор пишет простой kv-storage с нуля. Там кнопки свистелки. Люблю формат за наглядность.
4. [article] 500 Miles.
===================================
27 ноября в Екатеринбурге будет Pytup от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Modernizing Compiler Design for Carbon Toolchain.
Chandler Carruth рассказывает про базовый дизайн современных компиляторов, который уходит в решения 50летней давности, и делится ограничениями такого подхода, после чего рассказывает про новые подходы и решения, применённые при реализации компилятора для Carbon, что позволило научиться компилировать язык очень эффективно и быстро.
Нормальная такая волына этот доклад.
1. [article] Diff Algorithms.
Солидный пост про алгоритмы поиска диффа в текстах (и последовательностях в общем). Автор рассказывает, что он хотел от подобной библиотеки, чем не устраивают существующие на Go, как это всё счастье работает.
Понравилось, что при проектировании API либы автор пошёл от пожеланий юзера и потенциальных хотелок по использованию библиотеки, а не с конца разработчика. Сделать хорошую API даже с точки зрения кода это целое искусство. Я в последнее время всё больше и больше про это думаю. Ничего правда не придумал. Может надо погрузиться в тему глубже.
2. [article] Life Altering Postgresql Patterns.
Набор рекомендаций, которые могут сильно облегчить жизнь при работе с postgres. Там что-то вида: юзайте uuid, всегда имейте created_at и updated_at, юзайте енамы, используйте схемы и др.
Местами база, местами я ещё не думал и не встречал связанных проблем. Но там где встречал, на сто процентов уверен, что рекомендации к месту и не раз экономили мне кучу времени и нервов.
3. [article] Build Your Own Database.
Интерактивный пост, в котором автор пишет простой kv-storage с нуля. Там кнопки свистелки. Люблю формат за наглядность.
4. [article] 500 Miles.
"We're having a problem sending email out of the department."
"What's the problem?" I asked.
"We can't send mail more than 500 miles," the chairman explained.
I choked on my latte. "Come again?"
===================================
27 ноября в Екатеринбурге будет Pytup от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍11🔥7🤮2❤1👎1😁1
#algo
Бинарный поиск -- чуть ли не первый алгоритм, который мы узнаем.
Ну я по крайней мере.
Я его увидел когда-то Грокаем алгоритмы, а потом на спор угадывал число одноклассника от 1 до 4kkk за 32 попытки (не получилось: т.к. я считал в уме, погрешность вычислений в голове привела меня к отрезку длиной 8 на последнюю попытку; получил заслуженный фофан ).
Потом мне рассказали про бинарный поиск по ответу.
Это когда у вас ответ на задачу -- монотонная функция.
Можно попробовать разные значения и понять, в какой момент она меняет значение (поиск квадратного корня или 371C как хорошие примеры).
Потом я думал про условный тернарный поиск, чтобы отсекать сразу 2/3 ответов, а не половину. Ничего не придумал.
Он используется, но в других местах.
Недавно попался доклад на P99 про ускорение бинарного поиска, но перед ним надо посмотреть на другой.
Оптимизируем бинарный поиск Сергея Слотина с C++ Zero Cost Conf 2022 (english версия с CppCon того же года; рекомендую её, т.к. в неё чуть больше поместилось).
Оптимизировать бинпоиск по Сергею Слотину это:
👍 избавляться от сложнопредсказуемого бранча
👍 префетчить потенциальные куски памяти
😎 менять memory layout, например с помощью Eytzinger нумерации
🤓 уходить в B-tree like укладывание элементов (S-tree)
🤔 улучшать с помощью B+-tree like оптимизации (S+-tree)
А на P99 был доклад от Ragnar Groot про докручивание решения выше, только на Rust.
Отойдя в сторону, есть вариация бинарного поиска, известная под названием Shar's algorithm, когда вместо поддержания двух границ вы сдвигаете индекс на степень двойки.
Тут прикольная статья про то, как автор генерировал код на D для решения задачи на массивах статического размера.
Некоторое развитие и на C++ есть у другого автора.
Во всех ресурсах выше речь идёт о классическом бинпоиске, а не о решении задачи с такими условиями.
Как говорил Сергей в докладе, есть и другие варианты.
Например, для маленького множества ключей можно заранее предпосчитать ответ на каждый возможный запрос и хранить их в lookup table (LUT) (для 8-16 байтовых типов это делается быстро и не очень дорого по памяти).
Если типы пошире, можно изменить вид LUT и в старших битах хранить границы более узкого отрезка, что позволяет изначально сокращать задачу бинпоиска на несколько итераций.
Подробнее это описано тут.
Или если у вас есть все запросы заранее (решаем в офлайне), можно использовать этот факт и, зная отношения между числами, более эффективно узнавать ответ на новые запросы, исходя из предыдущих.
И не прям про бинпоиск, но под руку попался доклад, на который ссылаются разные бинпоиск статьи, хотя там рассказываются в целом общие идеи и корутины: Gor Nishanov «Nano-coroutines to the Rescue! (Using Coroutines TS, of Course)».
Рядом упомянем и другие вариации:
- exponential search для больших размеров
- fibonacci search для старых архитектур, т.к. там нужно только сложение и вычитание -> выполняется быстрее
- jump search, в котором минимизируется кол-во скачков назад (нужно только мамонтам имхо)
- fractional cascading позволяет оптимизировать задачу нахождения одного числа в нескольких массивах
И раз мы считаем среднее между двумя числами, вот доклад про std::midpoint. Там не всё так просто!
Я так и не научился за секунду писать бинописк правильно.
То единичку забуду, то про инвариант не подумаю.
Коварен.
Есть что-то добавить по теме?
Бинарный поиск -- чуть ли не первый алгоритм, который мы узнаем.
Ну я по крайней мере.
Я его увидел когда-то Грокаем алгоритмы, а потом на спор угадывал число одноклассника от 1 до 4kkk за 32 попытки (
Потом мне рассказали про бинарный поиск по ответу.
Это когда у вас ответ на задачу -- монотонная функция.
Можно попробовать разные значения и понять, в какой момент она меняет значение (поиск квадратного корня или 371C как хорошие примеры).
Потом я думал про условный тернарный поиск, чтобы отсекать сразу 2/3 ответов, а не половину. Ничего не придумал.
Он используется, но в других местах.
Недавно попался доклад на P99 про ускорение бинарного поиска, но перед ним надо посмотреть на другой.
Оптимизируем бинарный поиск Сергея Слотина с C++ Zero Cost Conf 2022 (english версия с CppCon того же года; рекомендую её, т.к. в неё чуть больше поместилось).
Оптимизировать бинпоиск по Сергею Слотину это:
👍 избавляться от сложнопредсказуемого бранча
👍 префетчить потенциальные куски памяти
😎 менять memory layout, например с помощью Eytzinger нумерации
🤓 уходить в B-tree like укладывание элементов (S-tree)
А на P99 был доклад от Ragnar Groot про докручивание решения выше, только на Rust.
Отойдя в сторону, есть вариация бинарного поиска, известная под названием Shar's algorithm, когда вместо поддержания двух границ вы сдвигаете индекс на степень двойки.
Тут прикольная статья про то, как автор генерировал код на D для решения задачи на массивах статического размера.
Некоторое развитие и на C++ есть у другого автора.
Во всех ресурсах выше речь идёт о классическом бинпоиске, а не о решении задачи с такими условиями.
Как говорил Сергей в докладе, есть и другие варианты.
Например, для маленького множества ключей можно заранее предпосчитать ответ на каждый возможный запрос и хранить их в lookup table (LUT) (для 8-16 байтовых типов это делается быстро и не очень дорого по памяти).
Если типы пошире, можно изменить вид LUT и в старших битах хранить границы более узкого отрезка, что позволяет изначально сокращать задачу бинпоиска на несколько итераций.
Подробнее это описано тут.
Или если у вас есть все запросы заранее (решаем в офлайне), можно использовать этот факт и, зная отношения между числами, более эффективно узнавать ответ на новые запросы, исходя из предыдущих.
И не прям про бинпоиск, но под руку попался доклад, на который ссылаются разные бинпоиск статьи, хотя там рассказываются в целом общие идеи и корутины: Gor Nishanov «Nano-coroutines to the Rescue! (Using Coroutines TS, of Course)».
Рядом упомянем и другие вариации:
- exponential search для больших размеров
- fibonacci search для старых архитектур, т.к. там нужно только сложение и вычитание -> выполняется быстрее
- jump search, в котором минимизируется кол-во скачков назад (нужно только мамонтам имхо)
- fractional cascading позволяет оптимизировать задачу нахождения одного числа в нескольких массивах
И раз мы считаем среднее между двумя числами, вот доклад про std::midpoint. Там не всё так просто!
Я так и не научился за секунду писать бинописк правильно.
То единичку забуду, то про инвариант не подумаю.
Коварен.
Есть что-то добавить по теме?
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥30❤4⚡4❤🔥1
#list
0. [talk] What Every Programmer Should Know about How CPUs Work.
Matt Godbolt наваливает баса и рассказывает базу про устройство CPU. Я не очень погружён, потому мне понравилось. Хороший кусок уделяется общему пайплайну, branch predictor'у и ещё немного execute инструкций.
1. [article] The Art of Formatting Code.
Статья про форматирование кода, правда в итоге не кода, а JSON, но поверьте, этого с головой достаточно.
Примеры кстати на Rust. Довольны???
2. [article] Expert Generalists.
Martin Fowler с друзьями рассказывает про концепцию expert generalists: кто такие, какие качества, зачем нужны, как оценить, как растить и ещё пару мелочей.
3. [talk] Анатомия асинхронных движков.
Пошёл пересматривать архивы. В этот раз Антон Полухин рассказывает про то, как делать асинхронные движки. Рассказ построен от базового подхода до чего-то более приемлемого, решая проблему за проблемой.
Это кстати C++ Zero Cost Conf 2021. Первая.
4. [article] How to Increase Your Luck Surface Area.
Нравится вам это или нет, важно говорить про то, что вы делаете. Современные иерархии в больших компаниях не могут естественным образом привести к тому, что про ваши успехи будут знать все вокруг (а это чаще всего жизненно необходимо для ваших финансовых результатов). Так что надо идти и как-то рассказывать про успехи.
В конце очень хорошая картинка. У вас есть несколько вариантов, но показательнее всего мне кажется такая развилка: можно либо делать достаточно, но правильно и много про это говорить (best), либо делать очень много и почти про это не говорить (тоже best, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] What Every Programmer Should Know about How CPUs Work.
Matt Godbolt наваливает баса и рассказывает базу про устройство CPU. Я не очень погружён, потому мне понравилось. Хороший кусок уделяется общему пайплайну, branch predictor'у и ещё немного execute инструкций.
1. [article] The Art of Formatting Code.
Статья про форматирование кода, правда в итоге не кода, а JSON, но поверьте, этого с головой достаточно.
Примеры кстати на Rust. Довольны???
2. [article] Expert Generalists.
Martin Fowler с друзьями рассказывает про концепцию expert generalists: кто такие, какие качества, зачем нужны, как оценить, как растить и ещё пару мелочей.
3. [talk] Анатомия асинхронных движков.
Пошёл пересматривать архивы. В этот раз Антон Полухин рассказывает про то, как делать асинхронные движки. Рассказ построен от базового подхода до чего-то более приемлемого, решая проблему за проблемой.
Это кстати C++ Zero Cost Conf 2021. Первая.
4. [article] How to Increase Your Luck Surface Area.
Нравится вам это или нет, важно говорить про то, что вы делаете. Современные иерархии в больших компаниях не могут естественным образом привести к тому, что про ваши успехи будут знать все вокруг (а это чаще всего жизненно необходимо для ваших финансовых результатов). Так что надо идти и как-то рассказывать про успехи.
В конце очень хорошая картинка. У вас есть несколько вариантов, но показательнее всего мне кажется такая развилка: можно либо делать достаточно, но правильно и много про это говорить (best), либо делать очень много и почти про это не говорить (тоже best, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍16❤9🔥6🤯2
#list
0. [talk] The Evolution of std::optional - From Boost to C++26.
Начинается сезон CppCon2025.
Steve Downey рассказывает про
И местами приятные примеры кода из C++-современного/C++-будущего. Повышаем насмотренность. Набиваем руки.
Что прикольно, докладчик рассказывает про профит от участия в Beman project: нашли багу в потенциальной реализации
1. [article] Итоги встречи ISO C++ на Гавайях: начинаем полировку стандарта С++26.
Антон Полухин рассказывает новости очередной встречи комитета.
2. [article] Metastable Failures in the Wild.
Я вам уже рассказывал про metastable failures и Лёшу Быкова (@it_tldr). Добрался осознанно перечитать некоторые статьи из ссылок в его докладе.
Метастатья про разные найденные на просторах инциденты, связанные как раз с metastable failures. Там общие описания, небольшая статистика (например, в >50% случаев, ретраи были фактором, мещающим системе самовосстановиться) и разбор деталей некоторых инцидентов. Что забавно, есть такой кусок:
Т.е. кто-то ребятам nda слил, а они и рады это описать. Похехал.
3. [article] Код-гольф в Яндексе: как нерды развлекаются.
Помните, я вам писал про военный синус от Паши Сухова?
Паша весь этот год прикладывал (и продолжает) руку к активностям на митапах и конференциях Яндекса. Делает код-гольф. Не знаете что это? Примеры задач и решений не видели? Ну почитайте его статью!
А ещё, прикиньте, он услышал запросы трудящихся и дропнул канал себе: @cpp_durka. Ничего не обещает, но вы приходите.
4. [book] Корпорация гениев. Как управлять командой творческих людей. Эд Кэтмелл.
Это не обзор в обычном смысле. Просто поделюсь наблюдением.
Книжка рассказывает про молодые годы Pixar, как чуваки искали своё место на рынке, Стива Джобса и процессы в компании.
И хотя Pixar когда-то давно это совсем не айтишечка, там можно увидеть знакомые сегодня штуки.
Например у чуваков был brain trust -- собрание ответственных коллег, которые ревьюили разные решения в производстве мультиков у ответственных. Я, слушая, подумал "Пфф, это ж архитектурное ревью. Мы такое сто лет у себя уже делаем".
Или автор рассказывает про то, как случайно удалили огромный кусок работы, запаниковали, нашли бекап недельной давности у коллеги дома, восстановили и сели думать, как такого больше не допустить. Не винили ответственного. Сделали какие-то action item'ы для неповторения. Тут я подумал "Пфф. Чуваки придумали инцидент менеджмент. Что ж тут такого?".
А потом я осознал, что это мне в 2к25 всё понятно и очевидно. А у них не было примеров. Им некуда было смотреть. Они буквально чуть ли не первые, кто начал делать подобные вещи и сделал из них процессы. А потом уже спустя 10-15-20 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
=====
Картинка кринж или норм?
0. [talk] The Evolution of std::optional - From Boost to C++26.
Начинается сезон CppCon2025.
Steve Downey рассказывает про
std::optional и, что больше ему свойственно, т.к. он там что-то предлагает по теме в стандарт, std::optional<T&>. Там общие концепции, сложные вопросы "как должны себя вести в ситуациях А Б В". Что делать с такими-то методами. И местами приятные примеры кода из C++-современного/C++-будущего. Повышаем насмотренность. Набиваем руки.
Что прикольно, докладчик рассказывает про профит от участия в Beman project: нашли багу в потенциальной реализации
std::optional<T&>.1. [article] Итоги встречи ISO C++ на Гавайях: начинаем полировку стандарта С++26.
Антон Полухин рассказывает новости очередной встречи комитета.
2. [article] Metastable Failures in the Wild.
Я вам уже рассказывал про metastable failures и Лёшу Быкова (@it_tldr). Добрался осознанно перечитать некоторые статьи из ссылок в его докладе.
Метастатья про разные найденные на просторах инциденты, связанные как раз с metastable failures. Там общие описания, небольшая статистика (например, в >50% случаев, ретраи были фактором, мещающим системе самовосстановиться) и разбор деталей некоторых инцидентов. Что забавно, есть такой кусок:
While publicly available incident reports provide enough high-level information to identify the metastable failures, they lack the depth and detail to understand the complex interactions between components in large systems. In this case study, we use insider information to describe in detail one specific metastable failure occurring at Twitter, a large internet company, due to garbage collection (GC).
Т.е. кто-то ребятам nda слил, а они и рады это описать. Похехал.
3. [article] Код-гольф в Яндексе: как нерды развлекаются.
Помните, я вам писал про военный синус от Паши Сухова?
Паша весь этот год прикладывал (и продолжает) руку к активностям на митапах и конференциях Яндекса. Делает код-гольф. Не знаете что это? Примеры задач и решений не видели? Ну почитайте его статью!
А ещё, прикиньте, он услышал запросы трудящихся и дропнул канал себе: @cpp_durka. Ничего не обещает, но вы приходите.
4. [book] Корпорация гениев. Как управлять командой творческих людей. Эд Кэтмелл.
Это не обзор в обычном смысле. Просто поделюсь наблюдением.
Книжка рассказывает про молодые годы Pixar, как чуваки искали своё место на рынке, Стива Джобса и процессы в компании.
И хотя Pixar когда-то давно это совсем не айтишечка, там можно увидеть знакомые сегодня штуки.
Например у чуваков был brain trust -- собрание ответственных коллег, которые ревьюили разные решения в производстве мультиков у ответственных. Я, слушая, подумал "Пфф, это ж архитектурное ревью. Мы такое сто лет у себя уже делаем".
Или автор рассказывает про то, как случайно удалили огромный кусок работы, запаниковали, нашли бекап недельной давности у коллеги дома, восстановили и сели думать, как такого больше не допустить. Не винили ответственного. Сделали какие-то action item'ы для неповторения. Тут я подумал "Пфф. Чуваки придумали инцидент менеджмент. Что ж тут такого?".
А потом я осознал, что это мне в 2к25 всё понятно и очевидно. А у них не было примеров. Им некуда было смотреть. Они буквально чуть ли не первые, кто начал делать подобные вещи и сделал из них процессы. А потом уже спустя 10-15-20 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
=====
Картинка кринж или норм?
❤12🔥7😁1
#cpp
Время -- деньги.
Стандарт говорит [упрощая], что компиляторы должны поддерживать только наблюдаемое поведение. А как он там это делает, это уже его дело.
Есть несколько уровней оптимизаций.
O0 (о ноль)
База. Компилятор делает минимальный анализ и минимальное кол-во оптимизаций. Сохраняется полная семантика программы. Дефолтный вариант. Идеально для дебага.
O1
Компилятор применяет простые оптимизации без сложного анализа: dead code elimination, constant propagation, basic inlining.
У GCC тут уже 48 оптимизаций.
Используется редко, когда не хочется сильно замедлить компиляцию очень больших программ (друг отметил, что это нужно только маргиналам).
O2
Самый народный уровень.
Множество оптимизаций без speed-space трейдофа: unroll loops, vectorization, strict aliasing.
O3
Включаем максимальный перфоманс отдельной программы. Всё ради скорости. Более агрессивно оптимизируем циклы, больше инлайним, больше векторизируем. Из-за сильной векторизации и инлайнинга бинарник может сильно раздуваться. В том числе поэтому перф может падать, так что на практике не всегда является более оптимальным (при небольшом instruction cache вы станете чаще кешмиссить).
Если увлекаетесь, можно включать при компиляции отдельных файлов, код в которых точно в плюсе. Не задевая всё остальное.
Ofast
Как O3, но включаются опасные оптимизации. Например
Почему опасные? Потому что скорость получается за счёт точности. Про артефакты можно почитать в Beware of fast-math.
Og (оуджи)
Og = O0 + некоторые оптимизации из O1, не ухудшающие debug experience.
Os
Os = оптимизации из O2, не увеличивающие размер кода + некоторые дополнительные, позволяющие сократить размер исполняемого кода. Трейдофим немного, но в меру.
Oz
Когда у вас мощнейшие ограничения по размеру бинарника и использованию памяти, выбираем Oz. Заодно можно просадить и перф. Но иногда в embedded только так.
Может увеличить кол-во исполняемых инструкций, если их можно закодировать меньшим кол-вом байтов.
Дебагать может быть тоже уже нереально больно. Но как есть.
Мы не говорим про LTO (и ThinLTO) и PGO. Мы не говорим про -march=... и другие. Может когда-нибудь потом..
Доклад в тему: What GCC optimization level is best for you?
В докладе про сами оптимизации и много сравнения с LLVM в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.
Время -- деньги.
Стандарт говорит [упрощая], что компиляторы должны поддерживать только наблюдаемое поведение. А как он там это делает, это уже его дело.
Есть несколько уровней оптимизаций.
O0 (о ноль)
База. Компилятор делает минимальный анализ и минимальное кол-во оптимизаций. Сохраняется полная семантика программы. Дефолтный вариант. Идеально для дебага.
O1
Компилятор применяет простые оптимизации без сложного анализа: dead code elimination, constant propagation, basic inlining.
У GCC тут уже 48 оптимизаций.
Используется редко, когда не хочется сильно замедлить компиляцию очень больших программ (друг отметил, что это нужно только маргиналам).
O2
Самый народный уровень.
Множество оптимизаций без speed-space трейдофа: unroll loops, vectorization, strict aliasing.
O3
Включаем максимальный перфоманс отдельной программы. Всё ради скорости. Более агрессивно оптимизируем циклы, больше инлайним, больше векторизируем. Из-за сильной векторизации и инлайнинга бинарник может сильно раздуваться. В том числе поэтому перф может падать, так что на практике не всегда является более оптимальным (при небольшом instruction cache вы станете чаще кешмиссить).
Если увлекаетесь, можно включать при компиляции отдельных файлов, код в которых точно в плюсе. Не задевая всё остальное.
Ofast
Как O3, но включаются опасные оптимизации. Например
--ffast-math.Почему опасные? Потому что скорость получается за счёт точности. Про артефакты можно почитать в Beware of fast-math.
Og (оуджи)
Og = O0 + некоторые оптимизации из O1, не ухудшающие debug experience.
Os
Os = оптимизации из O2, не увеличивающие размер кода + некоторые дополнительные, позволяющие сократить размер исполняемого кода. Трейдофим немного, но в меру.
Oz
Когда у вас мощнейшие ограничения по размеру бинарника и использованию памяти, выбираем Oz. Заодно можно просадить и перф. Но иногда в embedded только так.
Может увеличить кол-во исполняемых инструкций, если их можно закодировать меньшим кол-вом байтов.
Дебагать может быть тоже уже нереально больно. Но как есть.
Мы не говорим про LTO (и ThinLTO) и PGO. Мы не говорим про -march=... и другие. Может когда-нибудь потом..
Доклад в тему: What GCC optimization level is best for you?
В докладе про сами оптимизации и много сравнения с LLVM в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.
👍38🔥17❤8🥴1
#list
0. [talk] Cutting C++ Exception Time by 93.4%.
Khalil Estell рассказывает про то, как он срезает косты при использовании икслючений на железках.
Как настоящий сварщик, он взял самые жирные куски и по одному их поускорял. Причём ускорения довольно прикольные. Местами их сложность примерно около нуля. Но это ж надо было додуматься всё равно!
Ещё чувак очень естественно выглядит на сцене. Мегауверенно. Будем у него учиться.
1. [article] C++20 idioms for parameter packs.
Солиднейшая статья про variadic templates.
Первая треть фокусируется на базе: какие бывают, где можно писать, где нельзя (рекомендую вчитаться, даже если разбираетесь; я нашёл для себя несколько интересностей).
Вторая-третья на идиомах, которые сегодня помогают делать красивое полезное.
Местами ту мач формальная, но я давно убеждён, что C++ сообщество -- сборище душных персон, которые за незнание каждой буквы в стандарте готовы публично растерзать (я сам душный, но не настолько, к счастью).
2. [article] How does it work - The Log-Structured Merge (LSM) Tree.
Там немного пролистайте вниз к теме.
3. [talk] Intro to Large Language Models.
Лекция двухлетней давности от Andrej Karpathy про устройство LLM, как они живут, учатся и ломаются.
Кажется, это что-то фундаментальное на года, что можно будет ещё детям показать для общего развития.
4. [fact]
Смотрел Understanding Optimizers: Helping the Compiler Help You, в котором докладчик говорит про то, что код с
превращается в
И он прав. Это прям хороший наглядный пример лишнего чека и нашего с вами перфа. Но вопрос не только в двойной проверке. Вопрос в исключении. Мы у себя стараемся юзать
Проверку потерять нереально? Конечно это не так. Код бывает разный. Рефакторинги регулярными. Вообще на раз два.
Короче делаем трейдоф перфоманс-скорость дебага проблем в сторону последнего.
Правда я умолчал о важном моменте. Докладчик всё-таки отмечает, что компилятор не делает лишних проверок. Всё там в порядке.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Cutting C++ Exception Time by 93.4%.
Khalil Estell рассказывает про то, как он срезает косты при использовании икслючений на железках.
Как настоящий сварщик, он взял самые жирные куски и по одному их поускорял. Причём ускорения довольно прикольные. Местами их сложность примерно около нуля. Но это ж надо было додуматься всё равно!
Ещё чувак очень естественно выглядит на сцене. Мегауверенно. Будем у него учиться.
1. [article] C++20 idioms for parameter packs.
Солиднейшая статья про variadic templates.
Первая треть фокусируется на базе: какие бывают, где можно писать, где нельзя (рекомендую вчитаться, даже если разбираетесь; я нашёл для себя несколько интересностей).
Вторая-третья на идиомах, которые сегодня помогают делать красивое полезное.
Местами ту мач формальная, но я давно убеждён, что C++ сообщество -- сборище душных персон, которые за незнание каждой буквы в стандарте готовы публично растерзать (я сам душный, но не настолько, к счастью).
2. [article] How does it work - The Log-Structured Merge (LSM) Tree.
Там немного пролистайте вниз к теме.
3. [talk] Intro to Large Language Models.
Лекция двухлетней давности от Andrej Karpathy про устройство LLM, как они живут, учатся и ломаются.
Кажется, это что-то фундаментальное на года, что можно будет ещё детям показать для общего развития.
4. [fact]
std::optional::valueСмотрел Understanding Optimizers: Helping the Compiler Help You, в котором докладчик говорит про то, что код с
std::optional вида
if (x) y = x.value()
превращается в
if (x.m_active) {
if (x.m_active) {
y = x.m_data;
} else { throw ...; }
}
И он прав. Это прям хороший наглядный пример лишнего чека и нашего с вами перфа. Но вопрос не только в двойной проверке. Вопрос в исключении. Мы у себя стараемся юзать
std::optional::value просто потому что когда проверка вдруг потерялась, вы полусаете адекватное исключение с понятной ошибкой. Да, проблему надо ещё поискать, но по крайней мере понятно, что искать. Проверку потерять нереально? Конечно это не так. Код бывает разный. Рефакторинги регулярными. Вообще на раз два.
Короче делаем трейдоф перфоманс-скорость дебага проблем в сторону последнего.
Правда я умолчал о важном моменте. Докладчик всё-таки отмечает, что компилятор не делает лишних проверок. Всё там в порядке.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
🔥12❤6👍5
#cpp
Сегодня Папа C++ в русскоязычном коммьюнити (Антон Полухин) рассказывал про новости комитета стандартизации. В частности C++26.
Контент:
- новая фича (Антон утверждает, что это полезно для метапроги)
Тут Антон показывал, как можно сделать утилитку
Теперь такое из коробки работает для
- compile time
- контракты 🤝 hardening (друзья на век)
- рефлексия:
- в рефлексии доступность к приватным членам класса на месте
- consteval block
- баги всякие
- может быть успеют поправить P3725
- ub в <type_traits>: работа с incomplete типами (не оч корректна)
- basic_string::append/assign принимают std::string (потенциально лишние копии)
- uniform_uint_distribution<uint8_t> == ub
- и ещё много других!
И всякие добавляшки.
Живём!
Сегодня Папа C++ в русскоязычном коммьюнити (Антон Полухин) рассказывал про новости комитета стандартизации. В частности C++26.
Контент:
- новая фича (Антон утверждает, что это полезно для метапроги)
Тут Антон показывал, как можно сделать утилитку
sequence<N>, чтобы заработал такой пример:
auto [i1, i2, i3] = sequence<3>{}; // 0 1 2
Теперь такое из коробки работает для
std::integer_sequence (C++26).- compile time
std::format, что улучшает читаемость ошибок компиляции- контракты 🤝 hardening (друзья на век)
- рефлексия:
- в рефлексии доступность к приватным членам класса на месте
- consteval block
- баги всякие
- может быть успеют поправить P3725
- ub в <type_traits>: работа с incomplete типами (не оч корректна)
- basic_string::append/assign принимают std::string (потенциально лишние копии)
- uniform_uint_distribution<uint8_t> == ub
- и ещё много других!
И всякие добавляшки.
Живём!
🔥27🤮13💩6❤3👎2👍1🤔1🥴1🌚1
#books
Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон. (2021г.)
Данная книга является в некотором роде библией про микросервисы. Если хотите погрузиться в тему, почти наверняка вам посоветуют именно её.
Микросервисы рассматриваются с самых разных сторон. Оглавление такое:
1. Побег из монолитного ада: как жить с монолитом, почему это удобно, pros and cons микросервисов и процессы вокруг. В общем база.
2. Стратегии декомпозиции: как разбить вашу систему на микросервисы в разных плоскостях. Что важно, это не про вынос микросервиса, а про проектирование с нуля.
3. Межпроцессное взаимодействие в микросервисной архитектуры: REST, gRPC, синхронные/асинхронные вызовы.
4. Управление транзакциями с помощью повествований.
5. Проектирование бизнес-логики в микросервисной архитектуре.
6. Разработка бизнес-логики с порождением событий (event driven like системы).
7. Реализация запросов в микросервисной архитектуре.
Про API, CQRS.
8. Шаблоны внешних API.
Про проблемы поддержания внешнего API и api-gateway.
9. Тестирование микросервисов 1.
Общие понятия. Модульные тесты.
10. Тестирование микросервисов 2.
Интеграционные, компонентные и «сквозные» тесты.
11. Разработка сервисов, готовых к промышленному использованию.
Безопасность, конфигурируемость, observability.
12. Развёртывание микросервисов.
Docker, kubernetes, serverless (AWS Lambda).
13. Процесс перехода на микросервисы.
Про то, как взять ваш монолит и распилить его на куски.
Каждая глава сдобрена практическими примерами. В рамках книги сквозной историей разбирается развитие абстрактного ecom приложения FTGO. Можно считать дефолтной доставкой чего-либо. И в каждой главе показывается применение описанных паттернов.
Есть несколько тем, которые мне подарила эта книга. Под «подарила» я понимаю раскрыть базовое понимание, хотя раньше я этого базового понимания насобирать не смог (хотя и не то чтобы пытался, но тут я тоже не пытался, а получилось):
- GraphQL. Выглядит очень прикольно. Прям ощущаю, насколько полезно это может быть в некоторых случаях. Может быть нам пригодилось бы.
- JWT, OAuth.
- Docker, kubernetes. Оказывается, в Яндексе я несколько лет пользовался внутренним аналогом последнего.
- serverless. Честно говоря, я не до конца осознал, но теперь я точно перестану скипать статьи про подобное и дам себе шанс разобраться глубже. Выглядит интересно.
Несколько минусов:
- текст местами без причины сложный.
Бывают предложения, которые можно упростить без потери смысла. Возможно это просто стиль письма у автора. Но материал и так сложный, а когда про него ещё и сложно пишут, становится тяжелее в квадрате. Не надо так.
- [относится к русскому изданию] книга чрезмерно локализована.
Endpoint назван «конечной точкой», а mock в теме тестирования «макетом». Сразу видно руку технического переводчика. REST, gRPC и CQRS не переведены, а вот эти термины да. Хотя имхо стоило бы их оставить как есть. Это мешает пониманию (мне, человеку с опытом, приходится прикладывать усилия для понимания простых предложений с этими терминами).
В итоге книга нормикс. Даёт неплохую базу и даже больше. Но приготовьтесь напрягаться и осознавать. Вдумываться. Это займёт много сил и мыслетоплива. Возможно местами чрезмерно.
7/10.
Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон. (2021г.)
Данная книга является в некотором роде библией про микросервисы. Если хотите погрузиться в тему, почти наверняка вам посоветуют именно её.
Микросервисы рассматриваются с самых разных сторон. Оглавление такое:
1. Побег из монолитного ада: как жить с монолитом, почему это удобно, pros and cons микросервисов и процессы вокруг. В общем база.
2. Стратегии декомпозиции: как разбить вашу систему на микросервисы в разных плоскостях. Что важно, это не про вынос микросервиса, а про проектирование с нуля.
3. Межпроцессное взаимодействие в микросервисной архитектуры: REST, gRPC, синхронные/асинхронные вызовы.
4. Управление транзакциями с помощью повествований.
5. Проектирование бизнес-логики в микросервисной архитектуре.
6. Разработка бизнес-логики с порождением событий (event driven like системы).
7. Реализация запросов в микросервисной архитектуре.
Про API, CQRS.
8. Шаблоны внешних API.
Про проблемы поддержания внешнего API и api-gateway.
9. Тестирование микросервисов 1.
Общие понятия. Модульные тесты.
10. Тестирование микросервисов 2.
Интеграционные, компонентные и «сквозные» тесты.
11. Разработка сервисов, готовых к промышленному использованию.
Безопасность, конфигурируемость, observability.
12. Развёртывание микросервисов.
Docker, kubernetes, serverless (AWS Lambda).
13. Процесс перехода на микросервисы.
Про то, как взять ваш монолит и распилить его на куски.
Каждая глава сдобрена практическими примерами. В рамках книги сквозной историей разбирается развитие абстрактного ecom приложения FTGO. Можно считать дефолтной доставкой чего-либо. И в каждой главе показывается применение описанных паттернов.
Есть несколько тем, которые мне подарила эта книга. Под «подарила» я понимаю раскрыть базовое понимание, хотя раньше я этого базового понимания насобирать не смог (хотя и не то чтобы пытался, но тут я тоже не пытался, а получилось):
- GraphQL. Выглядит очень прикольно. Прям ощущаю, насколько полезно это может быть в некоторых случаях. Может быть нам пригодилось бы.
- JWT, OAuth.
- Docker, kubernetes. Оказывается, в Яндексе я несколько лет пользовался внутренним аналогом последнего.
- serverless. Честно говоря, я не до конца осознал, но теперь я точно перестану скипать статьи про подобное и дам себе шанс разобраться глубже. Выглядит интересно.
Несколько минусов:
- текст местами без причины сложный.
Бывают предложения, которые можно упростить без потери смысла. Возможно это просто стиль письма у автора. Но материал и так сложный, а когда про него ещё и сложно пишут, становится тяжелее в квадрате. Не надо так.
- [относится к русскому изданию] книга чрезмерно локализована.
Endpoint назван «конечной точкой», а mock в теме тестирования «макетом». Сразу видно руку технического переводчика. REST, gRPC и CQRS не переведены, а вот эти термины да. Хотя имхо стоило бы их оставить как есть. Это мешает пониманию (мне, человеку с опытом, приходится прикладывать усилия для понимания простых предложений с этими терминами).
В итоге книга нормикс. Даёт неплохую базу и даже больше. Но приготовьтесь напрягаться и осознавать. Вдумываться. Это займёт много сил и мыслетоплива. Возможно местами чрезмерно.
7/10.
1✍25👍19❤13🔥5😁1
#highload
Принёс отдельные доклады с Яндекс Tech Tour (в прошлом году это был foodtech tour, на котором я выступал в Минске).
1️⃣ Как мы переосмыслили поиск лекарств в Яндекс Еде. Сергей Синягин.
Когда вы открываете Еду, ищутся все доступные вам заведения. И бывает, что вам доступны несколько заведений одного бренда. Тогда заведения дедуплицируются и остаётся какое-то одно. Проблема в том, что в этом заведении может не быть нужного вам товара (например конкретных таблеток в конкретной аптеке), а в отброшенным они были!
Серёжа рассказывает, как меняли архитектуру, чтобы уметь чаще удовлетворять пользовательские запросы.
2️⃣ Как мы пересобрали инфраструктуру Маркета и не сломали всё вокруг. Егор Быховцев.
Егор рассказывает про изменение концепции оркестрации в бэкенде Маркета.
Буквально недавно меня убедили, что такое крута. Я верю. После доклада Егора убедился ещё больше.
Внутри и снаружи решение называется apphost. Глядишь, выкатят в опенсорс скоро.
3️⃣ LLM Cache в поиске Лавки. Алексей Щекалев.
Лёша рассказывает тлдр про развитие поиска в Лавке.
Раз у нас ассортимент небольшой, то можно сделать кеш ответов на самые популярные запросы. Вот ребята это и сделали.
Имхо решение бомба. Наикрасивейше. Это не только про качество, но и про тайминги.
Ещё круто, что ребята затащили это в т.ч. в Еду. Круто, когда внутри экосистемы один сервис чуть ли не бесплатно помогает другому крутыми технологиями.
4️⃣ Event-Driven архитектура в Цикле Заказа Яндекс Лавки. Миша Горбушин.
Миша рассказывает про ЦЗ Лавки, зачем его делали event-driven, собсна как это делали. И про разные проблемы по пути.
5️⃣ Как разрабатывают и улучшают алгоритмы логистики в Яндекс Еде. Дима Ефимов.
Дима рассказывает про процесс улучшения алгоритмов доставки в Еде. В целом из чего доставка состоит. На какие метрики смотрят. Про разные уникальности доставки и местные АБ.
Принёс отдельные доклады с Яндекс Tech Tour (в прошлом году это был foodtech tour, на котором я выступал в Минске).
Когда вы открываете Еду, ищутся все доступные вам заведения. И бывает, что вам доступны несколько заведений одного бренда. Тогда заведения дедуплицируются и остаётся какое-то одно. Проблема в том, что в этом заведении может не быть нужного вам товара (например конкретных таблеток в конкретной аптеке), а в отброшенным они были!
Серёжа рассказывает, как меняли архитектуру, чтобы уметь чаще удовлетворять пользовательские запросы.
Егор рассказывает про изменение концепции оркестрации в бэкенде Маркета.
Буквально недавно меня убедили, что такое крута. Я верю. После доклада Егора убедился ещё больше.
Внутри и снаружи решение называется apphost. Глядишь, выкатят в опенсорс скоро.
Лёша рассказывает тлдр про развитие поиска в Лавке.
Раз у нас ассортимент небольшой, то можно сделать кеш ответов на самые популярные запросы. Вот ребята это и сделали.
Имхо решение бомба. Наикрасивейше. Это не только про качество, но и про тайминги.
Ещё круто, что ребята затащили это в т.ч. в Еду. Круто, когда внутри экосистемы один сервис чуть ли не бесплатно помогает другому крутыми технологиями.
Миша рассказывает про ЦЗ Лавки, зачем его делали event-driven, собсна как это делали. И про разные проблемы по пути.
Дима рассказывает про процесс улучшения алгоритмов доставки в Еде. В целом из чего доставка состоит. На какие метрики смотрят. Про разные уникальности доставки и местные АБ.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤮7🔥6🗿2❤1👍1
#list
Т.к. впереди намечается солидное количество выходных, можно покайфовать под что-то интересное.
Контент будет нетехническим для разнообразия. Но в тему айтишечки и вот этого всего. Предлагаю вам ощутить напряжённейшую жизнь стартапов и их естественного развития. Иногда успешного. Иногда не очень.
Всё ниже так или иначе связано с крепкой политикой и подковёрными играми. Мне такое нравится (наблюдать, не участвовать).
👉 Сериал На взводе: Битва за Uber.
Отличнейший сериал про некоторые важные этапы развития Uber, когда компания ещё была молодой и токсичной под руководством Travis Kalanik. Так сказать, полутёмные времена компании (полу, потому что было тяжко, но они непомерно росли, так что может цель и оправдывает средства?).
Состоит из одного сезона в 7 серий примерно по часу.
Можно заодно кайфануть от непростого английского. Тут много эмоций, быстрой речи и невнятных разговоров на специфические темы. Кайф.
Есть ещё книга, по которой сериал и был снят, если вы предпочитаете подобный формат.
👉 Книга Миллиард за мечту, или Как дерзость и непомерные амбиции Адама Неймана построить новое общество обернулись крахом империи WeWork. Ривз Видеман.
Adam Neumann придумал новый формат коворкингов, который превратился в честный стартап-единорог. Правда потом всё зафакапилось. Жаль братка.
👉 Книга Дурная кровь. Тайны и ложь одного стартапа Кремниевой долины. Джон Каррейру.
А эта книга про компанию Theranos и её основательницу Elizabeth Holmes, которая хотела изменить мир, дав людям возможность делать быстрые и качественные анализы в любой момент.
Амбиция крутая, а методы достижения цели не очень. Внутри солидное количество надувалова со стороны топ-менеджеров и непомерно токсичное руководство.
Штош!
В отличие от предыдущих двух, книга не просто пересказывает происходящие события, а является компиляцией расследования чувака, который своими статьями и копаниями приложил руку (или перо) к проблемам компании.
Опять же, есть аналог, если не хочется читать фул книгу: Изобретатель: Жажда крови в Силиконовой долине, -- документалка про всё то же.
Если вы знаете что-то похожее, поделитесь!
А с меня останутся только итоги года : )
Т.к. впереди намечается солидное количество выходных, можно покайфовать под что-то интересное.
Контент будет нетехническим для разнообразия. Но в тему айтишечки и вот этого всего. Предлагаю вам ощутить напряжённейшую жизнь стартапов и их естественного развития. Иногда успешного. Иногда не очень.
Всё ниже так или иначе связано с крепкой политикой и подковёрными играми. Мне такое нравится (наблюдать, не участвовать).
👉 Сериал На взводе: Битва за Uber.
Отличнейший сериал про некоторые важные этапы развития Uber, когда компания ещё была молодой и токсичной под руководством Travis Kalanik. Так сказать, полутёмные времена компании (полу, потому что было тяжко, но они непомерно росли, так что может цель и оправдывает средства?).
Состоит из одного сезона в 7 серий примерно по часу.
Можно заодно кайфануть от непростого английского. Тут много эмоций, быстрой речи и невнятных разговоров на специфические темы. Кайф.
Есть ещё книга, по которой сериал и был снят, если вы предпочитаете подобный формат.
👉 Книга Миллиард за мечту, или Как дерзость и непомерные амбиции Адама Неймана построить новое общество обернулись крахом империи WeWork. Ривз Видеман.
Adam Neumann придумал новый формат коворкингов, который превратился в честный стартап-единорог. Правда потом всё зафакапилось. Жаль братка.
👉 Книга Дурная кровь. Тайны и ложь одного стартапа Кремниевой долины. Джон Каррейру.
А эта книга про компанию Theranos и её основательницу Elizabeth Holmes, которая хотела изменить мир, дав людям возможность делать быстрые и качественные анализы в любой момент.
Амбиция крутая, а методы достижения цели не очень. Внутри солидное количество надувалова со стороны топ-менеджеров и непомерно токсичное руководство.
Штош!
В отличие от предыдущих двух, книга не просто пересказывает происходящие события, а является компиляцией расследования чувака, который своими статьями и копаниями приложил руку (или перо) к проблемам компании.
Опять же, есть аналог, если не хочется читать фул книгу: Изобретатель: Жажда крови в Силиконовой долине, -- документалка про всё то же.
Если вы знаете что-то похожее, поделитесь!
А с меня останутся только итоги года : )
👍14❤5👎5🔥2🐳1
# 2025
2024, 2023, 2022.
Посты:
- про хорошего разработчика;
- CRDT premier;
- первоапрельский пост про размеры;
- мои фавориты из шортлиста Технотекст 7;
- про балансировку трафика;
- микрогайд по type traits;
- пишем make_index_sequence;
- про стандартную библиотеку;
- speculative execution;
- проблемы с shared database подходом;
- про читаемость кода 2;
- опять ub моими руками;
- про найм;
- про бинарный поиск;
- про флаги оптимизаций (O);
- новости от РГ21++;
- контент на праздники;
- пачки ссылок: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25;
Люди и контент:
- Андрей Гейн и string matching premier;
- Лёша Быков и metastable failures;
- Саша Федькин и мысли про микросервисы;
- Паша Сухов и военный синус;
Сборники с конференций:
- Saint TeamLead Conf 2024;
- Saint Highload++ 2024;
- С++ Russia 2024;
- Яндекс Day&Night;
- C++ Zero Cost Conf 2025;
- Highload++ 2024 first, second;
- Яндекс Tech Tour 2025;
Книги:
- Искусство планирования мощностей. Джон Оллспоу;
- API. Сергей Константинов;
- Мама, я тимлид! Марина Перескокова;
- Вредные советы для C++ программистов. Андрей Карпов;
- System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан;
- Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон;
Светился:
- в гостях у ребят из Выше Вилки;
- был с лайтнингом на C++ Russia 2025, рассказывал как мы в Лавке упрощали разработку. Записи нет, материалов не будет;
- C++ Zero Cost Conf 2025: i, j, k и шаблоны: вспоминаем линейную алгебру. Записи нет.
Самый зашареный пост: Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон (>110 шеров).
Вас стало в 2 раза больше (на 2400 примерно).
Звали выступать на конфу, но я не ходил.
Суммарно 2 месяца из 12 провёл вне страны проживания.
7 раз приходили за рекламой.
Не понял, лишился четверти мудрости (удалил восьмёрку) или стал мудрее (на год).
Уже 10 месяцев чист от никотина. Планирую так ещё лет 50-70.
С любимой женщиной взяли собаку.
Любимая женщина стала любимой женой.
Уволился из Яндекса. Устроился в Bloomberg.
Семьёй из троих сменили Минск на Лондон.
Не умер, что особенно приятно.
Буду безмерно счастлив, если расскажете про канал друзьям/коллегам/в тематических чатах.
2024, 2023, 2022.
Посты:
- про хорошего разработчика;
- CRDT premier;
- первоапрельский пост про размеры;
- мои фавориты из шортлиста Технотекст 7;
- про балансировку трафика;
- микрогайд по type traits;
- пишем make_index_sequence;
- про стандартную библиотеку;
- speculative execution;
- проблемы с shared database подходом;
- про читаемость кода 2;
- опять ub моими руками;
- про найм;
- про бинарный поиск;
- про флаги оптимизаций (O);
- новости от РГ21++;
- контент на праздники;
- пачки ссылок: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25;
Люди и контент:
- Андрей Гейн и string matching premier;
- Лёша Быков и metastable failures;
- Саша Федькин и мысли про микросервисы;
- Паша Сухов и военный синус;
Сборники с конференций:
- Saint TeamLead Conf 2024;
- Saint Highload++ 2024;
- С++ Russia 2024;
- Яндекс Day&Night;
- C++ Zero Cost Conf 2025;
- Highload++ 2024 first, second;
- Яндекс Tech Tour 2025;
Книги:
- Искусство планирования мощностей. Джон Оллспоу;
- API. Сергей Константинов;
- Мама, я тимлид! Марина Перескокова;
- Вредные советы для C++ программистов. Андрей Карпов;
- System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан;
- Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон;
Светился:
- в гостях у ребят из Выше Вилки;
- был с лайтнингом на C++ Russia 2025, рассказывал как мы в Лавке упрощали разработку. Записи нет, материалов не будет;
- C++ Zero Cost Conf 2025: i, j, k и шаблоны: вспоминаем линейную алгебру. Записи нет.
Самый зашареный пост: Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон (>110 шеров).
Вас стало в 2 раза больше (на 2400 примерно).
Звали выступать на конфу, но я не ходил.
Суммарно 2 месяца из 12 провёл вне страны проживания.
7 раз приходили за рекламой.
Не понял, лишился четверти мудрости (удалил восьмёрку) или стал мудрее (на год).
Уже 10 месяцев чист от никотина. Планирую так ещё лет 50-70.
С любимой женщиной взяли собаку.
Любимая женщина стала любимой женой.
Уволился из Яндекса. Устроился в Bloomberg.
Семьёй из троих сменили Минск на Лондон.
Не умер, что особенно приятно.
Буду безмерно счастлив, если расскажете про канал друзьям/коллегам/в тематических чатах.
301❤69🔥43❤🔥15👍8
К сожалению, я был немного неосторожен и невнимателен.
Предыдущий пост улетел раньше нужного, потому что шчедул стоял не на то время. В том числе поэтому он был сырым и без некоторой важной информации.
Что важного хочется подчеркнуть:
- как оно в этом Лондоне я ещё сам хз. Мы тут всего пару дней. Напишу через год.
- same про новое место.
Расписал инфу про год вот тут: https://github.com/dasfex/articles/blob/trunk/2025.md
(фотки большие, поправлю попозже!)
Пожелание на следующий год через пару дней.
Напомню, что есть ещё @memesfromhole, @dzikart и @khdocs.
С Наступающим Вас!
Предыдущий пост улетел раньше нужного, потому что шчедул стоял не на то время. В том числе поэтому он был сырым и без некоторой важной информации.
Что важного хочется подчеркнуть:
- как оно в этом Лондоне я ещё сам хз. Мы тут всего пару дней. Напишу через год.
- same про новое место.
Расписал инфу про год вот тут: https://github.com/dasfex/articles/blob/trunk/2025.md
(фотки большие, поправлю попозже!)
Пожелание на следующий год через пару дней.
Напомню, что есть ещё @memesfromhole, @dzikart и @khdocs.
С Наступающим Вас!
GitHub
articles/2025.md at trunk · dasfex/articles
My articles which I don't want to store on telegra.ph, cause its kinda shitty. - dasfex/articles
👍19❤12🔥7
#list
0. [2026]
Начинается очередной год. Здравствуйте.
В конце прошлого года я много думал о направлении в жизни. Туда-сюда и решил, чего хочется.
Хочется делать сложные вещи.
Под сложными я в основном понимаю не только сложные, но и долгие. Когда результат будет получен через год-два. Хочется прочитать мало больших книг, а не много маленьких. Написать мало больших постов. Завести пару привычек и разгрести огромные залежи информации.
Хочется уходить от чувства ложной продуктивности и ложного счастья. Быстрый результат, дающий быстрое удовольствие, хочется исключить. Рилсы тоже в идеале не смотреть.
Такой план на год. Как получится, расскажу в декабре.
Успехов и вам.
1. [talk] Implement the C++ Standard Library: Design, Optimisations, Testing while Implementing Libc++.
Hui Xie рассказывает про точечные оптимизации и связанные с ними проблемы в libc++.
Например, как экономят память ввходить в хату вставлять в
А в конце рассказывается про тестирование стд либы. Как оно всё там непросто у ребят.
2. [article] Logging sucks.
Какой-то чувак сделал сайт про то, как правильно логировать в ваших сервисах, чтобы логи начали быстро и честно приносить пользу.
В конце предлагает консультации за бабосики. Но может вы и сами разберётесь.
3. [article] Simplify hashing in C++.
Автор справедливо замечает, что пользоваться std::hash не очень приятно и что это надо поправить. Немудрыми улучшениями он решает эту проблему.
Опустим момент, что выбрать хороший hash_combine сложно.
4. [article] The Math of Why You Can't Focus at Work.
Статья про мат модель вашего фокуса в задачах, проблемы в этом непростом деле быть продуктивным и потенциальные их решения.
Всё конечно логично, но никогда не вредно.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [2026]
Начинается очередной год. Здравствуйте.
В конце прошлого года я много думал о направлении в жизни. Туда-сюда и решил, чего хочется.
Хочется делать сложные вещи.
Под сложными я в основном понимаю не только сложные, но и долгие. Когда результат будет получен через год-два. Хочется прочитать мало больших книг, а не много маленьких. Написать мало больших постов. Завести пару привычек и разгрести огромные залежи информации.
Хочется уходить от чувства ложной продуктивности и ложного счастья. Быстрый результат, дающий быстрое удовольствие, хочется исключить. Рилсы тоже в идеале не смотреть.
Такой план на год. Как получится, расскажу в декабре.
Успехов и вам.
1. [talk] Implement the C++ Standard Library: Design, Optimisations, Testing while Implementing Libc++.
Hui Xie рассказывает про точечные оптимизации и связанные с ними проблемы в libc++.
Например, как экономят память в
std::expected, почему for_each работает быстрее цикла для std::deque, как правильно std::flat_map и всякое другое. А в конце рассказывается про тестирование стд либы. Как оно всё там непросто у ребят.
2. [article] Logging sucks.
Какой-то чувак сделал сайт про то, как правильно логировать в ваших сервисах, чтобы логи начали быстро и честно приносить пользу.
В конце предлагает консультации за бабосики. Но может вы и сами разберётесь.
3. [article] Simplify hashing in C++.
Автор справедливо замечает, что пользоваться std::hash не очень приятно и что это надо поправить. Немудрыми улучшениями он решает эту проблему.
Опустим момент, что выбрать хороший hash_combine сложно.
4. [article] The Math of Why You Can't Focus at Work.
Статья про мат модель вашего фокуса в задачах, проблемы в этом непростом деле быть продуктивным и потенциальные их решения.
Всё конечно логично, но никогда не вредно.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
1❤26👍11😱1
#cpp
System Level Meetup 2025
🌼 Первым докладом был «Корутинные оптимизации в компиляторах» от глыбы Константина Владимирова и коллеги глыбы Юлия Тарасова.
Доклад про корутины концептуально, их реализацию и разные оптимизации по теме (в частности в LLVM). Сложно блин! И поэтому круто. Правда придётся потом пересмотреть ещё пару раз.
🌼 Далее Сергей Чеботарёв рассказывал «Модули С++20 в существующий проект: лёгкая прогулка или прыжок в бездну?».
Сергей рассказывал про попытку начать использовать модули в реальном проекте: какой подход выбрали и какую кучу проблем насобирали по пути. С решениями конечно.
🌼 «LRU-кеш: от решения с собеседования до production-уровня» Ильи Шишкова.
Кеш у Ильи не базовый бэкендерский. Он хранит какие-то артефакты в шареной между различными процессами памяти.
Имхо крутая история про полезность правильного трейдофа. На самом деле иногда нам достаточно приблизительное решение, что позволяет упрощать/экономить. Надо учиться такое подмечать и вовремя использовать.
Код конечно у ребят глаз не радует. Может я привередливый.
Круто #1: в итоге получается не жоское решение, которое разваливает всё-всё, а чуть медленее на большинстве запросов, зато гораздо быстрее на тяжёлом хвосте. Уменьшать дисперсию тоже очень полезно. Это предсказуемость, которой иногда сильно не хватает.
Круто #2: Илья несколько раз говорит, что к чему-то не дошёл в процессе решения задачи.
Важно уметь вовремя остановиться. Мы можем улучшать что-то бесконечно, но если вы начинаете тратить больше, чем в итоге получаете, скажите себе хватит. Это про взрослое отношение к задачам.
🌼 «Когда действительно нужны алгоритмы: опыт оптимизации kd-tree» Саши Голубева.
Саша рассказывает как устроено само дерево и каким образом оно применяется в Такси для поиска исполнителя заказа.
Потом начинается движуха с оптимизациями, чтобы срезать тайминги и заодно CPU.
Все оптимизации сами по себе довольно простые, но вместе дают солиднейшие результаты. Это нам урок.
🌼 Анастасия Черникова рассказывала «Анатомия чекеров в clang-tidy».
Доклад буквально про то, как он называется.
Анастасия рассказывает про разные способы проверять качество кода. Глубже уходит в статический анализ. Рассказывает про AST, разные классы чекеров и сами чекеры из LLVM инфраструктуры.
А дальше рассказывает, как она дорабатывала один из чекеров и как это вообще делается.
🌼 Заканчивал C++ трек доклад «Строки, строки, строки и initializer_list» Антона Полухина.
Антон рассказывал про разные проблемы со строками, их лайфтаймом,
Мне понравилось.
System Level Meetup 2025
🌼 Первым докладом был «Корутинные оптимизации в компиляторах» от глыбы Константина Владимирова и коллеги глыбы Юлия Тарасова.
Доклад про корутины концептуально, их реализацию и разные оптимизации по теме (в частности в LLVM). Сложно блин! И поэтому круто. Правда придётся потом пересмотреть ещё пару раз.
🌼 Далее Сергей Чеботарёв рассказывал «Модули С++20 в существующий проект: лёгкая прогулка или прыжок в бездну?».
Сергей рассказывал про попытку начать использовать модули в реальном проекте: какой подход выбрали и какую кучу проблем насобирали по пути. С решениями конечно.
🌼 «LRU-кеш: от решения с собеседования до production-уровня» Ильи Шишкова.
Кеш у Ильи не базовый бэкендерский. Он хранит какие-то артефакты в шареной между различными процессами памяти.
Имхо крутая история про полезность правильного трейдофа. На самом деле иногда нам достаточно приблизительное решение, что позволяет упрощать/экономить. Надо учиться такое подмечать и вовремя использовать.
Код конечно у ребят глаз не радует. Может я привередливый.
Круто #1: в итоге получается не жоское решение, которое разваливает всё-всё, а чуть медленее на большинстве запросов, зато гораздо быстрее на тяжёлом хвосте. Уменьшать дисперсию тоже очень полезно. Это предсказуемость, которой иногда сильно не хватает.
Круто #2: Илья несколько раз говорит, что к чему-то не дошёл в процессе решения задачи.
Важно уметь вовремя остановиться. Мы можем улучшать что-то бесконечно, но если вы начинаете тратить больше, чем в итоге получаете, скажите себе хватит. Это про взрослое отношение к задачам.
🌼 «Когда действительно нужны алгоритмы: опыт оптимизации kd-tree» Саши Голубева.
Саша рассказывает как устроено само дерево и каким образом оно применяется в Такси для поиска исполнителя заказа.
Потом начинается движуха с оптимизациями, чтобы срезать тайминги и заодно CPU.
Все оптимизации сами по себе довольно простые, но вместе дают солиднейшие результаты. Это нам урок.
С Сашей мы год вместе занимались С++ community в Яндексе. Вот такой мужик👍
Ещё на C++ Russia 2024 я Сашу вином облил. Не специально.
🌼 Анастасия Черникова рассказывала «Анатомия чекеров в clang-tidy».
Доклад буквально про то, как он называется.
Анастасия рассказывает про разные способы проверять качество кода. Глубже уходит в статический анализ. Рассказывает про AST, разные классы чекеров и сами чекеры из LLVM инфраструктуры.
А дальше рассказывает, как она дорабатывала один из чекеров и как это вообще делается.
🌼 Заканчивал C++ трек доклад «Строки, строки, строки и initializer_list» Антона Полухина.
Антон рассказывал про разные проблемы со строками, их лайфтаймом,
std::string_view, кастомную поделку для литералов (чтобы быть уверенными в их времени жизни), а ещё, конечно же, про то, как избегать лишних аллокаций там, где мы можем случайно их словить.Мне понравилось.
🔥27👍12❤3👏2
#list
0. [talk] Could C++ Developers Handle an ABI Break Today?
Доклад про потенциальные последствия слома ABI. Не про мнение докладчика или нужно ли нам это делать в С++, а просто что будет, если уже случилось. Показывает как теоретически, так и на примерах уже произошедших сломах ABI.
Может и правда не надо его ломать. Непонятно!
Но, думаю, никто не был бы против более быстрых unordered контейнеров из-за перехода на открытую адресацию. Или возможности работать с
1. [article] How to contribute to Abseil with a visible performance gain.
Danila Kutenin рассказывал, как он оптимизировал флаги в abseil.
Красиво блин.
2. [article] Как построить прогноз спроса и не потерять голову.
Пару лет назад ребята из Самоката написали статью про прогнозирование закупок товаров на склады. В Лавке, очевидно, есть точно такая же задача с, на мой взгляд, похожей спецификой. Как оно там работало, не знаю, но думаю, что в статье общие проблемы и решения хорошо описывают ситуацию.
3. [article] Why speed matters.
Паша @cpp_durka Сухóв подкинул важную базу.
4. [fact] MFA fatigue.
Multi factor authentication fatigue атака -- это когда злодеи-анонимусы узнали ваши логин и пароль и пытаются взять вас на лоха, задудосив попытками войти в аккаунт. Вам придёт много-много уведомлений (ведь у вас как минимум 2fa), будете отвлекаться и тыкнете «Разрешить», чтобы не мешало. Ну или случайно кликните и дадите доступ.
Вот, например, Uber так на самом деле взламывали.
Это конечно надо глубоко понимать людей, чтобы впервые такое придумать. Восхищён.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Could C++ Developers Handle an ABI Break Today?
Доклад про потенциальные последствия слома ABI. Не про мнение докладчика или нужно ли нам это делать в С++, а просто что будет, если уже случилось. Показывает как теоретически, так и на примерах уже произошедших сломах ABI.
Может и правда не надо его ломать. Непонятно!
Но, думаю, никто не был бы против более быстрых unordered контейнеров из-за перехода на открытую адресацию. Или возможности работать с
int128_t.1. [article] How to contribute to Abseil with a visible performance gain.
Danila Kutenin рассказывал, как он оптимизировал флаги в abseil.
Красиво блин.
2. [article] Как построить прогноз спроса и не потерять голову.
Пару лет назад ребята из Самоката написали статью про прогнозирование закупок товаров на склады. В Лавке, очевидно, есть точно такая же задача с, на мой взгляд, похожей спецификой. Как оно там работало, не знаю, но думаю, что в статье общие проблемы и решения хорошо описывают ситуацию.
3. [article] Why speed matters.
Паша @cpp_durka Сухóв подкинул важную базу.
4. [fact] MFA fatigue.
Multi factor authentication fatigue атака -- это когда злодеи-анонимусы узнали ваши логин и пароль и пытаются взять вас на лоха, задудосив попытками войти в аккаунт. Вам придёт много-много уведомлений (ведь у вас как минимум 2fa), будете отвлекаться и тыкнете «Разрешить», чтобы не мешало. Ну или случайно кликните и дадите доступ.
Вот, например, Uber так на самом деле взламывали.
Это конечно надо глубоко понимать людей, чтобы впервые такое придумать. Восхищён.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
❤1🤓1