#list

0. [talk] Быстрее быстрой или Как обогнать std::sort с помощью поразрядной сортировки.

Дмитрий Изволов рассказывает про поразрядную сортировку, как она пишется, как её надо проектировать по уму и, что самый жир, как он закоммитил ускорение std::stable_sort с её помощью в llvm.

Дима кстати был моим первым руководителем в Лавке. Ровно тем, кто меня нанял в команду. Правда довольно быстро он из Лавки убежал, так что поработать вместе мы успели дай бог 3 месяца.

Мне очень понравилась финалка. В то время, когда другие нанимающие менеджеры просто задавали и отвечали на вопросы (причём не всегда успешно), Дима в том числе просто открыл мой github и спросил, что я хотел бы ему показать. У меня была какая-то простенькая реализация вычисления n-ого числа Фибоначчи возведением матрицы в степень на компиляции, чем я с ним и поделился. Мы обсудили. Он предложил, как код упростить.
Не зря писал. Пригодилось. Понравилось.

Я тоже иногда такой формат иногда практиковал, но, к сожалению, у кандидатов не очень часто на github что-то есть.

1. [article] Unconventional PostgreSQL Optimizations.

Автор рассказывает про три небаянистые оптимизации, которые вы, возможно, можете применить в своих проектах.

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

2. [article] Why Senior Engineers Let Bad Projects Fail.

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

3. [article] How I estimate work as a staff software engineer.

Автор рассуждает на тему оценок задач, после чего говорит, что на самом деле не оценивать задачи, а возможный объём работы за имеющееся время. Типа перевернул всё.
Ну может и да! Надо поприменять и понять.

4. [article] Scaling PostgreSQL to power 800M ChatGPT users.

Статью прилагаю как антипаттерн.

Тема у чуваков отличная. Огромная нагрузка. Сто процентов сложнейшие инженерные задачи.

Что мы видим внутри?
Проход по базовым пунктам, каждый из которых вообще-то можно раскрыть на отдельную статью, но тут пробежали по верхам и на этом закончили.
Вот я бы почитал про оптимизацию отдельных запросов, например. Или про workload isolation. Там сто процентов есть крутые детали.

А так выглядит как набор топиков на ресёрч.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [videos]

Сегодня вместо серьёзных докладов 2 фановых видоса про эксплойты, minecraft, необъятную находчивость людей (программистов в частности), иногда социальную инженерию.

• The Fall of Minecraft's 2b2t.
• RANDAR: Minecraft's Most DANGEROUS Exploit.

1. [article] Debugging an evil Go runtime bug.

Автор рассказывает про мощнейшее расследование краша в Go-туле.

Когда я читаю подобное, мысленно отмечаю моменты, в которые я бы остановился из-за нехватки понимания или принятия решения, что знать ответ не стоит сил. Тут раз 7 так точно.
Автор крут.

2. [article] Uber’s Rate Limiting System.

Uber рассказали про свой Global Rate Limiter. Пару интересных хайлайтов:
- описывают парк проблем из-за зоопарка решений
- целились сделать процесс понимания «пора ли лимитить» как можно более простым, что логично
- конечно же там жирная нагрузка
- научились автоматически подстраивать лимиты, исходя из истории нагрузки.

Старый пост про рейтлимитинг: https://t.me/thisnotes/271

3. [article] In defence of swap: common misconceptions.

Автор рассказывает про то, зачем на самом деле нужен swap, в каком месте люди заблуждаются и как его потюнить при необходимости.
Я даже заблудиться в понимании ещё особо не успел, так что good for me!

4. [article] Вспомним старый пост про geospatial indexing.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#cpp

Пост небольшой, но с картинками. Даже не пост, а заметка.

Heap pinning: https://github.com/dasfex/articles/blob/trunk/heap_pinning.md

#cpp

Сегодня только один доклад. Зато какой!

Using Floating-point in C++: What Works, What Breaks, and Why. Egor Suvorov.

Егор рассказывает про устройство чисел с плавающей запятой. Миллион возможных проблем с ними в рамках спецификации, корнеров и C++. С примерами, как и что может пойти не так (некоторые примеры на мой взгляд достойны @cpp_durka Паши Сухова).

Я смотрел другие доклады Егора. Они всегда стройне, полные. От начала до конца. Но после этого доклада огромная гора уважения автору (вторая). Это ж сколько информации надо было перелопатить, чтобы прийти и рассказать потом про эту необъёмную яму, в которой закопаться и потеряться в любой случайный момент не составляет никакого труда. Сколько усидчивости и терпения надо иметь, чтобы родить один доклад. Очень красивый и подробный.

