C++ *

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

Это вторая статья из цикла От MNIST к Transformer, цель которого пошагово пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. В этой статье разберем основы работы с памятью и две простые математические операции с точки зрения математики, но не такие простые с точки зрения CUDA ядер.

Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

Всем привет, меня зовут Илья Шишков, я пишу на С++ с 2006 года. Много лет я был разработчиком в больших C++-кодовых базах, но в 2024 году жизнь меня занесла в PostgreSQL. А именно в RnD-разработку СУБД Pangolin, это реляционная СУБД от СберТеха, PostgreSQL с нашими доработками под требования к усиленной безопасности, производительности и так далее. PostgreSQL, как известно, написан на чистом С. Так я поработал с этим языком несколько месяцев и… стал внедрять C++. 

В этой статье я расскажу, зачем так сделал и почему это оказалось очень удобно. Например, некоторые технологии из C++ есть в PostgreSQL, при том, что их нет в C. Разберу практические примеры, как мне кажется, хороших абстракций на C++, которые упрощают программирование на C. И немного времени уделю разбору цены, которую нам приходится платить, когда мы используем в коде различные абстракции.

Выходные с пользой. Как я, моя восьмилетняя дочь и ИИ создавали мини-компьютер на базе Arduino Mega 2560. Цель - доступно объяснить разницу между персональным компьютером и микроконтроллером.

Привет, Хабр!

С радостью и чувством выполненного долга издательство «БХВ» представляет вам одну из флагманских новинок наступившего года. Мы получили из типографии книгу «Game++. Устройство и оптимизация игрового движка».

Как известно, высококлассные AAA-игры — это та территория, на которой сходятся проверенные и экспериментальные алгоритмы, высокая производительность, графика на уровне произведений искусства и проектирование распределённых систем. Главный язык программирования для аса в разработке игр — это C++.

Поскольку сложно объять необъятное, да и участие в разработке The Sims и Age of Empires смотрелось бы в резюме как опыт участия в гонках «Формулы-1», автор, самоотверженно поработав, создал фундаментальную книгу о наилучших практиках высокопроизводительного программирования как в элитном продакшне, так и на очень ограниченных ресурсах. Для автора игры — это полигон, на котором он набрал свой уникальный профессиональный опыт, а C++ — это инструмент, при помощи которого решается любая задача. Отдельно отметим, что в книге уделено внимание не только различным структурам данных и их реализациям, но и стандартной библиотеке шаблонов (STL); этот материал серьёзно повысит профессиональный уровень любого C++-разработчика.  

Далее - от автора, Сергея Кушниренко @dalerank.

Давайте обманем атомик. Вот две функции - можно ли, общаясь к атомику только с их помощью, увидеть некорректное состояние ?

void write(std::atomic<int64_t>& x, int64_t v) { x.store(v, std::memory_order_seq_cst); } int64_t read(std::atomic<int64_t>& x) { return x.load(std::memory_order_seq_cst); }

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

Начну я с фундаментального вопроса: что же такое игра с точки зрения программной инженерии? В целом игра -- это система мягкого реального времени, что означает, что все процессы, которые в ней происходят, начиная от игровых событий вроде нажатия кнопок игроком или появления врагов на экране, продолжая игровой логикой, которая определяет правила взаимодействия объектов и состояния игрового мира, физикой, столкновениями и заканчивая рендерингом, должны происходить в строго определенное время, и это ограничение является абсолютным и не подлежащим обсуждению, иначе мы получим "вязкий" игровой процесс.

Это очень отличает игры от большинства других типов программного обеспечения, где небольшая задержка в несколько миллисекунд не так незаметна или вообще не критична для пользовательского опыта. Вот вы открыли эту статью и ваш браузер грузил эту странцицу на секунду дольше чем мог бы, потому что я как обычно вставил большую КДПВ, но вы как пользователь этого, скорее всего, даже не заметили. Или редактор Хабра, в котором я сейчас пишу эту статью и который сохраняет документ на секунду медленнее чем мог бы, это абсолютно не влияет на работу и вы об этом вообще никогда не задумывались.

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

