Back to Back

Обсудим главные новости со встречи Международного комитета по стандартизации C++, а также самые интересные возможности C++26. Руководитель РГ21 C++ Антон Полухин расскажет, что ждёт язык в ближайшие годы, и ответит на вопросы о развитии C++26 и планах на C++29.

В докладе — о том, как команда добавляет поддержку языка программирования LuaJIT в eBPF-профилировщик Perforator — open-source-проект Яндекса.

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

Рассмотрим некоторые нововведения C++26 полезные для генерации элементов программ. Пройдем путь от примитивов std::meta и основных приемов при работе с рефлексией, до генерации произвольных интерфейсов без макросов, кодогенерации и Undefined Behavior.

На примере экспериментальной библиотеки покажу новые возможности для реализации существующих подходов к runtime-полиморфизму.

Антон расскажет, как мы считаем range-предикаты с помощью битовых масок и как комбинировать их между колонками.

В C++20 появились корутины, но стандартная библиотека почти не даёт готовых примитивов для работы с ними. Один из таких недостающих механизмов — отмена ожидающих операций в асинхронных библиотеках.

Раед разберёт, почему в многопоточной асинхронной системе отмена оказывается нетривиальной задачей: от синхронизации с фреймом корутины до рисков use-after-free и дедлоков. На примере библиотеки YaIO, которая используется в Яндексе для асинхронного IO, он покажет, как шаг за шагом разработать безопасный механизм отмены для C++ корутин.

Разберём основные этапы масштабирования рантайма, баз и Temporal-кластера для фоновых процессов. Поговорим о том, какие ресурсы становились критичными по мере роста нагрузки и как менялась архитектура.

Рассмотрим масштабирование postgres-кластеров до первой тысячи магазинов, роутинга — после тысячи доменов, и Temporal-пайплайна — на первых 5 тысячах кабинетов.

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

Одновременное исполнение давно с нами — от инструкций процессора до распределённых систем. Но базу про concurrency, parallelism и многопоточность знают, как говорится, не только лишь все.

В докладе Андрей Аксёнов пройдётся по разным уровням «одновременности» — от micro-ops до MapReduce — и разберёт, что за ними стоит на практике. Без попытки уместить курс лекций в 30 минут: только ключевые прикладные выводы о том, как всё это влияет на код, архитектуру и инженерные решения.

Обеспечение надежного сохранения данных и их восстановления после сбоев — ключевая задача систем обработки данных. Любая ошибка записи может привести к потере транзакций или повреждению данных, а масштабные системы требуют при этом высокой производительности и быстрой доступности после сбоя. Мы в OtterBrix тоже столкнулись с задачей проектирования собственного WAL, и довольно быстро выяснили, что универсального рецепта здесь не существует.

Проектирование WAL — это поиск инженерного компромисса между скоростью записи, временем фиксации транзакций, временем восстановления после сбоя и надёжностью системы хранения. В зависимости от требований, для каждой отдельной СУБД этот компромисс будет решатся по-разному.

В докладе я покажу модель принятия решений при проектировании WAL на примере PostgreSQL, SQLite и DuckDB, а также расскажу, как в OtterBrix мы построили собственный WAL.

Что сегодня нужно, чтобы C+±модули действительно заработали «из пакета»? Разберём последние изменения в MSVC, Clang, GCC, CMake, Conan и vcpkg, сравним подходы разных инструментов и обсудим, почему интеграция всё ещё остаётся хрупкой.

Поговорим о текущих ограничениях и о том, что должно измениться в экосистеме C++, чтобы модули стали по-настоящему переносимыми. В том числе — о работе Tooling SG (SG15) и EcoStd.

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

Покажем, как мы перевели сервис на мультитенантные кластеры, сохранив изоляцию данных, возможность выделять отдельные кластеры крупным клиентам и горизонтально масштабировать систему. Разберем устройство нового слоя хранения, подход к шардированию, а также процесс безопасной миграции организаций между кластерами с минимальным простоем с использованием Yandex Data Transfer. Доклад будет полезен инженерам, которые проектируют высоконагруженные распределенные системы и сталкиваются с проблемами масштабирования и эволюции архитектуры.

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

В мире HFT эту задачу решили давно: там цена ошибки слишком высока, чтобы мириться с накладными расходами на наблюдаемость. Разберём, как эти же подходы можно применять в обычных продуктовых проектах. Пройдём путь от std::cout до shared memory и rdtsc, разберёмся, как минимизировать обмен кэш-линиями между ядрами, и обсудим различия между Intel со strong memory model и ARM со weak memory model. Отдельно рассмотрим инвалидацию кэшей и то, как организовать эффективную работу не только с одним потоком-логгером, но и с несколькими читателями.

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

Обычно пользователи веб-мира и секьюр-шелл-мира строго разделены. Для веб-мира имена, пароли и JWT-токены, для SSH-мира ключи, ну и иногда тоже имена и пароли.

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

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