Грокаем C++

〰️ Как оживить сигнал в микроконтроллере? В цифровом мире всё крутится вокруг нулей и единиц. Но когда нужно управлять мотором, формировать звук или регулировать яркость света, без цифро-аналогового преобразователя (ЦАП) не обойтись. 📆 9 октября в 20:00 МСК приглашаем на открытый урок, где мы: – разберём разные методы реализации ЦАП (PWM+RC, R2R, внешняя микросхема, цифровой потенциометр); – сравним их по частоте, разрядности, ресурсоёмкости и стоимости; – обсудим реальные примеры применения в embedded-проектах. ❗️Этот вебинар будет полезен инженерам-электронщикам, embedded-разработчикам и программистам микроконтроллеров. 👉 Открытый урок проходит в преддверие старта курса «Электроника и электротехника». Регистрация открыта: https://otus.pw/jGHwv/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

​​shared libraries #опытным И еще один способ уменьшить время сборки проекта. А точнее линковки. Идея такая: вы разбиваете свой проект на отдельные, независимые модули и компилируете их как разделяемые библиотеки. Дальше динамически линкуете эти библиотеки к своему исполняемому файлу. Почему в этом случае линковка быстрее? Для того, чтобы это понять, нужно знать, что происходит при статической линковке. На вход принимаются много объектных файлов и статических библиотек и компановщик выполняет примерно следующий набор действий: 1️⃣ Разрешение символов - для каждого неопределенного символа ищется определение. 2️⃣ Создание единого адресного пространства - линковщик определяет окончательные адреса для всех сегментов кода и данных и объединяет однотипные секции из разных объектных файлов. 3️⃣ Применение релокаций - в объектных файлах и статических либах адреса указаны относительно и линковщик пересчитывает все адреса в абсолютные значения. Так вот при динамической линковке компановщику лишь нужно проверить, что в библиотеке есть символы, которые используются в исполняемом файлы, поставить на месте использования символов заглушки, ну и записать определенную метаинформацию. Никаких вычислений адресов и прочего. Плюс при изменениях в библиотеке, которые не затрагивают API и ABI, можно вообще не перелинковывать исполняемый файл - все изменения подтянутся в рантайме. Линковка-то на самом деле происходит быстрее, но у разделяемых библиотек есть свои недостатки: 👉🏿 оверхэд на инициализацию программы за счет загрузки библиотек 👉🏿 оверхэд на первый вызов каждой функции. Но последующий вызовы уже не имеют заметного оверхэда за счет записей конкретных адресов в таблицу для каждого символа 👉🏿 более сложный деплой. Нужно вместе с бинарником распространять все разделяемые библиотеки. Если используется какой-нибудь докер, то головная боль относительно минимальна А если нет, то есть риски получить конфликты разных версий библиотеки для разных исполняемых файлов(так как все программы, слинкованные с одной шареной либой, обращаются в одному файлу) и увеличение coupling'а между разными программами, использующими одну либу. А вы используете компиляцию модулей своих проектов, как разделяемых библиотек? Share resources. Stay cool. #tools

Митап, который становится доброй традицией Открыта регистрация на третью встречу клуба С++ разработчиков 🔥 PVS-Studio совместно с Центральным Университетом организовывают митап "Сплошные плюсы. Клуб С++ разработчиков". Эти встречи не просто про доклады, это уникальная площадка, где вы можете развивать свои профессиональные навыки в приятной атмосфере. Приглашенные спикеры — действующие разработчики, которые понятно объясняют сложные аспекты с практическими примерами. На третьей встрече клуба вас ждут: ⏺ Доклад "Безопасная работа с массивами? Нет, не слышали" Иногда разработчику на С-подобном языке приходит в голову идея использовать двумерный массив как одномерный. Причины для этого всегда разные, а вот результат чаще всего один. Разберём эту сомнительную технику и поговорим о том, какие проблемы она может привнести в вашу программу. ⏺ Квиз++ Проверьте, насколько вы владеете C++ в соревновании для настоящих ценителей языка. Каждый раунд — это новый уровень сложности и адреналина! А ещё — это вкусная пицца, эксклюзивный мерч и классная атмосфера комьюнити, где все свои ❤ Регистрируйтесь по ссылке.