Потрясающе.

Один из докладов Егора уже упоминал тут: пункт 3 в t.me/thisnotes/285.

Другой его доклад (lightning) тоже недавно выложили: ⁠Do Not Compare Integers and Floats in C++: Sorting Pitfalls, UB & Type Conversion Explained.
Тут про проблему сортировки целочисленных типов вместе с числами с плавающей запятой.
Может надо как Амазон. Посадить 1000 человек. Пусть на глаз сравнивают. Долго, зато не ошибёмся!
Тема упоминается и в полном докладе, но вдруг вам только это интересно.

Что-то про сложение чисел с плавающей точкой уже упоминалось: t.me/thisnotes/288

Там же в комментах накидывали пачку статей, на которую и Егор, судя по всему, опирался: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

И тут под названием «What Every Computer Scientist Should Know About Floating-Point Arithmetic» есть жирная статья (хотя я привык её видеть в виде 100страничной пдфки) про то, что надо знать про floating point numbers: https://floating-point-gui.de/references/
Я долго думал, что когда-нибудь прочитаю, но наверное докладом Егора тему для себя можно закрыть.

Наслаждайтесь.

#cpp

The worst programming language of all time.

Или нет?

Возможно вам уже попадалось видео: youtube.com/watch?v=7fGB-hjc2Gc, рассказывающее, почему C++ — самый ужасный язык программирования. Разберём автором рассказанное.

https://github.com/dasfex/articles/blob/trunk/the_worst_programming_language_of_all_time.md

[Пост появился раньше на пару дней на] Patreon и Boosty.

Спасибо Artyom Garkavy за поддержку.

Доброе апреля.

1. Коллега точно подметил, что -Wall это wall of text.

2. Помните, я писал про книгу про API от Сергея Константинова?
У Сергея ещё книга про пиво есть. Мне недавно метко подсказали, что

API + пиво = IPA

Не знаю, как вам это поможет, но в этом что-то есть.

3. Если пропустили контент, то у Miyagi & Эндшпиль вышел трек про std::vector. Так и называется — Vector.

Доброе понедельничное утро.

Два прошлых года я выступал на C++ Zero Cost Conf. Eсли вас тут не было, то в 2024 я рассказывал про NRVO, а в прошлом году всякие приколы про шаблоны и математику.

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

Конференция никуда не девается и в этом году: 1 августа можно провести в компании коллег по цеху, особенно если вы в Москве или Белграде.
Моя роль от потенциального докладчика сместилась в сторону члена программного комитета.

И мы принимаем доклады!
У вас есть возможность податься до 11 мая.

Детали тут: https://cppzerocostconf.yandex.ru/

Вот картиночка. Не зря ж её кто-то рисовал.

#books #cpp

C++17 - Iterating Problems.

Я бы сказал, что это не книга, а книжка. Возможно мегабуклет. Просто из-за размера. Но пусть будет книга.

Автор поставил себе задачу исследовать возможности C++17 (да, сегодня это уже немного outdated увлечение).

Делает он это с помощью задач с hackerrank. По своей сути они простые, но ведь любую задачу можно бесконечно усложнить, чем автор и занимается.

Фичи языка, которые рассматриваются в книге, покрывают (но не ограничиваются): итераторы, type traits, SFINAE, вычисления на компиляции, fold expressions, std::variant, std::any.

Понятно, что код в итоге смотрится ужасно. Вот, например, для Hello world:

template <typename I, typename O>
auto
hello_world(I first, I last, O out) {
    return std::copy(first, last, out);
}

int
main(int, char *[]) {
    auto hello = std::array{"Hello", "World!"};
    auto out = os_iterator<std::string>{std::cout, ", "};
    hello_world(hello.begin(), hello.end(), out);
    return 0;
}

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

Причём это самая простая задача. С самым сжатым кодом. Дальше начинается полный разнос с нечитаемыми решениями.

Но!

Книга может научить важным вещам, которые вам понадобятся при проектировании общих решений/алгоритмов. Подобные задачи всегда связаны с большим количеством крайних случаев и потенциальных ошибок. Автор хоть и не получает всегда идеальное решение (так как задача — поюзать как можно больше фичей), но причины тех или иных решений объясняет. Возможно, не все из них имеют отношение к реальным задачам. Но важно уловить паттерн и ход мысли.

Из минусов: с какого-то момента книга становится монотонной. Ну штош.

3 итератора из 7.

Спасибо Artyom Garkavy и niki4smirn.
Patreon, Boosty.

#list

0. [talk] "Just switch the compiler", they said. Arne Mertz.

Arne Mertz рассказывает, насколько на самом деле сложно переходить на другой компилятор. Проблемы примерно вида:
• не компилится
• тулчейн не работает
• библиотеки не поддерживаются
• рантайм ломается

С примерами разных проблем. Делится знанием, как пострадать от процесса минимально.

Вроде конечно понятно всё, но я как-то раньше не задумывался.

1. [quiz] John Regehr's Integers in C quiz.

И это только про С! Хех!

Не справился с двумя вопросами (на самом деле с тремя, но там не считается, вы поймёте). Расскажите про ваши успехи в комментариях!

2. [article] the hidden compile-time cost of C++26 reflection.

Vittorio Romeo рассказывает про [предварительные] замеры скорости компиляции разного кода с рефлексией. Статья называется как-то с намёком на то, что всё плохо, но вроде сам говорит, что не прям.

3. [article] Code is run more than read.

4. В одной из статей (которой делиться я не буду, так как у меня к ней много вопросов) я увидел вот такую фразу:

we needed a tool that fit our engineering culture

Я надеюсь, у вас тоже возникло ощущение беспросветного булшита.

Patreon, Boosty.

#cpp

Принёс доклады с C++ Russia 2025.

В хронологическом порядке.

0. LLVM MemProf и методы профилирования памяти.
Алексей Веселовский.

Крутой доклад про профилирование памяти. Что важно, осознаваемый на 1.5х без напряга, но при этом всё ещё сложноватый.

1. [Не]очевидные оптимизации и паттерны из userver. Антон Полухин.

Антон продолжал серию докладов про всякие приколюхи из userver.
Обычно (и в этот раз, и, я уверен, в в конференции этого года) это рассказ про несколько отдельных улучшений/фиксов/оптимизаций из userver. Глубоко в теорию в них не закапываемся. Скорее подразумевается наличие экспертизы.
Интересно как точка расширения сознания, чтобы потом пойти чего-то ещё поизучать.

На youtube есть смешной комментарий:
> ты ему слово, а он тебе трюки из userver

2. Как компиляторы на основе LLVM моделируют неопределенное поведение и извлекают из него пользу. Макс Казанцев.

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

3. Замеряем производительность для высоконагруженных проектов с Google Benchmark. Савва Лебедев.

Введение в gbench. Что важно, там и базовое что-то есть, и что-то, что может вам пригодиться, если вы вроде какие-то бенчмарки писали, но в перф глубоко не погружены. Для становления perf-person.

4. Уроки кодогенерации JSON Schema. Василий Куликов.

Вася — один из основных контрибьюторов userver.
Снаружи (вне Яндекса), в отличие от опенсорсной версии фреймворка, userver изначально имел кодген, который по OpenAPI спецификации позволял генерить готовый код для ручек, внутренних классов и работы с ними. Не нужно было раскладывать JSON в плюсовую структуру самому, например.

Вася рассказывал про новую кодогенерацию в фреймворке.

Я так понимаю, что в итоге именно она в опенсорсе и появилась.

5. Как мы работаем над производительностью мобильного приложения в 2ГИС. Дмитрий Ястребков.

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

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

6. Лицензии ПО: теория, которая спасает от финансовых катастроф. Ольга Кузмичева, Георгий Панюшкин.

Ребята рассказывали про то, что и заявлено в заголовке.

Я в теме нуб. Было интересно послушать про что-то важное для сферы в целом, но какое-то тёмное непонятное юридическое.

7. Ржавеющие плюсы: как внедрять современные проверки С++ в промышленных масштабах. Винсент Амбо.

Винсент рассказывал про харденинг и его внедрение в Яндексе.

Плюсы и безопасность это топики тяжёлые (если вместе обсуждать), так что всегда полезно ещё что-то сделать в этом месте.

8. Как заставить шаблоны компилироваться быстро и выглядеть опрятно. Павел Сухов.

Пашу вы должны уже знать.
Меня тоже (я рядом стоял).

Паша рассказывает про проблемы компиляции шаблонов, про перф этого всего дела, и про то, как выглядеть опрятно (это отдельный вопрос).

9. [не доклад, а болталка] Чему C++ может научиться? Антон Полухин. Павел Новиков.

Люблю послушать некоторую внутрянку комитета по стандартизации. Тут Антон как раз рассказал пару небольших историй. Зашло.
.

Я выступал на offline only активности с лайтнингом. Рассказывал про оптимизацию разработки. Это была вариация этого доклада с некоторым уходом в сторону плюсов.

