Опухший C++-код Старая байка гласит, что программистам нельзя платить за строки кода, иначе они завалят проект бессмысленными копипастами. Теперь за строки платят генеративному ИИ, и байка сбылась буквально. В проекте VibeTensor заявлено около 100 тысяч строк на C++ и больше 400 файлов, но при проверке статическим анализатором выяснилось странное. Настоящих ошибок почти нет, и это как раз проблема. Один и тот же блок кода встречается в тестах девять раз, умные на вид конструкции с массивами и циклами при ближайшем рассмотрении сжимаются втрое, а анализатор вязнет в этом болоте вместе с человеком. Код правильный, выхода за границы массива нет, ошибаться попросту негде, потому что смысла в нём кот наплакал, только длина.

C++29 — начало. Встреча ISO C++ в Брно Число 120000.0 форматировалось как «120000», а 100000.0 внезапно как «1e+05». Два похожих числа выводились по-разному, потому что под механизмом std::to_chars старался выдать максимально короткую строку. В C++29 это чинят, заодно поведение приблизили к Python и выгадали 15% производительности. Рядом другая знакомая боль, когда «верни значение по ключу или дефолт» разворачивается в несколько строк с итераторами. Теперь у ассоциативных контейнеров есть метод lookup, и всё схлопывается в cache.lookup(key).value_or(42). Заодно всё неопределённое поведение наконец собрали в отдельные секции стандарта, написанные для нормальных людей, а не для экспертов по языку описания стандарта. А постфиксным операторам ++ и — разрешили писать = default, чтобы не копировать один и тот же boilerplate в каждом итераторе. И это лишь часть того, что привезли с одной встречи комитета. Узнаем, что ещё меняется в C++ на пути к C++29.

🔥 Kimi K3 на 2,78 ТРИЛЛИОНА параметров запустили на CPU с 8 ГБ RAM. Без GPU, BLAS и фреймворков Проект kimi-k3-in-c реализует inference Kimi K3 практически с нуля на portable C99. Чекпоинт модели занимает 1,56 ТБ, но пик RAM при запуске составил всего 8,24 ГБ. Фокус в MoE и стриминге весов. Из 896 экспертов на токен выбираются только 16, а остальные веса не обязаны постоянно лежать в оперативной памяти. Огромная часть модели читается прямо с диска, поверх этого работает LRU-кэш экспертов. Цена такого трюка очевидна: скорость. При 8 ГБ RAM автор получил около 26,5 секунды на токен, при 64 ГБ уже 19,8 секунды, а на машине с 128+ ГБ, где нужные данные помещаются в память, около 5,6 секунды. Получается любопытная смена ограничения: гигантскую MoE уже можно заставить работать без серверной фермы. Вопрос теперь скорее в том, сколько диска и времени на токен вы готовы отдать за такой inference. github.com/FareedKhan-dev/kimi-k3-in-c #AI #Kimi #LLM #C #LocalAI