include what you use #опытным Еще один способ уменьшить время сборки. Ваша программа может содержать все хэдэры стандартной библиотеки и прекрасно собираться. В чем проблема? Неиспользуемые шаблоны же не компилируются. Не компилируются, но анализируются. Если включить в вашу единицу трансляции кучу ненужных хэдэров, то вся эта куча ненужного кода все равно будет как минимум анализироваться на этапе компиляции на соответствие синтаксису. И на это тратится время. А инклюдятся не только шаблоны, поэтому как максимум в объектный файл могут попасть совершенно неиспользуемые части. Чтобы избежать лишнего анализа, есть такая практика в программировании на С/С++ - include what you use. Включайте в код только те заголовочники, где определены сущности, которые вы используете в коде. Тогда не будет тратится время на анализ ненужного кода. У этого подхода есть еще одно преимущество. Если мы полагаемся на неявное включение одних хэдэров через другие, то могут возникнуть проблемы при рефакторинге. Вы вроде был убрали только ненужный функционал вместе с объявлениями соответствующих сущностей, а билд сломался с непонятной ошибкой. Потому что вы убрали источник тех неявно подключаемых заголовков и компилятору теперь их недостает. А мы знаем, какие он "шедевры" может выдавать, если ему чего-то не хватает(тот же пример с std::ranges::less) Как использовать этот подход в проекте? Я знаю пару способов: 1️⃣ Утилита iwyu. Установив ее и прописав зависимости в симейке, на этапе компиляции вам будут выдаваться варнинги, которые нужно будет постепенно фиксить:

    
        # установка

sudo apt-get install iwyu

# интеграция с cmake

option(ENABLE_IWYU "Enable Include What You Use" OFF)

if(ENABLE_IWYU)
    find_program(IWYU_PATH NAMES include-what-you-use iwyu)
    if(IWYU_PATH)
        message(STATUS "Found IWYU: ${IWYU_PATH}")
        set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE "${IWYU_PATH}")
    else()
        message(WARNING "IWYU not found, disabling")
    endif()
endif()

# запуск

mkdir -p build && cd build
cmake -DENABLE_IWYU=ON ..
make 2> iwyu_initial.out

# Анализ результатов
wc -l iwyu_initial.out  # Общее количество предупреждений
grep -c "should add" iwyu_initial.out  # Пропущенные includes
grep -c "should remove" iwyu_initial.out  # Лишние includes{}
    

Там есть еще нюансы с 3rd-party, которые мы вынесем за рамки обсуждения. 2️⃣ clang-tidy. Если у вас настроены проверки clang-tidy, то вам ничего не стоит подключить include what you use. Достаточно к проверкам добавить пункт misc-include-cleaner. В конфиге также можно настроить различные исключения, что мы также выносим за скобки обсуждения. В целом, полезная вещь. Помогает меньше связывать модули друг с другом, а также потенциально уменьшает время компиляции. Include what you use. Stay cool. #tools #goodpractice

⌨️ Ручная компиляция и проекты, привязанные к IDE — это вчерашний день. Если вы хотите уверенно собирать кроссплатформенные C++-приложения и масштабировать проекты, без CMake не обойтись. 🗓 30 сентября в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «C++ Developer. Professional». 🦾 На открытом уроке мы разберём основы CMake: создадим минимальный CMakeLists.txt, подключим внешние библиотеки и соберём проект из нескольких файлов. Пошагово, на живых примерах. Вы поймёте, как переводить свои проекты на CMake и почему этот инструмент давно стал стандартом в профессиональной разработке. Эти навыки — must have для любого C++-разработчика, который планирует карьерный рост. 🔗 Ссылка на регистрацию: https://otus.pw/cAZx/ Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Откуда такая скорость у mold? #опытным На графиках с предыдущего поста видно, что mold работает чуть ли не на порядок быстрее, чем ld или gold. За счет чего они так сильно ускорили линковщик? Понятное дело, что будет затрагиваться много аспектов и будет применено много оптимизаций, но мы сегодня рассмотрим самые важные и интересные из них. Поехали: ⚡️Самая мякотка - работа в параллель. C единицами трансляции мы интуитивно понимаем как параллелить: каждому вычислительному юниту даем обрабатывать свою TU. С линковкой конечно сложнее, но тоже решаемо. Линкерам на вход подается большое число однотипных данных, которые нужно обработать, и между которыми не так уж и много связей. Поэтому эту гору данных можно разбить на поток задачек, которые независимо можно выполнять на большом количестве потоков. Однако рано или поздно наступит этап reduce, когда нужно собирать данные воедино. Для этого они используют потокобезопасную мапу, которая хранит отображение названия символа на сам объект символа. В качестве такой мапы mold использует Intel TBB's tbb::concurrent_hash_map. Крутая либа на самом деле, одно из лучших решений для высокопроизводительных потокобезопасных вычислений. ⚡️В качестве аллокатора используют mimaloc. Cтандартный malloc из glibc плохо масштабируется на большом количестве ядер, поэтому они решили попробовать сторонние решения. Среди jemalloc, tbbmalloc, tcmalloc и mimalloc - mimalloc от Microsoft показал наилучшую производительность. ⚡️Маппинг файлов в адресное пространство процесса. Операции ввода-вывода всегда долгие. Но в mold'е сделали ход конем: Они просто отображают содержимое файла в память программы и могут его читать в разы быстрее. ⚡️Если им и нужно записывать данные в файл, то они используют уже существующие файлы для перезаписи данных в них, нежели чем создают новые файлы. Данные намного быстрее записываются в файл, который уже находится в кэше буфера файловой системы. Молодцы, ребята. Комплексно подошли к проблеме, работали по всем фронтам и применили интересные технические решения. Be faster. Stay cool. #tools

