В этой заметке я произвел обзор учебно-треннировочной электронной платы JZ-F407VET6.
Это простая и дешевая PCB часто выручает при прототипировании и отладке программных компонентов.
Код бортового управляющего компьютера космического аппарата Аполлон (AGC) — одна из самых тщательно исследованных кодовых баз в истории. Её прочитали тысячи разработчиков. Учёные публиковали статьи о её надёжности. Эмуляторы выполняют её команда за командой. Мы обнаружили в ней баг, который, похоже, оставался незамеченным пятьдесят семь лет: блокировку ресурсов в коде гироскопического управления, приводящую к утечке на ошибочный путь и отключающую возможность изменения положения платформы наведения.
Для преобразования 130 тысяч строк ассемблерного кода AGC в 12,5 тысячи строк спецификаций мы воспользовались Claude и Allium — нашим опенсорсным языком создания поведенческих спецификаций. Спецификации были выведены из самого кода, и этот процесс направил нас непосредственно к багу.
Я провёл аудит веб-сайта CEO Y Combinator Гарри Тана после того, как он похвастался, что выдаёт по 37 тысяч строк кода в день, и держит этот темп уже 72 дня. В статье я покажу, как на самом деле выглядят в продакшене 78,4 тысячи строк ИИ-слопа. При загрузке одной главной страницы http://garryslist.org в 169 запросах загружается 6,42 МБ. И это для простого новостного блога с рассылкой.
В этом тексте я написал про то как наладить интерфейс командной строки (CLI) по двухпроводному синхронному отладочному интерфейсу SWD.
Посылать в прошивку команды и получать ответ.
Чтобы можно было работать примерно как с UART, только по SWD.
Это когда прошивка в коде асинхронно получает текстовую строку от PC и отправляет текст обратно в сторону PC.
Кошмар с автозавершением
Наше префиксное дерево было в 8 раз медленнее хэш-таблицы. И оно потребляло 128 МБ памяти, в отличие от хэш-таблицы с 24 МБ.
Такого не должно было произойти. Префиксные деревья — стандартное решение для автозавершения: поиск за O(k), где k — длина строки вне зависимости от размера датасета. Идеально подходит для сопоставления префиксов. Обычно всегда используется для автозавершения, проверки правописания и таблиц IP-маршрутизации.
Мой коллега предложил использовать префиксное дерево для функции автозавершения в нашем инструменте командной строки. Поиск в нём должен был выполняться по 50 тысячам команд и опций. Учебники говорили, что это правильный выбор.
Поэтому мы реализовали префиксное дерево. Результаты бенчмарка оказались ужасными:
Префиксное дерево было в 8 раз медленнее простой хэш-таблицы. И оно использовало 128 МБ памяти, в то время как хэш-таблица — всего 24 МБ.
Где мы ошиблись?
Загадка базы данных
Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени.
«Давайте попробуем B-дерево», — предложил я.
«Разве они нужны не только для баз данных на дисках? — спросил лид, — У нас всё находится в памяти. Чем нам будет полезно B-дерево?»
Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее.
В итоге мы реализовали B-дерево. Результаты удивили всех...
Программы часто отлаживают применяя printf-отладку.
Однако в этом есть недостаток. Со временем вывод printf сообщений становится настолько частыми и плотным, что становится просто невозможно что-либо прочитать.
Чтобы с этим бороться придумали уровни логирования Log Levels.
Суть в том, чтобы из shell консоли в run time можно было включать или отключить логи для конкретных программных компонентов. Отдельными командами вы можете увеличивать или уменьшать многословность логирования.
Это позволяет Вам сфокусировать внимание на конкретном программном компоненте и найти суть ошибки в программе или причину по которой не проходит модульный тест.
В процессе моих изысканий о том как-же создавть изображения локально, я столкнулся с неочевидной, для себя, проблемой в виде колоссального потребления VRAM, которое не сходилось с тем что написано в карточках моделей и в интернете.
Я попытался разобраться на примере современной FLUX.2-dev. Чтобы хотябы теоретически влезать в доступную мне VRAM на моем оборудовании я выбрал вариант GGUF Q4_K_M. И вот тут началось все самое интересное.
В этой статье, про ИИ, написанной не полностью ИИ, про генерацию изображений - не будет изображений.
В конце этой статьи мы будем запускать эту модель на указанном чипе, но начнем мы с чуть более мощного - он понадобиться чтобы разобраться с проблемой.
Первая проблема с которой я столкнулся - это потребление памяти. Поиски в интернете, описание самой модели говорили о том что она должна помещаться в ~10GB VRAM. Чего должно с запасом хватать для Apple M1 16GB. Однако фактическое зафиксированное потребление памяти составило 21 GB, не зафиксированное 28 GB (после чего я и начал исследование).
Excel не единственный, кто любит превращать любые данные в даты.
Если вы работаете с датами в JavaScript, то, вероятно, рано или поздно пользовались new Date(someString). Это удобно: передаём строку, получаем объект Date. Но привыкнув к Python, я был удивлён тем, насколько свободно JavaScript обращается с форматами дат. Позвольте мне проиллюстрировать это примерами.
Всё началось с тупой идеи.
У меня есть мышь Logitech MX Vertical, которая постоянно перемещается между моей домашней машиной, рабочим ноутбуком и другими устройствами. Однажды я задумался: у этой штуки есть флэш-память. Она обязана быть, иначе как мышь запоминает настройку DPI между подключениями? А можно ли в этой памяти хранить что-то ещё?
Ага, мне было скучно.
Я решил использовать мышь в качестве крошечного USB-накопителя. Так как она физически перемещается между компьютерами, то, строго говоря, способна и переносить между ними данные.
3 дня борьбы с ROCm, RX580 и Ollama: как я запустил LLM на домашней видеокарте
Я попытался запустить LLM inference на старой AMD RX580 через ROCm и Ollama в Kubernetes. GPU определялся, VRAM занималась, контейнеры запускались — но inference падал с ошибками hipMemGetInfo, а иногда просто выдавал бессмысленный текст.
В статье — полный инженерный разбор:как диагностировать реальный GPU compute (а не просто VRAM usage), почему Vulkan помог найти root cause, какие версии ROCm и kernel оказались рабочими, и как добиться стабильной генерации ~42 tokens/sec на RX580.
Всем привет!
Традиционное вступление в стиле "плач Ярославны": GlobalPlatform, ISO 7816, JavaCard и прочие смежные стандарты - боль. Тонна материала написанная сухим языком так и навивает мысль, что авторы этого всего не инженеры, а юристы. Для примера скажу, что каждый стандарт ETSI начинается со смысловых определений глаголов "shall", "shall not", "should", "should not" и т.д. Нет, в канцелярском стиле ничего плохого нет. Плохо становится когда он плавно переходит поросячью латынь - и это одно из самых терпимых определений. Это же додуматься надо "размазать" требования к несчастной SMS-ске между пятью стандартами (ETSI 102-223/-225/-226 и 131-111/-115).
Ну вот ты преодолел пучины стандартов, затем засел за написание JavaCard-апплета, с чем тоже успешно справился, ну а дальше начинается квест "найди все тулзы". Инструментарий от Oracle для сборки .cap-файлов недоступен из России, благо есть один удобный в открытом доступе. Там же рядышком лежит тулза для установки/удаления апплетов (да и вообще управления жизненным циклом карты).
Итак, ты скомпилировал и загрузил апплет на карту. Классно! А дальше? А дальше поговорим в статье.
Ты понимаешь, что баг хорош, если первым делом думаешь: «Как это вообще может происходить?»
Недавно я занимался доработкой дэшборда веб-приложения, над которым мы работаем, и заметил, что его загрузка длится бесконечно. Раньше на это требовалась одна секунда, но теперь ему требуется десять. Происходит что-то подозрительное.
Разумеется, сначала я обвинил в этом React.
Да, конечно, в современном веб-приложении может быть множество потенциальных причин проблем с производительностью: сторонний JavaScript, перегруженные серверы, раздутые ресурсы, отсутствующие индексы базы данных; список можно продолжать очень долго. Но опыт десятков лет разработки для веба подсказывал мне, что это была проблема фронтенда. Я просто чувствовал это. При загрузке страница дёргалась. И несмотря на то, что экосистема React сегодня — наименее плохой выбор для веб-фронтенда, она по разным причинам может оказаться хаотичной и тормозной.
Чтобы подтвердить свою теорию, я рассказал Claude1, что загрузка дэшборда тормозит и что проблемы наверняка в React, попросив проанализировать их и ранжировать по степени серьёзности. Конечно же, Claude обнаружил в React кучу подозрительных аспектов — ненужный повторный рендеринг, отсутствующие мемоизации и так далее. К тому же он подсказал, что мы всё ещё не используем React Compiler. Я попросил Claude выполнить первый проход решения самых простых и самых серьёзных проблем React, но…
Практически ничего не поменялось. Возможно, дело всё-таки не в React.
Итак, я закатал рукава и начал тщательное расследование.
В прошлом месяце я исследовал периодически возникающие всплески задержек в нашем сервисе отчётности и обнаружил нечто, заставившее меня не поверить своим глазам: 102 потока блокировалось одновременно, и все они ждали одной блокировки. Причиной этого оказалась одна строка кода, выглядевшая совершенно невинно.
Это история о том, как DatatypeFactory.newInstance() поставил на колени наш высокопроизводительный Java-сервис, и об удивительно простом решении, позволившем полностью избавиться от проблемы.
На прошлой неделе я попросил Claude устранить однострочный баг. Ему понадобилось 23 тысячи токенов. Потом тот же баг я попросил устранить Gemini. Он потратил 350 тысяч токенов. Да уж, на такое невозможно закрывать глаза.
Поэтому я написал Context Lens — трассировщик контекста, перехватывающий вызовы LLM API, чтобы показать, что же на самом деле находится в окне контекста с разбивкой по этапам. Я подключил его к четырём инструментам кодинга и дал им одну и ту же задачу. Результаты оказались настолько разными, что я решил написать об этом статью.
Вопрос
При работе с этими моделями мы платим за токены. Токены — это довольно сложная тема. По сути, это блоки информации; 1 токен приблизительно равен 4 символам английского текста. Чем больше токенов передаётся в модель, тем больше мы платим.
Но важнее то, что токены составляют контекст модели. Контекст — это всё, что есть у модели при генерации ответа, своего рода её кратковременная память. Как и у людей, она ограничена. И чем больше нужно запоминать, тем хуже мы справляемся при ответе на детализированный вопрос.
Итак, нам нужно быть аккуратными с нашим окном контекста, а для построения этого окна используются токены. Я задался вопросом: как инструменты справляются с этим ограничением? Насколько умно они его обрабатывают?
В релизе 1.26 языка Go, выпущенном в этом месяце, есть полностью переписанная подкоманда go fix. Go fix использует набор алгоритмов для обнаружения возможностей улучшения кода; часто для этого применяются более новые фичи языка или библиотеки. В этом посте мы сначала покажем, как использовать go fix для модернизации кодовой базы на Go. Во второй части статьи мы расскажем о лежащей в основе этой подкоманды инфраструктуре и её эволюции. В третьей части мы познакомим вас с тематикой инструментов анализа с «самообслуживанием», которые помогают мейнтейнерам модулей и организациям кодироовать собственные правила и рекомендации.
Появился открытый инструмент Coding Agent Explorer — обратный прокси-сервер, который в реальном времени показывает всё общение между вашим ИИ-агентом (пока только Claude Code) и API Anthropic. Вы видите системные промпты, последовательность вызовов инструментов, токены (включая кэш), мышление агента шаг за шагом. Запускается за пару минут, работает локально, ключи маскируются автоматически.
Признаюсь, я питаю слабость к классическому DOOM. Игре уже 31 год, но благодаря открытому исходному коду она живёт на всём — от смартфонов до осциллографов. В силу разных обстоятельств я стал сопровождать несколько пакетов, связанных с DOOM, в Fedora Linux.
Перед каждым релизом Fedora проводит массовую пересборку всех пакетов — и в этот раз chocolate-doom её не пережил. Виновник этому — маленький bool.
Последние месяцы я вижу одну и ту же сцену.
Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.
А потом начинаются знакомые фразы:
