13 июня закончилась встреча комитета по стандартизации C++ (также известного как WG21) в Брно (Чехия), на которой комитет работал над будущим стандартом C++, C++29. В этой статье кратко пересказаны все принятые в него нововведения с примерами их использования и ссылками на оригинальные пропозалы для тех, кто захочет познакомиться с ними детально.
Недавно передо мной встала задача расчетной гидро-газо динамики, надо было посчитать сопротивление воздуха, форму огибающего потока, все то, что требовалось, чтобы посчитать траекторию летящего тела. В этой статье я подробно написал и объяснил, как создать CFD solver.
Есть такая забавная категория людей в разработке, давайте назовём их IT-волки. Это те самые ребята, у которых в 26 лет уже 12 лет опыта, в 27 два проекта и архитектура уровня «я тут всё с нуля поднял», а в 28 управление двумя командами под миллион MAU.
Иногда смотришь такое CV и думаешь - ну всё, сейчас придёт человек, который видел боль, огонь и сломаный прод, а потом начинается интервью. И очень быстро становится понятно, что дело вообще не в синтаксисе или знаниях фреймворков, иногда это могут быть идеальные знания, что тоже пугает. Знания конкретных фреймворков, это вообще не проблема и можно забыть название паттерна, потому что этих самых паттернов овердофига и можно перепутать детали. Это нормально, у всех бывает, интереснее другое. Когда начинаешь спрашивать про реальные решения, про ошибки, про “что вы делали”, про “почему вы это сделали именно так”... вот тут часто начинается тишина.
В современном UI помимо удобства есть еще свистелки и гуделки, чтобы зацепить взгляд пользователя. И, зачастую, такой свистелкой являются анимации: нажал кнопку, а у тебя вокруг спец-эффекты, поставил палец вверх, а он красиво подпрыгнул, и так далее.
Большинство таких анимаций, которые вы видите в приложениях практически каждый день, сделаны с помощью Lottie. Например, тут, в Telegram, часть анимированных стикеров и эмодзи сделаны как раз с помощью Lottie.
Почему именно Lottie? Lottie — это JSON-based формат векторной анимации, поэтому он легковесный, легко масштабируется, не требует видеокодеков, хорошо выглядит на экранах с разным DPI.
Привет, Хабр! Меня зовут Кирилл, я разработчик СХД в YADRO и ML-энтузиаст, автор книги "Hands-on Machine Learning with C++". Я заметил, что роль С/С++ в экосистеме машинного обучения трансформируется прямо сейчас. Чтобы понять, какое значение язык играет в развитии ML, мы поговорим о классическом применении C++ для ручной оптимизации вычислительных ядер. Затем разберемся, почему новый стандарт не закрепляет реализаций линейной алгебры, а отдает это на откуп поставщикам стандартной библиотеки и вендорам оборудования. И в завершение подумаем, как работать с «зоопарком реализаций», который из-за этого остается.
Исполним обещанное в [1], где упомянута задача о светофоре Ангера [2]. Она интересна формулировкой, которая заметно отличается от аналогичных задач, и утверждением, что более компактного решения, чем предложенное автором монографии, не существует.
Обычно светофоры моргают, «тупо» реализуя фиксированную временную последовательность. В светофоре С..Ангера есть динамизм. Он определяется датчиками, фиксирующими ситуацию на перекрестке. И это само по себе интересно. А утверждение формальным путем, сомневаться в справедливости которого оснований, казалось бы, нет.
Но нет исследователя, который не ставил бы перед собой задачу доказать недоказуемое или опровергнуть неопровергаемое. И один из способов достичь желаемого – создать решение, подтверждающее вашу правоту. Как настоящие исследователи, мы именно это и попытаемся сделать, опровергнув, если удастся, тем самым утверждение С.Ангера.
А начнем мы с реализации светофора в исходной формулировке, хотя и в рамках другой формальной модели [3].
Продолжение. Начало здесь. Предыдущая часть. Репозиторий с кодом - на гитхабе.
(Сокращения: НАМ - нормальные алгорифмы Маркова, КТ - компайл-тайм, РТ - рантайм).
Следующая неприятность, которая нас ждёт, - это циклы, которые в КТ вовсе не циклы. Нам надо как-то научиться бегать по правилам, из которых состоит НАМ-программа.
Это вторая статья об использовании LLM в проекте разработки компилятора языка программирования как транспилятора в код на C++. Я продолжаю историю и хочу рассказать о своих наблюдениях и впечатлениях от попыток применять автономных агентов в большом и сложном проекте. А также о навязчивой рекламе и встроенных «закладках» в коде некоторых инструментов, которые, похоже, целенаправленно ухудшают работу с моделями конкурентов.
Новая графическая эпоха для игры детства , реалистичный туман , оптимазиация , кроспалтформеность и современые тени
Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.
Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.
И самое интересное заключается в том, что так было не обязательно.
Привет, мой читатель с Хабра!
Знаешь ли ты о том, что такое многопоточное программирование? Если да, то это хорошо! Если же нет, то придётся почитать немного скучноватой теории про такую известную технологию программирования, как многопоточное программирование, а затем мы копнём эту тему глубже…
Чтение сериализованных данных — это инфраструктурный налог, который платит каждый сервис при получении информации из внешних источников, например по сети или с диска. В индустрии для схематизированных данных стандартом де‑факто стал Protobuf, и чаще всего этот налог выражается в существенных затратах CPU на его парсинг. В продвинутых случаях парсинг пытаются заменить на значительно более дешёвую, но при этом куда менее удобную работу с zero‑copy представлением FlatBuffers.
Мы открыли исходники YaFF (Yet Another Flat Format) — формата, который убирает этот налог, не заставляя отказываться от Protobuf. На масштабе Яндекса это особенно важно, потому что менять такие базовые вещи, как формат, дорого и больно. Поэтому YaFF изначально спроектирован как альтернативный wire format для существующих экосистем Protobuf (и в перспективе FlatBuffers). Это позволяет дёшево и бесшовно встраиваться в существующие проекты, не переписывая десятки тысяч строк кода.
Как это работает на практике, мы покажем на примере Яндекс Рекламы: в рекомендательной системе, где каждый из сотен тысяч запросов обрабатывает десятки тысяч объектов, нужно особое внимание к представлению данных. Благодаря YaFF мы смогли постепенно, шаг за шагом, оптимизировать систему и без дорогих рефакторингов сэкономить 10–20% CPU в масштабах крупных рантаймов.
Продолжение. Первая часть - программирование на НАМ. Вторая - обзор неприятностей, концепты.
Пришло время запутаться и распутаться со строками в компайл-тайме... и с зависимыми типами.
Основные требования к КТ-строкам - чтобы можно было использовать их в качестве параметров шаблона, и чтобы можно было писать constexpr-функции, логика и типы которых зависят от значений аргументов. Это не очень сложно, но может быть неочевидно.
В экосистеме современного C++ прочно укоренилось мнение: классический динамический полиморфизм через виртуальные функции (vtable) и наследование — это устаревший, медленный и недружелюбный к кэшу процессора механизм. В качестве «серебряной пули» модно предлагать связку std::variant и std::visit. Если вы спросите любого виртуального умника (ИИ) он до последнего будет убеждать вас что std::variant и std::visit всегда(!) лучше чем виртуальные функции, даже не сомневайтесь. Проблема в том что с таким отношением вы во многих случаях просто лишаете себя выбора адекватного технического решения. Решения адекватного условиям конкретной задачи с необходимостью диспетчеризации вызовов. По интернету кочуют статьи, утверждающие, что std::visit выполняет диспетчеризацию за фиксированное время O(1) и полностью уничтожает старый добрый ООП-подход, но вы должны понимать что не существует универсальных решений на все случаи жизни.
А что если мы попробуем уравнять начальные условия использования обеих техник диспетчеризации и будем использовать вариант с указателями, а не с эмплейс-объектами: std::vector<std::unique_ptr <BaseClass>> и std::vector<std::variantstd::unique_ptr<TypeA>, std::unique_ptr<TypeB>,std::unique_ptr<TypeC>>> в условиях раздельной компиляции классов и кода который делает вызовы (зачем это надо?).
Привет, Хабр.
Сегодня я постараюсь максимально понятным языком объяснить Hazard pointers, с схемой и примерами.
(Продолжение. См. первую часть, где мы научились кодить на марковских алгорифмах "на бумажке").
Какие неприятности нас ждут?
Я уже сказал, что реализация НАМ в КТ - это задача со звёздочкой.
Что нам придётся героически преодолеть, и о чём понятно прямо на старте?
Руководство по разработке своей версии vsnprintf для целочисленных значений для увлекающихся osdev. Проходит стандартные тесты от gcc
В этой статье речь пойдёт не просто об очередном алгоритме, а о том, как можно обойти классический бинарный поиск. Казалось бы, что может быть эффективнее старого доброго деления массива пополам для нахождения значения в отсортированных данных? Однако можно пойти дальше. В этой статье будет рассказываться о самодельном алгоритме «SIMD Quad» - квадратичном поиске.
Идея возникла из необходимости быстро искать 16-битные целые числа в массивах размером до 4096 элементов — именно такие структуры лежат в основе популярного формата Roaring Bitmap. Вместо того чтобы на каждом шаге сравнивать искомый элемент только с одной серединой интервала, авторский алгоритм использует две ключевые аппаратные особенности современных процессоров. Во-первых, это SIMD-инструкции, позволяющие за раз сравнить до 16 элементов. Во-вторых, это распараллеливание работы с памятью, которое даёт возможность безболезненно делить массив не на две, а сразу на четыре части. Так родился гибрид, который сначала выполняет учетверённый поиск по блокам, а затем находит нужный элемент с помощью векторных инструкций. Давайте разберёмся, как это работает и почему такой подход действительно позволяет превзойти бинарный поиск.
Какие программы могут быть по-настоящему достойны хаба "ненормальное программирование"?
Конечно же, программы для нормальных марковских алгорифмов! (Далее - НАМ).
Но, будем честны перед собой: абстрактные машины - очень просты в реализации. Зачастую вызов состоит в том, чтобы сделать какую-нибудь эзотерическую версию, язык для машины на минималках, и затем ещё и минимизировать транслятор для него.
Поэтому поставим задачу со звёздочкой: научимся писать для НАМ в компайл-тайме С++!
Для начала, посмотрим: что такое НАМ и что на них вообще можно делать.
Приветствую читатель!
Для тех кто со мной впервые вот оглавление:
Код лежит тут
Подразумевается что читатель знаком с архитектурой аллокатора из части 3 и понимает алгоритм неявного списка свободных блоков который был освещен в части 1
Аллокатор работает стабильно, все тесты зеленые, включая тесты на стабильность. И следующим шагом логично бы реализовать перегрузки new и delete для abi, но вот незадача: там есть версии принимающие дополнительный аргумент, а именно выравнивание. Эту фичу я реализовать как раз забыл. В архитектуре которая рассматривается в предыдущей статье это оказалось простой, но интересной задачей. Ее мы и обсудим ниже.
Решение потребовало реализации функции mem_malloc_aligned которая выделит бОльший кусок памяти с учетом запрошенного выравнивания что бы мы там точно нашли правильно выровненный адрес.
Но что если адрес указателя из mem_malloc_aligned не совпадает с адресом указателя который вернул mem_malloc? Что делать в mem_free? Что делать в mem_realloc? Как мне работать с указателем перед которым не хедера?
Для начала я решил применить технику добавления смещения перед payload выровненного блока вместо хедера, смещения до payload изначального блока у которого есть хедер и футер.
Но как мне отличить offset от header? Я решил добавить magic number в хедер и футер увеличив тем самым размер оверхеда в 2 раза и раз уж от него считалось внутреннее выравнивание блоков памяти в аллокаторе и минимальный размер блока, то теперь минимальный размер блока стал 32 байта, а с оверхедом все 64. Теперь можно просто проверять magic number и если он не совпадает, то интерпретировать число на месте хедера как смещение до payload блока который вернул mem_malloc и далее получив на него указатель работать с блоком стандартным образом.