​​Быстрые линкеры #опытным По предыдущим постам стало уже понятно, что линковка - бутылочное горлышко всей сборки. Если меняется хоть одна единица трансляции - перелинковываться бинарник будет полностью вне зависимости от количества TU в ней. Хотелось бы ускорить движение по этому горлышку. GCC как самый широкоиспользуемый компилятор использует ld в качестве линкера. ld считается очень громоздким, раздутым и от этого медленным. Можно решить проблему гениально и просто использовать быстрый линкер! С ld можно бесшовно перейти на другой совместимый компоновщик с помощью опции -fuse-ld. То есть буквально:

    
        g++ -fuse-ld=<my_linker> main.cpp -o program{}
    

И ваша программа будет собираться с помощью my_linker. Ну или в cmake:

    
        # Установка линкера для всего проекта
set(CMAKE_LINKER my_linker)

# Или для конкретной цели
target_link_options(my_target PRIVATE "LINKER:my_linker"){}
    

Какие альтернативные компоновщики существуют? ✅ GNU Gold. Еще один официальный линковщик из пакета GNU. Создавался как более быстрая альтернатива ld для линковки ELF файлов. Он действительно быстрее ld, но теперь его уже никто не поддерживает и недавно в binutils задепрекейтили его. ✅ lld (LLVM Linker). Линковщик от проекта llvm. Активно развивается и имеет интерфейсную совместимость с дефолтовым ld, как и clang имеет в gcc. Быстрее Gold. ✅ mold. Или modern linker. В несколько раз быстрее lld и является самым быстрым drop-in опенсорсным линковщиком. Он использует более оптимизированные структуры данных и каким-то образом линкует в параллель! Благодаря этому достигается фантастическая скорость работы. Собственно, переход на любой из этих линковщиков в теории должен произойти бесшовно. Просто добавляете флаг и все. Но плюсы тоже обещают обратную совместимость, но апгрейдить компилятор не всегда является тривиальной задачей. Поэтому могут всплыть интересности. В любом случае стоит попробовать и, возможно, вы в несколько раз сможете сократить время линковки. Be faster. Stay cool. #tools #compiler

​​ccache vs cmake #опытным И давайте раскроем очевидный вопрос: чем кэширование ccache отличается от кэширования самого cmake'а? Ведь при искрементальной сборке cmake пересобирает только те файлы, которые поменялись. Основное отличие: cmake - это система сборки, а ccache - это четко кэш. cmake не может себе позволить анализировать контент всех файлов, его основная задача - билдить проект. Поэтому ему нужно очень быстро понять, изменился файл или нет. И принимает он решение на основе времени модификации файла. А ccache не ограничен такими рамками. Он учитывает контент препроцесснутого файла и контекст компиляции. Проще понять разницу на примерах: 🔍 Вы скомпилировали проект и случайно или специально(бывает нужно, если cmake троит) удалили папку с билдом. Без ccache нужно перекомпилировать все, а с ним - ничего, только линковку сделать. 🔍 Вы плотно работаете с несколькими ощутимо отличающимися бранчами, собираете, коммитите и переключаетесь. Без ccache нужно будет перекомпилировать все измененные при переключении бранчей файлы. С ccache - только те, которые вы сами изменили после последней сборки. 🔍 Если вы правите только комменты в файле, то голый cmake пойдет перекомпилировать его. ccache - нет, потому что работает с препроцесснутым файлом. 🔍 Вы активно переключаетесь между конфигурациями при сборке. Например между релизом и дебагом. cmake будет полностью пересобирать проект при изменении типа билда. А ccahce после одной сборки на каждую конфигурацию все запомнит и вы будете компилировать только последние изменения. Not much, но каждый из нас частенько сталкивается с одним из этих пунктов. Поэтому ставьте ccache. Это сделать просто, но импакт дает ощутимый в определенных кейсах. Compile fast. Stay cool. #compiler #tools