#highload

Redis license stuff.

https://github.com/dasfex/articles/blob/trunk/redis_license_stuff.md

Спасибо Artyom Garkavy и niki4smirn.

Patreon, Boosty.

#common

Thoughts on finishing things.

Можно почитать на Patreon или github.

Как обычно, на том же Patreon или Boosty пост был доступен раньше.

Спасибо Artyom Garkavy и niki4smirn.

#common

Уже фактически начался сезон конференций. Как частый участник и иногда спикер, я (пусть и всего за пару лет) насмотрелся кеков. Потому напомню вам базовые правила.

Для участников:
• не пытайтесь посетить ВСЁ.
Досмóтрите дома в онлайне. Лучше пару докладов качественно, чем всё и быть пиявкой к концу дня.
А ещё почитайте абстракты докладов. Почему-то этого почти никогда не делают.
• вы идёте не только ради контента, но и нетворка.
Не тусуйтесь исключительно со своими коллегами. Познакомьтесь с вот этими тремя рандомными персонами. Опциально бахните с ними пива. Подойдите к тому самому крутому спикеру. Почти наверняка он(а) приятный человек.
Если стесняетесь, подумайте заранее, как в 3 предложения себя представить. Вы вообще-то тоже интересные!
• будьте уважительны к спикерам.
Человек уже вышел на сцену (а вы, почти наверняка, нет) и скорее всего испытывает некоторый объём волнения. Не надо на весь зал и под запись показывать, насколько вы умнее докладчика. Выскажите ему лично.
Я был на одном мероприятии на ≈200 человек, где дядька сказал докладчикам в микрофон что-то вроде "идите сначала доучитесь в школе, а потом приходите на конференции выступать".
Задайте вопрос, если он действительно есть.
Сделайте хорошее дополнение, чтобы поделиться знаниями.
• тайм-менеджмент тут тоже важен.
Подумайте заранее, когда и куда вы пойдёте. Соображать в короткий перерыв в толпе не очень эффективно.
Не забудьте взять воды.
• покайфуйте в конце концов.

Для спикеров (ну вдруг) (я не хочу рассказывать вам, как делать доклад, как-нибудь потом):
• будьте честными со слушателями.
Любое лукавство сразу видно. Несколько раз видел, когда докладчики отрицали использование разных источников, типа «сами придумали», а код символ в символ одинаковый.
Ради бога, не рассказывайте то, в чём не разбираетесь. Это тоже чувствуется на раз-два.
• принимайте фидбек.
Если вам кто-то говорит, что тут наверное такая ошибка, поблагодарите и разберитесь потом.
Если кто-то говорит, что слайды сложные, значит наверное так оно и есть.
• не будьте высокомерными.
Есть разные докладчики, которые за слово не по стандарту смерят вас пронзительным взглядом и скажут «тьфу» (особенно актуально для плюсового коммьюнити). Ваше присутствие на сцене не означает, что вы лучше других.
• в любом случае вы молодцы.
Выйти на толпу это крута.

#cpp

Поток (англ. flux)

https://github.com/dasfex/articles/blob/trunk/flux.md

Как обычно, на том же Patreon или Boosty пост был доступен раньше.

Спасибо Artyom Garkavy и niki4smirn.

#list

0. [talk] CTRACK: C++ Performance Tracking and Bottleneck Discovery. Grischa Hauser.

Автор рассказывает про новую тулу для измерения перфа ваших программ (догадались, как называется?).

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

1. [article] Email is crazy.

Такой поверхностный, слегка научпоповский пост про то, как устроены emails. С вайбом костыль на костыле.

2. [lightning talk] Catching Performance Issues at Compile Time. Keith Stockdale.

3. [lol] WTF-8 encoding are real.

4. [fact] В последнее время активно пользовался valgrind --tool=massif и надо было анализировать результаты.
Есть 2 рекомендуемых способа:
• утилита ms_print, которая печатает ваш massif.out файл в почти таком же формате. Это никак не помогает вам понять, где аллоцируете память.
• GUI massif-visualizer, которая запускается со скрипом, не кликается, не отзывается ни на что и ничего полезного не говорит.

Зато закинуть выхлоп в агента с доступом к анализируемому коду помогло неимоверно. Потыкал мне в конкретные места, которые кушают слишком много. Попредлагал фиксы.

Возможно часть тулинга нам больше не нужна.

Patreon или Boosty.

#common

Вылил текста про проблемы роста и полезность индивидуального плана развития.

https://github.com/dasfex/articles/blob/trunk/ipr.md

Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.