Привет Хабр. Мы хотим вам немного рассказать про один интересный недавний ремонт, а так-же свой опыт и инструкцию скачивания прошивки с ПЛИС ALTERA MAX.
Началось все с прибора Fluorophos FLM200 – прибор для проверки качества пастеризации молока.
История про второй (и последний) прототип моего умного флориума с управлением через веб. Жанр — инженерная трагикомедия.
Речь о процедурно‑параметрическом программировании, о котором почти никто не пишет. Я реализовал одну и ту же задачу в ООП и в этой парадигме и сравнил их численно. Одна из метрик разошлась в 6 раз.
Это вторая часть статьи Путеводитель по чужим STL, возможно будет и третья про разные трюки-хаки с контейнерами, как наберется материал.
Стандартная библиотека плюсов оказалась почти непригодной для игровой разработки и поняли это практически сразу, как попытались её использовать. Крупнейший на тот момент издатель Electronic Arts стал самым известным примером реализации стандартной библиотеки для разработчиков игр (но конечно же были и другие, менее именитые), и силами команд нескольких студий под руководством Paul Pedriana это было претворено в жизнь.
Корни EASTL уходят в Maxis к 1998-му году, когда Пол работая над SimCity 3000, выступал на GDC с докладом «High Performance Game Programming in C++» про кастомные контейнеры, стоимость вызовов и замеры производительности. Единой EASTL тогда ещё не было, но подход, из которого она потом выросла, виден уже там.
До консолидации, даже внутри одной студии, могли существовать несколько параллельных STL-реализаций, разработанных под разные игры, платформы и инструменты. Рискну предположить, что самой полной была реализация от Maxis, как одной из ведущих студий, а в других командах были поменьше, каждая со своими допущениями.
Он же в статьях и докладах упоминал, что EASTL была синтезом практик из этих внутренних вариантов, а не работой одного человека с нуля, и в основе большой EASTL лежит коллективный опыт нескольких инженерных команд, даже если формальным автором финальной публичной версии и статьи остался он один. Конкретные имена соавторов отдельных модулей (аллокаторов, фиксированных контейнеров и т.д.) указаны в репо, но слава досталась Полу.
Привет, Хабр! Меня зовут Влад Лундышев, мне 23 года, я учусь в онлайн-магистратуре ИТМО в партнёрстве с Яндекс Практикумом на направлении «Фронтенд-, бэкенд-разработка и ИИ-решения» и параллельно работаю Python-разработчиком. Если бы несколько лет назад меня спросили, что самое сложное на пути в IT, я бы ответил: изучить язык программирования и алгоритмы, освоить сложный стек. Сейчас я думаю иначе. Самым сложным оказалось найти первую работу, научиться взаимодействовать с командой и выстроить систему развития, которая не приводит к выгоранию. В этой статье я расскажу, какие подводные камни встретились мне на пути и что я бы посоветовал себе самому несколько лет назад.
Попалась функция на языке С++. На её примере прям просится показать, что, делая рефакторинг, можно не только эстетично сократить код, но и оптимизировать его. Давайте разомнём мозги, они нам ещё пригодятся, несмотря на эпоху вайб-кодинга. Кто-то ведь должен понимать, как делать надо, а как не надо.
Я заменил std::deque на boost::circular_buffer в надежде получить прирост производительности. В реальности получил загрузку процессора в 25% вместо 2%.
Закон Мура, похоже, задвинули, т.к. упоминается он все реже и реже. А вот закон Амдала нет-нет, да вспомним. Тем более, что он приведен чуть ли не в каждой книге по параллельному программированию. А, ведь, есть и другие законы типа закона Гроша или гипотезы Минского. Но подобный их статус обязывает ко многому. Однако после детального знакомства с ними это ощущение, как правило, теряется.
В законе Амдала, вроде, все правильно, но что-то не так и не то. Подобные сомнения возникли почти сразу после знакомства с ним. Но, правда, кто я такой, чтобы давать оценку? Да и интересовали меня на тот момент другие проблемы, к которым данный закон имел, как мне представлялось, косвенное отношение.
Однако, «давно не было такого и вот опять» – свежая статья на Хабре про закон Амдала, да еще и с настоятельной рекомендацией его изучать[1]. Пришло, видимо, время мне на эту тему высказаться. Хотя бы в пику его «обязательности чтения», т.к. для тех, кто «проектирует параллельные системы», подобные советы представляются не только излишними, а даже вредными.
Все это, конечно, с «высоты» нынешних моих позиций. За прошедшее время они стали более строгими. Но все же это только моя личная оценка, но опирающаяся на мой опыт и на общепризнанные научные представления о процессах распараллеливания «реальных задач».
Так давайте попробуем понять кто прав, а кто нет. А поможет нам математика, которую можно не понимать, можно даже не любить, но не уважать нельзя.
HEIF, HEIC и AVIF на Android через ImageMagick: хроника внедрения в два этапа. Без лишней воды — только проблемы и их решения.
После вайб-кодинга: почему в 2026 году появляется новый класс Code Clean-up Agents. Как стоимость разработки смещается от генерации к проверке, рефакторингу и контролю изменений
Я всё чаще вижу один и тот же сценарий. Агент получает задачу, за несколько минут собирает патч, запускает тесты и сообщает об успехе. Первый просмотр выглядит обнадёживающе. Потом начинается ревью.
Чем быстрее появляется код, тем больше времени уходит на восстановление контекста: что агент поменял, на какие факты опирался, какой конфигурацией запускал тесты и сколько попыток сделал до финального ответа.
В этой точке полезно отделить генерацию патча от подготовки изменения к отправке в основную ветку. Для второй задачи в 2026 году формируется отдельный класс инструментов: Code Clean-up Agents.
Как устроен KalinkaPlayer: модульный бэкенд, нативный аудиоплеер, пайплайн метаданных и мобильное управление в одном проекте.
Казалось бы, современный C++ дает нам море инструментов для контроля кода на этапе компиляции: static_assert, концепты, constexpr всё, что только можно. Но что делать, если вам нужно заставить разработчика вызвать обязательную функцию инициализации инфраструктуры тестирования для библиотечных классов, а проект собирается под ARM с агрессивным -O2 -Os -flto=auto в недрах Yocto/OpenBMC?
В этой статье я расскажу, как попытка добавить удобный режим тестирования для датчиков которые используют header-only библиотеку столкнулась с невероятно умным оптимизатором GCC 14.2, и почему в эпоху мегабайтных исходников нам всё ещё приходится спускаться на уровень инлайн-ассемблера, чтобы просто заставить линкер выдать ошибку для не корректного кода (для определения правила использования хидера).
Встречайте FancyArgumentParser
Парсинг аргументов командной строки в C++ нередко превращается в набор громоздких решений или самописных костылей. Я решил упростить эту задачу и написал FancyArgumentParser — небольшую библиотеку для обучения и пет-проектов. В статье рассказываю, как она устроена, чем удобна и как быстро подключить её к своему проекту.
Меня зовут Самир, мне 16 и я хотел бы поделиться с вами одним из моих текущих проектов: Veo (https://github.com/SamirShef/veolang). Veo это системный язык программирования. Я хочу использовать его для написания своих программ в будущем. А ещё я разрабатываю его потому что мне интересны комплияторы и потому что мне нечего делать.
Я больше года занимаюсь компиляторострением.
Привет Хабр! Большинство современных метеостанций для умного дома бесполезны без интернета или локального MQTT-брокера. Пропал Wi-Fi — данные о микроклимате за последние сутки испарились вместе с перезагрузкой контроллера. Готовые логгеры стоят дорого, а их проприетарное ПО не дает доступа к сырым данным. Мне требовалось максимально дешевое и автономное решение — классический "черный ящик" для квартиры и балкона. Устройство должно пережить внезапное отключение света, не потерять ни одной точки замера и при этом отдавать накопленную историю в виде простого txt файла. Никаких облаков, подписок и зависимостей от сторонних сервисов. В этой статье я расскажу, как собрать такой регистратор на базе ESP32-C3 Super Mini, барометра bme280, датчика температуры и влажности и обычного карт-ридера!
Приветствую, Хабравчане.
Предлагаю вам, окунуться в ретро программирование на С++ 23 и модулях. Да вы не ослышались. Это вполне возможно и я готов вам рассказать это и показать на практике.
Но сначала мы напишем движок для моей любимой игры Arcanum. Но мы не остановимся на спрайтах и старой графике, я добавлю 3D.
Если хотите узнать как. Заходите. Я рад всем.
Go часто называют простым языком. Но простота синтаксиса не отменяет конкурентности, рантайма, сборщика мусора, интерфейсов, особенностей памяти и реального production-опыта.
Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Владимиром Балуном — разработчиком на C++ и Go, автором YouTube-канала «Владимир Балун» о программировании и основателем школы программирования.
В этом выпуске мы разбираем, почему Go стал таким востребованным, кому он подходит, как на него переходить, а также сильные и слабые стороны языка. Обсуждаем реальные проекты, особенности конкурентности, память, сборку мусора и production-опыт.
Вышло 2 модели prism-ml/Ternary-Bonsai-27B-gguf и prism-ml/Bonsai-27B-gguf
Модели представлены в 2-битном и 1-битном вариантах и занимают всего 7,2 и 3,8 ГБ соответственно. Но самое интересное здесь не размер, а качество после столь агрессивного сжатия. По заявленным результатам, 2-битная версия сохраняет около 95% качества FP16, а 1-битная - примерно 90%.
Благодаря столь компактному размеру 1-битную модель можно запускать даже на смартфонах. Например, на iPhone 17 Pro Max скорость генерации достигает примерно 11 токенов в секунду.
Для запуска потребовался форк PrismML-Eng/llama.cpp. На RTX 3090 мне удалось получить около 60 токенов в секунду. Скорость вполне достойная, однако потребление видеопамяти меня не устроило: при контексте в 256 тысяч токенов 2-битная версия заняла около 18 ГБ VRAM. В это значение входят примерно 3 ГБ, используемые Windows 11.
Я привык работать с TurboQuant версиями llama.cpp, которые заметно эффективнее расходуют память, при использовании параметров: -ctk tbqp3 -ctv tbq3 объём памяти занимаемый контекстом, сокращается в 4.71 раза. При этом качество такого сжатия контекста, согласно результатам тестов, оказывается примерно на 8% выше, чем у F16.
Типичная умная колонка с Алисой — это скромное железо и совсем немного оперативной памяти: у младших моделей её всего 256 МБ на всё устройство сразу. И за каждый мегабайт идёт настоящая борьба между множеством команд и компонентов: бизнес‑логикой, обработкой звука, локальными нейросетями.
Ежедневно мы собираем и анализируем memory‑дампы с миллионов колонок — нам важно понимать, куда уходят эти драгоценные мегабайты.
Меня зовут Сергей, я работаю в команде, которая пишет прикладной код на C/C++ для умных устройств с Алисой (например, колонок, телевизоров и автомобилей). Под катом расскажу, как мы построили и используем инструмент для анализа потребления памяти в проде на нашем флоте Linux‑колонок.
В предыдущем посте мы спроектировали CPU. Я определился с набором команд, написал ассемблер, проверил каждый опкод и создал процессор, работающий в кремнии (или, точнее, в FPGA Altera Cyclone II EP2C5T144C8, что тоже довольно близко). Но у нас пока нет осмысленного ПО (микрокода калькулятора) для запуска на «железе».
В этой части проекта оправдали себя все эксперименты с прототипами на C++, описанные в частях 2 и 3.
Когда я начал писать addsub.asm (самую первую команду, которую я портировал), то не смотрел на пустую страницу, задаваясь вопросом, как работает BCD-сложение. У меня уже имелась эталонная реализация на C++ (addsub.cpp в проекте Proto), верифицированная на тысячах тестовых векторов. Алгоритм был известен, пограничные случаи найдены и охарактеризованы. Я проработал поведение защитного разряда и бита фиксации. Оставалось лишь транслировать это всё на язык ассемблера; задача всё равно сложная, но совершенно иного уровня сложности, нежели изобретение алгоритма в процессе его написания.
Я хотел бы сделать упор на этот двухэтапный процесс, потому что может показаться, что без него можно обойтись. Написание кода прототипа на C++ с последующей ручной трансляцией на язык ассемблера кажется избыточной и долгой работой. Однако она перестанет казаться избыточной к моменту, когда вы будете отлаживать неочевидный пограничный случай округления в 16-ниббловом BCD-вычитании. Наличие золотого эталона, с которым можно выполнять сравнения, не избыточно: это единственное, что стоит между вами и неделями кропотливого труда или даже провалом проекта.