​​Распределенные компиляторы #опытным Как только ваш проект достигает определенного размера, время компиляции начинает становиться проблемой. В моей скромной практике были проекты, которые полностью собирались с 1-2 часа. Но это далеко не предел. Пишите кстати в комментах ваши рекордные тайминги сборки проектов. С этим жить, конечно, очень затруднительно. Даже инкрементальная компиляция может занимать десятки минут. Как разрабатывать, когда большая часть времени уходит на билд? Кто-то безусловно будет радоваться жизни и попивать кофеек, если не пивко, пока билд билдится. Но компании это не выгодно, поэтому кто-то должен озаботится этой проблемой. То есть вам необходимо найти эффективные способы сократить это время, чтобы свести к минимуму периодические задержки и максимизировать продуктивность. Есть разные способы достичь этой цели, один уже рассмотрели. Но сегодня мы поговорим распределенную компиляцию. Основная идея распределенной компиляции такова: поскольку единицы трансляции обычно можно компилировать независимо друг от друга, существует огромный потенциал для распараллеливания. Это значит, что вы можете использовать множество потенциально удаленных CPU для того, чтобы нагрузка компиляции распределялась между этими юнитами вычисления. Так как обычно девелоперские задачи в среднем потребляют мало ресурсов(не так много нужно, чтобы писать буквы в редакторе), этими удаленными CPU могут быть даже машины ваших коллег! Наиболее известный представитель систем распределенной компиляции с открытым исходным кодом — это distcc. Он состоит из демона-сервера, принимающего задания на сборку по сети, и обёртки (wrapper) для компилятора, которая распределяет задания по доступным узлам сборки в сети. Вот примерная схема его работы:

    
        ┌─────────────────┐    ┌─────────────────────────────────┐
│   Клиентская    │    │        Ферма компиляции         │
│     машина      │    │                                 │
│                 │    │  ┌───────┐  ┌───────┐  ┌───────┐│
│  ┌─────────────┐│    │  │Worker │  │Worker │  │Worker ││
│  │ Координатор │◄──────►│  1    │  │  2    │  │  N    ││
│  └─────────────┘│    │  └───────┘  └───────┘  └───────┘│
│                 │    │                                 │
│  ┌─────────────┐│    │  ┌─────────────────────────────┐│
│  │  Кэш .o     ││    │  │       Distributed Cache     ││
│  │  файлов     │◄──────►│                             ││
│  └─────────────┘│    │  └─────────────────────────────┘│
└─────────────────┘    └─────────────────────────────────┘{}
    

- Координатор анализирует зависимости между файлами и распределяет задачи компиляции - Компиляционные ноды выполняют фактическую компиляцию, их набор конфигурируется на клиенте - Распределенный кэш хранит скомпилированные объектные файлы, кэширует результаты компиляции, тем самым ускоряя повторные сборки Этапы работы примерно такие: 1️⃣ Все цппшники проекта проходят этап препроцессинга на локальной машине и уже в виде единиц трансляции перенаправляются на ноды компиляции. 2️⃣ Ноды компиляции преобразуют единицы трансляции в объектные файлы и пересылают их на клиентскую машину. 3️⃣ Последним этапом идет бутылочное горлышко всей системы - линковка. Для нее необходим доступ ко многим объектым файлам одновременно и эта задача слабо параллелится, поэтому и выполняется на клиентской машине. Таким образом вы можете уменьшить время сборки проекта в разы и ускорить разработку в целом. Вот ссылочка на доку для заинтересовавшихся. Speed up processes. Stay cool. #compiler #tools

Внутрянка бэкэнда Бэкенд интересен тем, что ему ставятся амбициозные задачи из самых разных доменных областей. И с каждым годом планка все повышается. Все больше сфер жизни оцифровываются, rps растет, а ML хотят все да побольше. Это прям огромная кроличья нора и глубины ее не видно. Однако эти челенджи успешно решаются российскими IT-компаниями. И 4 октября в Москве эксперты нашего бигтеха будут раскрывать про внутрянку своих продуктов на конференции «Я про бэкенд»! В докладах будет,много про бэкенд челледжи, связанных с МЛ, рекомендательными и генеративными технологиями. Держите список докладов: -Антон Полднев (Яндекс Реклама): как рекомендательный движок ежегодно экономит 200 тыс. CPU в инфраструктуре Рекламы -Дмитрий Погорелов (VK): эволюция рекомендательного движка и перезапуск рекомендаций ВКонтакте -Михаил Чебаков (T-Банк): как прятать сложность LLM-инференса за понятными числами -Андрей Шукшов (Яндекс R&D): внутри LLM: как выжать максимум из decoder attention на GPU -Алёна Васильева (Шедеврум): про архитектуру для ML-моделей и длинный инференс -Никита Сикалов (Яндекс Поиск): про эволюцию технологий реалтайм-индексации И еще куча интересностей, которые вы может найти в программе мероприятия по ссылочке. Регистрируйтесь и прокачивайте свои бэкэндерские мускулы