Недавно у нас в гостях был Игорь Подвойский — руководитель группы разработки компонентов мультимедиа в проекте KasperskyOS. Игорь поделился большой подборкой книг и материалов для тех, кто хочет глубже разобраться в системной разработке, операционных системах, C/C++, Linux, архитектуре компьютеров и не только. Сохраняйте: Современная инженерная культура: ▫️«Software Engineering at Google» T. Winters ▫️«Site Reliability Engineering» B. Beyer ▫️«How Google Tests Software» J. Whittaker Для тех, кто хочет разрабатывать инфраструктуру: ▫️«Designing Data-Intensive Applications» M. Kleppmann База для новичков: ▫️«Архитектура компьютера» Э. Таненбаум, Т. Остин ▫️«Современные операционные системы» Э. Таненбаум, Х. Бос «Программирование на языке ассемблера NASM для ОС Unix» А. Столяров «Архитектура операционной системы UNIX» M. Bach «The little book about OS development» E. Helin Кое-что по Linux: ▫️«Linux Device Drivers» J. Corbet, A. Rubini, G. Kroah-Hartman ▫️«The Linux Kernel Module Programming Guide» P. Salzman ▫️«Writing device drivers in Linux: A brief tutorial» X. Calbet По операционным системам: ▫️«xv6 А simple, Unix-like teaching operating system» R. Cox ▫️Исходник xv6 Исчерпывающая открытая книга по параллельному программированию: ▫️«Is Parallel Programming Hard, And, If So, What Can You Do About It?» P. McKenney Про память, кэши и прочее: ▫️«What Every Programmer Should Know About Memory» U. Drepper Оптимизация на C, C++ и ассемблере для x86: ▫️Software optimization resources По алгоритмам: ▫️«Алгоритмы» С. Дасгупта ▫️«Competitive Programmer's Handbook» A. Laaksonen Математика для программистов: «▫️Математика для программистов» Д. Юричев Введение в ассемблер для ARMv8: ▫️A Guide to ARM64 / AArch64 Assembly on Linux with Shellcodes and Cryptography Современный C: ▫️«Modern C» J. Gustedt Введение в разработку бэкенда компилятора: ▫️«Essentials of Compilation» J. Siek Список для разработчиков компиляторов от Квентина Карбоне: ▫️Resources for Amateur Compiler Writers

Python: как один из самых медленных языков стал королем нейросетей В наборе тестов USENIX приложения на CPython отработали в среднем в 29,5 раза медленнее, чем те же программы на C++. При этом именно Python стал основным инструментом машинного обучения и держит первую строчку в рейтинге TIOBE, опережая C, C++ и Java. Самый медленный в этой компании язык возглавил область, где всё упирается в скорость вычислений. Разгадка в том, что тяжёлую математику Python выполняет вовсе не сам. Один его вызов способен запустить перемножение матриц из миллионов элементов, и вся нагрузка при этом уходит в скомпилированное ядро на C++ или CUDA. Получается, что в такой работе программа большую часть времени проводит за пределами самого Python.

Превращаем виртуальный индикатор кислорода Subnautica в реальное устройство Синтетический голос произносит «oxygen», и это значит, что времени на решение уже не осталось. Кто нырял в Subnautica, знает эту связку счётчика с двумя числами и подступающей паники. Автор решил вытащить этот прибор из игры в реальный мир и повесить перед собой круглый дисплей, показывающий, сколько кислорода осталось прямо сейчас. Дальше начинается инженерная часть. Студия сама выросла из моддеров и разрешила ковырять игру, так что данные достаёт плагин на C#, читающий значения четыре раза в секунду и отправляющий их наружу по UDP. По пути выясняется, почему кислород в логах утекает дробными долями, а не тикает целыми, и как это спасает плавность будущей анимации.

std::expected в C++23: гайд по миграции с исключений на функциональный error handling Берём функцию, которая грузит пользователя, проверяет права и собирает DTO. На исключениях она пишется в три строки и выглядит компактнее, чем цепочка на std::expected. Вот только какие типы исключений способна бросить эта цепочка вызовов, видно не в сигнатуре, а в документации, и компилятор промолчит, когда в глубине добавится ещё один. С std::expected из C++23 набор возможных ошибок стоит прямо в возвращаемом типе, и его проверяют статически на компиляции. Гайд ведёт от базового API к monadic-цепочкам через and_then и transform_error, показывает конвертацию ошибок между слоями и честно перечисляет места, где переходить как раз не стоит.

Худший язык программирования всех времён /s Инициализировать переменную можно десятком способов, и в одном из них скобки решают, лежит там ноль или мусор с прошлого вызова функции. static делает четыре несвязанные вещи. Целочисленных типов около пятидесяти, а vector — вовсе не вектор, что признавал и сам автор STL. Жанр «почему C++ ужасен» на Хабре выжжен дотла, и всё это читано по двадцать раз. Полгода назад разработчик пробежал 50-минутное видео о худшем языке по диагонали, а теперь пересмотрел целиком и обнаружил неприятное. Если убрать интонацию обиженного джуна и оставить аргументы, процентов 70 там — правда. И все эти боли, от кривых имён до медленных контейнеров, оказываются следствием одного решения из прошлого языка.