В интернете есть много разных статей по решению задач с IT-собеседований, но на русском языке по программированию микроконтроллеров я видел только одну статью на Хабре. Недавно я менял работу: посещал много компаний и отвечал на вопросы по поводу различных аспектов моей профессии. По итогам этих и более ранних встреч решил написать о том, чем на собеседованиях могут озадачить программиста микроконтроллеров.

Дисклеймер: эта статья размещена в блоге YADRO, но список вопросов, выделенных в тексте, — это компиляция моего многолетнего опыта и десятков собеседований в разные компании. С наймом в конкретную компанию текст не связан.

В данной статье я описал, как мы разрабатываем систему для функционального контроля микросхем ADV7180BCPZ (SDTV Video Decoder) и ADV7343BSTZ (Multiformat Video Encoder). Показана архитектура системы, общий алгоритм и сценарии тестирования.

Привет, Хабр! Я Кирилл Колодяжный, разработчик систем хранения данных в YADRO и ML-энтузиаст. Продолжаю рассказывать о паттернах С++, которые легко адаптировать под задачи машинного обучения. В этой части поговорим о динамическом полиморфизме — технологии, которая помогает объединить интерфейс для запуска вычислений с разными условиями. Ссылку на первую часть найдете в конце статьи.

Что происходит, когда вы вводите ls в терминале? Как 2 буквы превращаются в список файлов на экране? Я решил разобраться и написал свой терминал с нуля на C++.

В этой статье я объясняю через метафору ресторана, как работают три магических системных вызова — fork(), exec() и wait() — которые лежат в основе любого терминала. Вы узнаете, почему cd нельзя сделать обычной программой, как работает перенаправление >, и какой коварный баг я поймал из-за непонимания процессов. Без сложной теории — только практика и понятные объяснения.

Разработан новый рекомпилятор rexglue, что сдвинуло камень с места и привело к новому витку развития рекомпиляции

В отличие от XenonRecomp код более универсален, соответственно сам создает toml таблицу функций проекта.

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

Сравним разные варианты реализации блокировок с точки зрения накладных расходов. mutex, ptr, atomic в нескольких вариантах. Рассматриваем случай без контеншена.

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

Я хочу запустить большой цикл статей От MNIST к Transformer, цель которого пошагаво пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит.

Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

Язык активно улучшается, осталось недолго до bootstrapping'а! Также уменя есть планы писать LSP и загрузить язык на github linguist. Для последнего нужны репозитории (>200). Для тех, кому нечего делать, или кому просто не лень, попробуйте пописать программки на моем языке. Пока мало что можно будет написать, но, думаю, хотя бы что-то можно.

Как уместить полноценный Shoot ’em up в 3 КБ? Когда иконка на вашем раб столе весит в несколько раз больше. Однако в эпоху терабайтных дистрибутивов всё еще жива магия сайз-кодинга — искусства втиснуть максимум смысла в минимум байт.

Этот проект родился в рамках одного геймджема, где по правилам: «Вначале нужно придумать свой язык программирования, а потом написать на нём игру». У меня было 7 дней, чтобы пройти путь от проектирования архитектуры байт-кода до финальной оптимизации исполняемого файла под Windows.

Углубленный взгляд на устройство работы New | Delete

Переопределение, new_handler, типы new, внутренняя реализация

Привет Хабр!

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

Приветствую вас, дорогие читатели! В этой статье мы разберёмся в том, как нам добраться от самого нуля до первого треугольника. Мы будем использовать Vulkan API 1.0, а затем будем переходить к всё более и более новым версиям этого API. Это моя первая авторская статья, поэтому прошу вашей поддержки. Цель данной статьи - разъяснить процесс отрисовки треугольника так, чтобы любой мог не просто нарисовать треугольник, а понять как устроен простейший рендеринг на Vulkan API на примере отрисовки треугольника.

В данной статье я описываю свой опыт разработки приложений с OpenCL/SYCL.

Вычисления на видеокартах ассоциируются преимущественно с графикой, научными вычислениями и с недавних пор с нейросетями. Но чаще всего с графикой.

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

Самый краткий ввод в гетерогенное программирование: у нас есть две роли — хост и девайс, задача хоста – формировать задачи и отдавать их на девайс, в то время как задача девайса обработать их и вернуть результат. При этом хост и девайс могут быть одним вычислительным устройством (это не обязательно CPU + GPU, так как CPU может отдавать задачи сам себе).