#cpp
ACCU on Sea 2026.
Помните, я в июне на конфе был? Пора отдавать долги.
Конфа проходила в Folkestone. Это город на юге UK. Прям у моря, так что название не врёт.
Раньше это было две отдельные конференции: ACCU conference (более общепрограммистская, пусть ACCU непосредственно с C и C++ и связано) и C++ On Sea. Мне несколько раз независимо сказали, что объединились они стратегически: сложно таскать участников дважды в год на похожие мероприятия, да ещё и денюжек у всех мало, так что от сотрудничества все только выиграют. Охотно верю.
Если в России подобные конфы часто делают проф организации, которые на этом деньги зарабатывают, то тут это скорее сборище энтузиастов. Надеюсь, они не работают в минус.
Сравнить с предыдущими конфами той же серии у меня конечно не получится. Но я могу сравнить с СНГшными альтернативами.
Во-первых, очень непривычно ездить на длинные конфы. Самая большая до этой у меня была на 2 дня. А тут все 4, и это я 2 дня воркшопов пропустил.
Во-вторых, очень непривычно ездить (на поезде), а не на самолёте летать. То есть уже кпд повыше (время в пути относительно времени на конференцию).
В-третьих, просто потому что это такая локация, вдали от Лондона (там дорого, причём и участникам, и организаторам), город отдаёт чуть больше Англией. Вот этой дефолтной обычной. У жил в гостинице старше моих дедов, с двумя кранами (для холодной и горячей воды) и под крышей. Вокруг всё такое деревянное. Короче даёт вайбом.
Морюшко рядом просто замечательное. За пару дней до конференции мы приезжали просто город посмотреть. Кроме огромного количества мошек у воды нареканий не было. Симатишно.
В силу того, что конференция так-то довольно большая и известная, было очень много известных чуваков. Вот лист рандомных имён, на которые удалось посмотреть вживую, с кем-то даже пообщаться: Andrei Alexandrescu (я пожал ему руку и хотел её больше никогда не мыть, но жена не разрешила), Jason Turner, Matt Godbolt, Walter E Brown, Klaus Iglberger, Nicolai M. Josuttis, Victor Ciura, Andreas Fertig, Sandor DARGO, Hana Dusíková, Timur Doumler, Arne Mertz и много других (коллег по компании не упоминаю). Они все настоящие, как и я настоящий. Очень необычно видеть людей вживую спустя 8 лет просмотров по телевизору.
Кормили дефолтно по-английски.
Стенды компаний вокруг были в основном трейдинги разного направления.
Вечерние активности были довольно интересными. Квиз особенно. Мы с коллегой вдвоём его начинали и для усиления привлекли группу из 5 случайных мужчин с пивом в руках. Победить нам это не помогло, но усилиться точно.
Walter E Brown в какой-то из вечеров устраивал Movie Night. Это он показывал на большом экране прикольные видосы с вайбом из ВК 2015. Визуализации сортировок. Как забавно хор имитирует звуки виндовс. Короче дедовские мемы.
Очень понравился формат лайтнингов.
Я несколько лет на C++ Russia с ними выступал и посмотрел на них тут. Отличия радикальные. На C++ Russia это сайдактивность где-то там в уголке, пока в главном зале большинство участников мощно пьют пиво и в конкурсах участвуют (по крайней мере в прошлые года, в этом я не посещал). На тебя приходит посмотреть человек 10-15, лайтнинги не blazingly fast (до 20 минут). Их мало.
На ACCU On Sea лайтнинги до 5 минут. Строго. Если превышаешь тайминги, у тебя отберут микрофон силой. Они идут час после докладов (то есть 12-14 лайтнингов успеваем) и они каждый день. Фактически за 3 вечера ты слушаешь ещё дополнительные ≈35 микродокладов на самые разные темы: рандомные плюсовые приколы, рекламы стартапов, астрономия, как клаву под себя собрать, про ос, какой-то чувак просто песню спел, даже не про C++. И это всё происходит в главном зале, куда фактически все приходят изначально, а значит у тебя есть большая аудитория. Гораздо более энергичный и заряженный формат. Рекомендую попробовать, друзья из джуг ру груп.
ACCU on Sea 2026.
Помните, я в июне на конфе был? Пора отдавать долги.
Конфа проходила в Folkestone. Это город на юге UK. Прям у моря, так что название не врёт.
Раньше это было две отдельные конференции: ACCU conference (более общепрограммистская, пусть ACCU непосредственно с C и C++ и связано) и C++ On Sea. Мне несколько раз независимо сказали, что объединились они стратегически: сложно таскать участников дважды в год на похожие мероприятия, да ещё и денюжек у всех мало, так что от сотрудничества все только выиграют. Охотно верю.
Если в России подобные конфы часто делают проф организации, которые на этом деньги зарабатывают, то тут это скорее сборище энтузиастов. Надеюсь, они не работают в минус.
Сравнить с предыдущими конфами той же серии у меня конечно не получится. Но я могу сравнить с СНГшными альтернативами.
Во-первых, очень непривычно ездить на длинные конфы. Самая большая до этой у меня была на 2 дня. А тут все 4, и это я 2 дня воркшопов пропустил.
Во-вторых, очень непривычно ездить (на поезде), а не на самолёте летать. То есть уже кпд повыше (время в пути относительно времени на конференцию).
В-третьих, просто потому что это такая локация, вдали от Лондона (там дорого, причём и участникам, и организаторам), город отдаёт чуть больше Англией. Вот этой дефолтной обычной. У жил в гостинице старше моих дедов, с двумя кранами (для холодной и горячей воды) и под крышей. Вокруг всё такое деревянное. Короче даёт вайбом.
Морюшко рядом просто замечательное. За пару дней до конференции мы приезжали просто город посмотреть. Кроме огромного количества мошек у воды нареканий не было. Симатишно.
В силу того, что конференция так-то довольно большая и известная, было очень много известных чуваков. Вот лист рандомных имён, на которые удалось посмотреть вживую, с кем-то даже пообщаться: Andrei Alexandrescu (я пожал ему руку и хотел её больше никогда не мыть, но жена не разрешила), Jason Turner, Matt Godbolt, Walter E Brown, Klaus Iglberger, Nicolai M. Josuttis, Victor Ciura, Andreas Fertig, Sandor DARGO, Hana Dusíková, Timur Doumler, Arne Mertz и много других (коллег по компании не упоминаю). Они все настоящие, как и я настоящий. Очень необычно видеть людей вживую спустя 8 лет просмотров по телевизору.
Кормили дефолтно по-английски.
Стенды компаний вокруг были в основном трейдинги разного направления.
Вечерние активности были довольно интересными. Квиз особенно. Мы с коллегой вдвоём его начинали и для усиления привлекли группу из 5 случайных мужчин с пивом в руках. Победить нам это не помогло, но усилиться точно.
Walter E Brown в какой-то из вечеров устраивал Movie Night. Это он показывал на большом экране прикольные видосы с вайбом из ВК 2015. Визуализации сортировок. Как забавно хор имитирует звуки виндовс. Короче дедовские мемы.
Очень понравился формат лайтнингов.
Я несколько лет на C++ Russia с ними выступал и посмотрел на них тут. Отличия радикальные. На C++ Russia это сайдактивность где-то там в уголке, пока в главном зале большинство участников мощно пьют пиво и в конкурсах участвуют (по крайней мере в прошлые года, в этом я не посещал). На тебя приходит посмотреть человек 10-15, лайтнинги не blazingly fast (до 20 минут). Их мало.
На ACCU On Sea лайтнинги до 5 минут. Строго. Если превышаешь тайминги, у тебя отберут микрофон силой. Они идут час после докладов (то есть 12-14 лайтнингов успеваем) и они каждый день. Фактически за 3 вечера ты слушаешь ещё дополнительные ≈35 микродокладов на самые разные темы: рандомные плюсовые приколы, рекламы стартапов, астрономия, как клаву под себя собрать, про ос, какой-то чувак просто песню спел, даже не про C++. И это всё происходит в главном зале, куда фактически все приходят изначально, а значит у тебя есть большая аудитория. Гораздо более энергичный и заряженный формат. Рекомендую попробовать, друзья из джуг ру груп.
👍20❤2🔥2
Про контент.
Я не буду разбирать и рекомендовать отдельные доклады. Это я сделаю когда досмотрю пару пропущенных, и их выложат в открытый доступ.
Наблюдения такие:
• было солидное количество докладов, которые уже рассказывали на других конференциях. Это стандартная практика, но она чувствуется гораздо сильнее в англоязычном пространстве, когда конференций и докладчиков в целом больше. Если сейчас в программу Meeting C++ 2026 заглянуть, там вы тоже солидное кол-во повторов найдёте.
• очень много говорят про фичи последних стандартов. Рефлексия. Контракты. Это логично, ведь всем хочется знать, как там фичи покруче использовать, но я в последнее время перестал пытаться ухватывать каждую новую функцию. Стараюсь смещать фокус в более фундаментальные вещи.
• безопасность и Rust. Ну вот популярные насущные топики. Что с них взять.
Было ощущение, что не всегда доклады в сетке расставлены равномерно. Где-то в большом зале мало людей, а в другом поменьше не протолкнуться. В последний день в один слот стояли Jason Turner, Matt Godbolt и Timur Doumler. Жоска!
Мне очень понравилось.
Несколько фотографий с конфы и из города в целом.
На фото номер 3 коллега из Bloomberg: Женя Селиверстов. У него блог есть: omniverse.ru
Последняя — с прогулки в соседнем Hythe, где мы случайно встретили огромного пса Scooby. Наш 6-килограммовый зверь был готов наброситься, но он не знает, как это не любить кого-то, так что обошлось.
Я не буду разбирать и рекомендовать отдельные доклады. Это я сделаю когда досмотрю пару пропущенных, и их выложат в открытый доступ.
Наблюдения такие:
• было солидное количество докладов, которые уже рассказывали на других конференциях. Это стандартная практика, но она чувствуется гораздо сильнее в англоязычном пространстве, когда конференций и докладчиков в целом больше. Если сейчас в программу Meeting C++ 2026 заглянуть, там вы тоже солидное кол-во повторов найдёте.
• очень много говорят про фичи последних стандартов. Рефлексия. Контракты. Это логично, ведь всем хочется знать, как там фичи покруче использовать, но я в последнее время перестал пытаться ухватывать каждую новую функцию. Стараюсь смещать фокус в более фундаментальные вещи.
• безопасность и Rust. Ну вот популярные насущные топики. Что с них взять.
Было ощущение, что не всегда доклады в сетке расставлены равномерно. Где-то в большом зале мало людей, а в другом поменьше не протолкнуться. В последний день в один слот стояли Jason Turner, Matt Godbolt и Timur Doumler. Жоска!
Мне очень понравилось.
Несколько фотографий с конфы и из города в целом.
На фото номер 3 коллега из Bloomberg: Женя Селиверстов. У него блог есть: omniverse.ru
Последняя — с прогулки в соседнем Hythe, где мы случайно встретили огромного пса Scooby. Наш 6-килограммовый зверь был готов наброситься, но он не знает, как это не любить кого-то, так что обошлось.
👍13🔥5❤3
#list
0. [talk] Achieving Peak Performance for Matrix Multiplication in C++. Aliaksei Sala.
Алексей рассказывает про постепенное улучшение умножения матриц, начиная от базового подхода и двигаясь через улучшение работы с кешами, simd, префетчингом и всякими другими финтифлюшками.
1. [article] How Google Measures and Manages Tech Debt.
Хорошая системная статья про то, как в Google пытаются мерять и бороться с техдолгом как явлением. Вряд ли вы найдёте радикальные откровения, но системность подхода на уровне.
2. [article, download pdf] Microservices Anti-Patterns: A Taxonomy.
Статья написана поверх опроса специалистов на тему антипаттернов при использовании микросервисов. Я — святая простота — некоторым типичным проблемам удивился, так как даже подумать не мог, что где-то считают это нормальным. Например, «local logging», который подразумевает хранение логов в рамках контейнера одного сервиса. То есть нельзя сразу везде искать. Жесть как так жить вообще можно...
Хотя с другими я не прям согласен как с проблемами. Имхо можно спокойно и без API-gateway пожить. И shared libraries вообще-то отличное решение, если адекватно ими пользоваться.
В статье рассматриваются не только технические проблемы, но и организационные. Вроде «быть жадными на микросервисы» (== делать новый на любой чих). Или не менять структуру компании в соответствии с новрй технической организацией.
Не предлагаю прочитать всё внимательно. Скорее пробежаться глазами по табличкам с описанием отдельных проблем в середине.
3. [article] Build better software to build software better.
Чуваки из Slack рассказывали, как переделывали build-пайплайн.
Кроме очевидных поинтов мне очень понравилась мысль (нигде явным образом не сформулированная), что иногда использование тулинга требует подготовки и переделки системы под инструмент.
И может это даже окупится.
4. [article] p99 0 ms* autocomplete for 240 million domain names.
0. [talk] Achieving Peak Performance for Matrix Multiplication in C++. Aliaksei Sala.
Алексей рассказывает про постепенное улучшение умножения матриц, начиная от базового подхода и двигаясь через улучшение работы с кешами, simd, префетчингом и всякими другими финтифлюшками.
1. [article] How Google Measures and Manages Tech Debt.
Хорошая системная статья про то, как в Google пытаются мерять и бороться с техдолгом как явлением. Вряд ли вы найдёте радикальные откровения, но системность подхода на уровне.
2. [article, download pdf] Microservices Anti-Patterns: A Taxonomy.
Статья написана поверх опроса специалистов на тему антипаттернов при использовании микросервисов. Я — святая простота — некоторым типичным проблемам удивился, так как даже подумать не мог, что где-то считают это нормальным. Например, «local logging», который подразумевает хранение логов в рамках контейнера одного сервиса. То есть нельзя сразу везде искать. Жесть как так жить вообще можно...
Хотя с другими я не прям согласен как с проблемами. Имхо можно спокойно и без API-gateway пожить. И shared libraries вообще-то отличное решение, если адекватно ими пользоваться.
В статье рассматриваются не только технические проблемы, но и организационные. Вроде «быть жадными на микросервисы» (== делать новый на любой чих). Или не менять структуру компании в соответствии с новрй технической организацией.
Не предлагаю прочитать всё внимательно. Скорее пробежаться глазами по табличкам с описанием отдельных проблем в середине.
3. [article] Build better software to build software better.
Чуваки из Slack рассказывали, как переделывали build-пайплайн.
Кроме очевидных поинтов мне очень понравилась мысль (нигде явным образом не сформулированная), что иногда использование тулинга требует подготовки и переделки системы под инструмент.
И может это даже окупится.
4. [article] p99 0 ms* autocomplete for 240 million domain names.
👍4❤1
#common
Мы часто делаем системы, которые обладают какими-то ограничениями. Ограничения наш хлеб: если бы надо было сделать универсальную систему для любой, абсолютно любой задачи, её бы скорее всего не стали финансировать даже на этапе идеи. Масштаб изначально не объять.
Например, сервис доставки продуктов, в котором я провёл 4 года, обладает (по крайней мере раньше) некоторыми интересными свойствами.
Во-первых, это жутко операционный бизнес.
У вас есть склады, а значит нужно находить существующие помещения нужного размера и подписывать аренду с владельцами. Вам нужны поставщики. Для оптимизации некоторых процессов вообще можно захотеть построить завод, чтобы товары самому производить (и растить маржу). Некоторые фичи нельзя сделать в одного, потому что нужно не только код написать, но и научить кладовщиков в десятках городов (и странах) делать вещи иначе. Горячая еда и кофе не могут быть горячими постоянно. Их нужно греть/готовить, а значит соблюдать санитарные нормы, и вообще найти физическое место для оборудования.
Но это же и делает задачи особенными. Идея, которая мне очень понравилась, но заглохла на этапе поисков ресурса, — поставить на каждый склад принтер, заинтегрироваться с сервисом AI-генерации картинок и печатать каждому пользователю открытку с его заказом. Как же фаново звучит.
Операционка — ограничение, которое всегда было и постоянно нужно учитывать.
Но это не то, про что я хочу рассказать. Ещё есть во-вторых: сервис не имел user generated content (UGC). Хотя он предоставлял какой-то контент (товары посмотреть). Всё, что вы видели в приложении, полностью создаётся или внимательно валидируется сотрудниками. В какой-нибудь социальной сети, живущей на UGC, в любой момент кто угодно может запостить абсолютно что угодно. А вот в сервисе доставки нет.
Почему это хорошо?
Я не говорю, что это хорошо. Я говорю, что это существующее ограничение, которое имеет свои плюсы.
Например, вы можете доверять данным. Это значит, что задач
• модерации
• антиспама
• соблюдения копирайта
просто не существует.
Вам не нужно удалять содержимое за мгновение, потому что юзер мог написать что-то не то и яростно кликает на кнопку Delete. За сутки отрастёт и ладно (преувеличиваю конечно, но суть ясна). А это даёт возможность обкладываться кешами по самое не хочу.
Другое преимущество: объём данных не растёт так непредсказуемо.
Никакой пользователь на загрузит гигабайт фоток за полдня. Не придёт злостный робот-спамер с вредными комментариями (придут другие, но про это когда-нибудь потом).
Вам буквально проще заниматься capacity planning.
Более того, скорее всего данные в целом меняются не очень часто -> вы получаете систему вида «few writes, many reads». Значит возможно данным не нужно появляться мгновенно (что тоже не всегда правда, но мы теоретизируем) и можно обрабатывать их более сложными и долгими способами. Можно в конце концов взять 1000 самых популярных поисковых запросов (если у вас поиск есть) и посчитать самые релевантные ответы на них. Раз в сутки пересчитывать одной большой долгой кронкой.
У вас вероятно нет горячих и холодных данных (ну может с какого-то момента есть, но до этого вам нужно ещё дожить, когда в системе с UGC всё может произойти завтра).
Я не говорю, что все отпавшие задачи выше — фигня какая-то. Нет. Они очень интересны. Но у вас трейдофы смещаются в сторону и позволяют оптимизироваться под вещи, которые не могут быть возможны в UGC системах. Всё вокруг вы можете оптимизировать под чтение, а не запись.
Иногда от UGC можно умело избавляться -> не добавлять сложные последствия. Например, не показывать отзывы юзеров на товары, а показывать AI-суммаризацию (CEO вам ещё спасибо скажет: AI добавили, нифига себе модные).
Короче ваши решения могут быть более долговечными и производительными, если вы поймёте специфику вашего продукта и его ограничения.
Попробуйте потратить время на этой неделе, чтобы глубже ощутить подобные ограничения в вашем проекте.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
От мегапатрона Artyom Garkavy вам:
Мы часто делаем системы, которые обладают какими-то ограничениями. Ограничения наш хлеб: если бы надо было сделать универсальную систему для любой, абсолютно любой задачи, её бы скорее всего не стали финансировать даже на этапе идеи. Масштаб изначально не объять.
Например, сервис доставки продуктов, в котором я провёл 4 года, обладает (по крайней мере раньше) некоторыми интересными свойствами.
Во-первых, это жутко операционный бизнес.
У вас есть склады, а значит нужно находить существующие помещения нужного размера и подписывать аренду с владельцами. Вам нужны поставщики. Для оптимизации некоторых процессов вообще можно захотеть построить завод, чтобы товары самому производить (и растить маржу). Некоторые фичи нельзя сделать в одного, потому что нужно не только код написать, но и научить кладовщиков в десятках городов (и странах) делать вещи иначе. Горячая еда и кофе не могут быть горячими постоянно. Их нужно греть/готовить, а значит соблюдать санитарные нормы, и вообще найти физическое место для оборудования.
Но это же и делает задачи особенными. Идея, которая мне очень понравилась, но заглохла на этапе поисков ресурса, — поставить на каждый склад принтер, заинтегрироваться с сервисом AI-генерации картинок и печатать каждому пользователю открытку с его заказом. Как же фаново звучит.
Операционка — ограничение, которое всегда было и постоянно нужно учитывать.
Но это не то, про что я хочу рассказать. Ещё есть во-вторых: сервис не имел user generated content (UGC). Хотя он предоставлял какой-то контент (товары посмотреть). Всё, что вы видели в приложении, полностью создаётся или внимательно валидируется сотрудниками. В какой-нибудь социальной сети, живущей на UGC, в любой момент кто угодно может запостить абсолютно что угодно. А вот в сервисе доставки нет.
Почему это хорошо?
Я не говорю, что это хорошо. Я говорю, что это существующее ограничение, которое имеет свои плюсы.
Например, вы можете доверять данным. Это значит, что задач
• модерации
• антиспама
• соблюдения копирайта
просто не существует.
Вам не нужно удалять содержимое за мгновение, потому что юзер мог написать что-то не то и яростно кликает на кнопку Delete. За сутки отрастёт и ладно (преувеличиваю конечно, но суть ясна). А это даёт возможность обкладываться кешами по самое не хочу.
Другое преимущество: объём данных не растёт так непредсказуемо.
Никакой пользователь на загрузит гигабайт фоток за полдня. Не придёт злостный робот-спамер с вредными комментариями (придут другие, но про это когда-нибудь потом).
Вам буквально проще заниматься capacity planning.
Более того, скорее всего данные в целом меняются не очень часто -> вы получаете систему вида «few writes, many reads». Значит возможно данным не нужно появляться мгновенно (что тоже не всегда правда, но мы теоретизируем) и можно обрабатывать их более сложными и долгими способами. Можно в конце концов взять 1000 самых популярных поисковых запросов (если у вас поиск есть) и посчитать самые релевантные ответы на них. Раз в сутки пересчитывать одной большой долгой кронкой.
У вас вероятно нет горячих и холодных данных (ну может с какого-то момента есть, но до этого вам нужно ещё дожить, когда в системе с UGC всё может произойти завтра).
Я не говорю, что все отпавшие задачи выше — фигня какая-то. Нет. Они очень интересны. Но у вас трейдофы смещаются в сторону и позволяют оптимизироваться под вещи, которые не могут быть возможны в UGC системах. Всё вокруг вы можете оптимизировать под чтение, а не запись.
Иногда от UGC можно умело избавляться -> не добавлять сложные последствия. Например, не показывать отзывы юзеров на товары, а показывать AI-суммаризацию (CEO вам ещё спасибо скажет: AI добавили, нифига себе модные).
Короче ваши решения могут быть более долговечными и производительными, если вы поймёте специфику вашего продукта и его ограничения.
Попробуйте потратить время на этой неделе, чтобы глубже ощутить подобные ограничения в вашем проекте.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
От мегапатрона Artyom Garkavy вам:
Try it today: google.com.
👍15❤6
Давайте новый тег заведём: #perf
Во-первых, надо понять, что я вообще понимаю под перфом, ведь понятие очень широкое. Так как мои интересы лежат в районе эффективности распределённых систем, то перф для меня — всё, что позволяет делать эти распределённые системы быстрыми. В зависимости от системы вам может понадобиться решать проблемы разного характера. Где-то это про сделать ручку для обработки данных батчами, чтобы по сети поменьше ходить. Где-то научиться нормально пользоваться БДшкой. Где-то надо почаще попадать в L1 кеш и префетчить данные. А где-то вообще выбросить всё что есть и сделать заново в другой парадигме. Вся широта проблем меня занимает. В разной мере в разное время.
На самом деле я бы расширил понятие перфа до слова эффективность. И разговаривал бы ещё про то, что такое эффективность команды или всех разработчиков на стеке Х. Что такое developer experience. Почему унификация помогает средне-большой компании экономить деньги и вот это всё. Тут конечно надо быть осторожным и не уйти в степь вида «дайте-ка я ещё померяю, кто у меня в команде больше коммитов делает и буду им оценочку на ревью повыше ставить». Я за здравое понимание «эффективности разработки», а не за вот это корпоративное обмазаться метриками и всем в нос им потом тыкать.
Но такие вещи я постараюсь в тег не заносить, чтобы не обманывать хардкорных си плюс плюс подписчиков.
Во-вторых, начать тег я хочу с концепции. Концепция хорошо показана в докладе с CppCon 2014: Data-Oriented Design and C++ от Mike Acton. Это даже тот самый классический доклад, который всем показывают по теме.
Я его смотрел когда-то пару лет назад. Смотрел не очень осознанно. А сейчас как-то естественным образом пришёл к понимаю подобного направления и случайно ещё наткнулся на доклад, который вроде про то самое.
Суть хорошо показана в первой части (где-то первые 30 минут, дальше начинаются примеры кода). Кратко её сформулировать можно так: данные это всё. Основная проблема: при решении задач мы часто оперируем ментальными моделями, которые хорошо выглядят с точки зрения нашего человеческого понимания объектов, трансформаций данных и решения проблемы «переложить объект слева направо». Но так как компуктеры работают не так, как мы думаем, необходимо взять себя в руки и подумать про то, как данные должны трансформироваться (фактически единственно важный вопрос при проектировании). И из этого ответа у вас вытекают все возможности решений.
Фактически весь перф это про data oriented design. Ведь вам не нужно ускорять то, что согласно данным не нужно ускорять. И нужно то, что нужно. Вам нужно знать, как ваши данные выглядят, какие там взаимосвязи. Как они используются. Желательно знать как можно больше. Вы хотите решать задачу для наиболее common случая, потому что это статистически принесёт больше пользы.
Короче знайте свои данные.
Есть ещё доклад Vittorio Romeo «More Speed & Simplicity: Practical Data-Oriented Design in C++». Несмотря на какой-то околоискуственный пример, тут неплохо показана попытка сдвига мышления от привычной OOP парадигмы в сторону DOD.
Особенно, пусть это и не относится особенно к делу, красиво задвинул в конце про адекватный интерфейс для SoA.
У меня вот прям после некоторого количества информации по этой теме какой-то сдвиг в голове случился, и некоторые вещи обрели новый, более устойчивый смысл, а некоторые его радикально потеряли. Будем наблюдать, какие плоды это в итоге принесёт.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
На правах мегапатрона послание подписчикам от Artyom Garkavy:
Во-первых, надо понять, что я вообще понимаю под перфом, ведь понятие очень широкое. Так как мои интересы лежат в районе эффективности распределённых систем, то перф для меня — всё, что позволяет делать эти распределённые системы быстрыми. В зависимости от системы вам может понадобиться решать проблемы разного характера. Где-то это про сделать ручку для обработки данных батчами, чтобы по сети поменьше ходить. Где-то научиться нормально пользоваться БДшкой. Где-то надо почаще попадать в L1 кеш и префетчить данные. А где-то вообще выбросить всё что есть и сделать заново в другой парадигме. Вся широта проблем меня занимает. В разной мере в разное время.
На самом деле я бы расширил понятие перфа до слова эффективность. И разговаривал бы ещё про то, что такое эффективность команды или всех разработчиков на стеке Х. Что такое developer experience. Почему унификация помогает средне-большой компании экономить деньги и вот это всё. Тут конечно надо быть осторожным и не уйти в степь вида «дайте-ка я ещё померяю, кто у меня в команде больше коммитов делает и буду им оценочку на ревью повыше ставить». Я за здравое понимание «эффективности разработки», а не за вот это корпоративное обмазаться метриками и всем в нос им потом тыкать.
Но такие вещи я постараюсь в тег не заносить, чтобы не обманывать хардкорных си плюс плюс подписчиков.
Во-вторых, начать тег я хочу с концепции. Концепция хорошо показана в докладе с CppCon 2014: Data-Oriented Design and C++ от Mike Acton. Это даже тот самый классический доклад, который всем показывают по теме.
Я его смотрел когда-то пару лет назад. Смотрел не очень осознанно. А сейчас как-то естественным образом пришёл к понимаю подобного направления и случайно ещё наткнулся на доклад, который вроде про то самое.
Суть хорошо показана в первой части (где-то первые 30 минут, дальше начинаются примеры кода). Кратко её сформулировать можно так: данные это всё. Основная проблема: при решении задач мы часто оперируем ментальными моделями, которые хорошо выглядят с точки зрения нашего человеческого понимания объектов, трансформаций данных и решения проблемы «переложить объект слева направо». Но так как компуктеры работают не так, как мы думаем, необходимо взять себя в руки и подумать про то, как данные должны трансформироваться (фактически единственно важный вопрос при проектировании). И из этого ответа у вас вытекают все возможности решений.
Фактически весь перф это про data oriented design. Ведь вам не нужно ускорять то, что согласно данным не нужно ускорять. И нужно то, что нужно. Вам нужно знать, как ваши данные выглядят, какие там взаимосвязи. Как они используются. Желательно знать как можно больше. Вы хотите решать задачу для наиболее common случая, потому что это статистически принесёт больше пользы.
Короче знайте свои данные.
Есть ещё доклад Vittorio Romeo «More Speed & Simplicity: Practical Data-Oriented Design in C++». Несмотря на какой-то околоискуственный пример, тут неплохо показана попытка сдвига мышления от привычной OOP парадигмы в сторону DOD.
Особенно, пусть это и не относится особенно к делу, красиво задвинул в конце про адекватный интерфейс для SoA.
У меня вот прям после некоторого количества информации по этой теме какой-то сдвиг в голове случился, и некоторые вещи обрели новый, более устойчивый смысл, а некоторые его радикально потеряли. Будем наблюдать, какие плоды это в итоге принесёт.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
На правах мегапатрона послание подписчикам от Artyom Garkavy:
Try it today: google.com.
👍16❤1
#perf
Попробовал собрать в кучку (кажется, немного сумбурно всё же) мысли по двум моментам:
• что искать в данных и как их собирать, чтобы на них можно было быть oriented
• чуть более разнообразные, чем обычно, примеры применения DOD.
https://thisnotes.dev/blog/dod_examples/
Да, на инглише, теперь иногда будет так.
Ещё можете подписаться на newsletter: https://thisnotes.substack.com/subscribe
Может вам на почту удобнее получать.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
Попробовал собрать в кучку (кажется, немного сумбурно всё же) мысли по двум моментам:
• что искать в данных и как их собирать, чтобы на них можно было быть oriented
• чуть более разнообразные, чем обычно, примеры применения DOD.
https://thisnotes.dev/blog/dod_examples/
Да, на инглише, теперь иногда будет так.
Ещё можете подписаться на newsletter: https://thisnotes.substack.com/subscribe
Может вам на почту удобнее получать.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
thisnotes.dev
Data-Oriented Design in practice
Examples of how we could use data oriented design in real life.
🔥7❤2👍2
#cpp #books
Да, книга 2001ого года. Мы ровесники.
И да, в ней в основном обсуждаются какие-то решения, которые сегодня уже всем знакомы и лежат в стандартной библиотеке сто лет. Но есть но...
Содержание:
1. Policy-Based Class Design.
Глава рассказывает про сложности создания качественного кастомизируемого дизайна общих классов и почему множественное наследование не помогает в решении проблемы экспоненциального роста потенциальных версий ваших компонент. Есть примеры использования различных policy.
В конце обсуждается, как декомпозировать ваш класс на policy. Есть такой совет: «Anything that can be done in more than one way should be identified and migrated from the class to a policy». Важно помнить, что книга для пишущих общего вида библиотеки. Скорее всего для общего решения в продуктовом коде правильнее будет сказать: «Выносите то, что прямо сейчас нужно вынести». Не наперёд, а в моменте.
2. Techniques.
Вторая глава рассказывает про набор отдельных утилиток и возможностей языка, которые могут применяться в более общих решениях. Некоторые из них:
- compile-time assertions (до
- partial template specialization
- integral constant to type (дед
- type-to-type mapping
- type selection (
- TypeTraits (правда тут это класс с константами, а не как у нас «вчера» шаблонные структуры)
3. Typelists.
Typelists конечно не поддерживают произвольное количество аргументов (потому что шаблоны не умели). Выглядят они так:
Дальше реализовываются разные операции и рассказывается про применение класса.
4. Рассказывает про проблемы стандартного аллокатора и после введения локальных понятий поясняет реализацию small-object аллокатора.
5. Про паттерн Command и generalized functor для его реализации. Фактически
6. Рассказывает про реализацию Singleton.
Причём довольно подробно описывая проблемы разных подходов. В итоге приходим к Meyers singleton. После небольшого chatgpt-like фактчека оказалось, что именно в этой книге Andrei Alexandrescu подарил миру это название.
Далее он рассматривает самоназванную KDL problem (которая легко может возникнуть на практике) и изобретает Phoenix singleton для её решения.
К концу главы обсуждается реализация singletone для многопоточного случая и общая policy-based реализация.
7. Про умные указатели.
Кто такие, как пользоваться и как должны быть реализованы с точки зрения различных случаев на практике.
8 и 9. Про фабрики и абстрактные фабрики.
10. Посвящена паттерну visitor.
11. Реализации мультиметодов.
Это как бы перегрузка функций, которая знает чуть больше, чем положена. Кратко можно пояснить так:
И вот обычно вы бы вызвали
Каждая глава проходит путь от каких-то простых реализаций до более продвинутых через рассмотрение ошибок и проблем, которые возникают при неаккуратном дизайне.
Сегодня конечно книга выглядит уже скорее как исторический артефакт. Но!
• первая глава про policy-based design всё ещё актуально, потому что говорит концептуальные вещи. Мне она сильно запомнилась и помогла на некоторые концепции иначе смотреть.
• большинство других глав полезны с точки зрения понимания, как стоит смотреть на проектирование общих решений.
То есть если не воспринимать книгу как справочник по C++, а попытаться увидеть в ней мануал по проектированию на примере конкретных задач, получится очень даже полезно.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
Да, книга 2001ого года. Мы ровесники.
И да, в ней в основном обсуждаются какие-то решения, которые сегодня уже всем знакомы и лежат в стандартной библиотеке сто лет. Но есть но...
Содержание:
1. Policy-Based Class Design.
Глава рассказывает про сложности создания качественного кастомизируемого дизайна общих классов и почему множественное наследование не помогает в решении проблемы экспоненциального роста потенциальных версий ваших компонент. Есть примеры использования различных policy.
В конце обсуждается, как декомпозировать ваш класс на policy. Есть такой совет: «Anything that can be done in more than one way should be identified and migrated from the class to a policy». Важно помнить, что книга для пишущих общего вида библиотеки. Скорее всего для общего решения в продуктовом коде правильнее будет сказать: «Выносите то, что прямо сейчас нужно вынести». Не наперёд, а в моменте.
2. Techniques.
Вторая глава рассказывает про набор отдельных утилиток и возможностей языка, которые могут применяться в более общих решениях. Некоторые из них:
- compile-time assertions (до
static_assert)- partial template specialization
- integral constant to type (дед
std::integer_constant)- type-to-type mapping
- type selection (
std::conditional)- TypeTraits (правда тут это класс с константами, а не как у нас «вчера» шаблонные структуры)
3. Typelists.
Typelists конечно не поддерживают произвольное количество аргументов (потому что шаблоны не умели). Выглядят они так:
typelist<type1, typelist<type2, type3>>
Дальше реализовываются разные операции и рассказывается про применение класса.
4. Рассказывает про проблемы стандартного аллокатора и после введения локальных понятий поясняет реализацию small-object аллокатора.
5. Про паттерн Command и generalized functor для его реализации. Фактически
std::function. 6. Рассказывает про реализацию Singleton.
Причём довольно подробно описывая проблемы разных подходов. В итоге приходим к Meyers singleton. После небольшого chatgpt-like фактчека оказалось, что именно в этой книге Andrei Alexandrescu подарил миру это название.
Далее он рассматривает самоназванную KDL problem (которая легко может возникнуть на практике) и изобретает Phoenix singleton для её решения.
К концу главы обсуждается реализация singletone для многопоточного случая и общая policy-based реализация.
7. Про умные указатели.
Кто такие, как пользоваться и как должны быть реализованы с точки зрения различных случаев на практике.
8 и 9. Про фабрики и абстрактные фабрики.
10. Посвящена паттерну visitor.
11. Реализации мультиметодов.
Это как бы перегрузка функций, которая знает чуть больше, чем положена. Кратко можно пояснить так:
class Shape {};
class Asteroid : public Shape {};
class Spaceship : public Shape {};
void Collide(Asteroid& a, Spaceship& s) { /* Logic 1 */ }
void Collide(Shape& s1, Shape& s2) { /* Logic 2 */ }
И вот обычно вы бы вызвали
Collide на основании того, какая ссылка была передана. Если Asteroid был передан как Shape, то вызовется общая функция для Shape. Вот мультиметоды позволяют понять, какой объект на самом деле лежит в памяти и вызвать для него соответствующую перегрузку. Каждая глава проходит путь от каких-то простых реализаций до более продвинутых через рассмотрение ошибок и проблем, которые возникают при неаккуратном дизайне.
Сегодня конечно книга выглядит уже скорее как исторический артефакт. Но!
• первая глава про policy-based design всё ещё актуально, потому что говорит концептуальные вещи. Мне она сильно запомнилась и помогла на некоторые концепции иначе смотреть.
• большинство других глав полезны с точки зрения понимания, как стоит смотреть на проектирование общих решений.
То есть если не воспринимать книгу как справочник по C++, а попытаться увидеть в ней мануал по проектированию на примере конкретных задач, получится очень даже полезно.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
👍12❤4🔥1