Python/ django

В исходниках DOOM нашли комментарий: «C отстой». Что было дальше?


Перед шириной экрана в doomdef.h разработчики id Software написали, что дефайны отстой, C отстой, а C++ хотя бы лучше как улучшенный C. Разбираем, почему макросы и правда коварны: SQ(1+2) даёт 5, а не 9, и как весь кадр DOOM в 320×200 умещается в 64 КБ.

https://www.youtube.com/shorts/B2iMXfDbYd4

Claude написал 180 млн строк доказательств, проверяя безопасность реального ПО.

Anthropic и Theorem показали подход, который превращает фаззинг-тесты в математические гарантии.

Обычный фаззер перебирает огромное количество входных данных и ищет сбой. Но даже триллионы запусков не гарантируют, что опасный случай найден.

Здесь Claude получает другую задачу: доказать, что выбранный тест не упадёт ни на одном входе размером менее 64 МБ - в рамках заданной модели исполнения.

За несколько недель удалось построить доказательства для 239 точек входа в 123 open-source библиотеках. Проверка идёт на уровне скомпилированного кода RISC-V: Claude пишет доказательство, а Rocq проверяет его корректность.

В процессе обнаружились сотни ошибок. Например, выход за границы памяти в распаковщике, требовавший входа около 20 МБ с редкой структурой.

Это не гарантия отсутствия всех багов в библиотеках. Доказательства покрывают конкретные точки входа и условия: однопоточный статический бинарник, ограниченную память и формальную модель RISC-V/Linux.

Но результат показывает перспективу: вместо бесконечного поиска контрпримеров — проверяемое доказательство конкретного свойства программы.

https://www.anthropic.com/research/formal-verification

⚙️ Почему код тормозит, даже если алгоритм хороший?

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

CPU Performance Engineering собирает материалы, которые помогают разобраться в этих ограничениях. Путь идёт от выполнения одной инструкции до запуска ИИ-моделей на CPU.

Внутри:

• Микроархитектура процессоров x86 и Arm.
• Кэши, память, NUMA и false sharing.
• Профилирование, perf и flame graphs.
• SIMD, векторизация и оптимизации компилятора.
• Многопоточность и задержки под нагрузкой.
• Инференс моделей и квантизация.

В 14 разделах есть воспроизводимые бенчмарки на C: исходники, команды сборки, результаты и разбор. Можно проверить поведение на своём железе.

Подборка опирается на первоисточники: статьи, документацию и измерения. Есть и MCP-сервер для подключения материалов к ИИ-ассистенту.

https://github.com/usamahz/cpu-performance-engineering

Работаете с СУБД? Присоединяйтесь к сообществу Pangolin для разработчиков и администраторов баз данных!

Pangolin DB — это PostgreSQL с 100+ доработками, и команда СберТеха открыто рассказывает о его разработке.
 
В канале «СУБД Pangolin» найдете:
🔹 Глубокие разборы архитектуры и кода
🔹 Кейсы оптимизации и доработки PostgreSQL
🔹 Советы и опыт инженеров
🔹 Вебинары и встречи с экспертами
🔹 Вакансии и жизнь команды от первого лица
 
Присоединяйтесь к сообществу, где говорят на языке баз данных!

👾 Русскоязычный каталог из 2118 проектов по декомпиляции игр: от Ocarina of Time до Xbox 360

На GitHub появился awesome-список, собранный на русском: проекты, которые восстанавливают игры из машинного кода. Это декомпиляции, статические рекомпиляции, порты на исходниках и ремейки движков. Задача простая: помочь найти проект под нужную игру и платформу и объяснить, как всё это устроено.

Масштаб впечатляет. В каталоге около 2118 проектов для примерно 1829 игр, из них 1771 активных. По типам: 786 декомпиляций, 525 статических рекомпиляций, 269 портов на исходниках, 238 ремейков движков, 234 дизассемблирования, 57 браузерных портов и 9 инструментов.

По платформам лидирует ПК с 295 проектами, дальше Nintendo 64 (190), Xbox 360 и PlayStation 1 (по 161). Следом идут DOS, GameCube, PS2, Game Boy Advance и Wii. Среди примеров Zelda (Ocarina of Time, Majora's Mask, Twilight Princess), Mario 64, Sonic, Diablo, Morrowind, OpenRA и OpenRCT2.

Внутри не просто список. В README есть топ-25, отдельный список браузерных портов, каталоги по типам и платформам, раздел о том, как начать декомпилировать самому, FAQ и глоссарий. Из инструментов упоминаются N64Recomp, XenonRecomp, RT64, splat, decomp.me
, objdiff и m2c. Каталог обновляется автоматически через GitHub Actions.

Важная оговорка: сами проекты работают с данными из легально купленных копий игр, а в репозитории лежат только ссылки.

Репозиторий: https://github.com/justxor/awesome-decomp-games-ru

5 алгоритмов для программиста: бинарный поиск, сортировка слиянием, BFS, Дейкстра, скользящее окно

Разбираем 5 алгоритмов, которые пригодятся в реальном коде: бинарный поиск за O(log n), сортировка слиянием за O(n log n), поиск в ширину, алгоритм Дейкстры для кратчайшего пути и скользящее окно за O(n). Короткие визуальные примеры на каждый. Сохраните, чтобы не потерять.

https://www.youtube.com/shorts/e--njUJA3y4

Datadog научила профилировщик Python понимать asyncio: флеймграфы со «стеками из стеков» и оверхед меньше на 60%

Главная боль профилирования asyncio в том, что каждая задача выглядит как независимый стек. Время в запросе к Cassandra повисает в воздухе, и непонятно, какой именно путь в приложении его породил. 

Инженеры Datadog решили это так: профилировщик отслеживает, какая задача кого ждёт, строит дерево зависимостей и начиная с листьев надстраивает фреймы родителей поверх фреймов потомков. Код, разбитый на отдельные задачи, и обычные корутины в одной задаче теперь дают сопоставимые флеймграфы. Если задача живёт дольше создателя, время засчитывается создателю, пока он работает, а затем тому, кто её ждёт.

Цена такого подхода высокая: к стоимости на поток добавляется O(n_tasks), а серверы держат много задач, поэтому адаптивный сэмплинг местами падал до минимальной одной выборки в секунду. 

Резервуарное сэмплирование задач команда отвергла, потому что для дерева нужны метаданные всех задач.

Оверхед срезали тремя шагами. Убрали C++ исключения из пути сэмплирования, это около 15%. Интернировали строки имён функций и файлов, ещё около 25%. Заменили process_vm_readv, по системному вызову на каждый маленький объект, на memcpy с обработчиком сигнала для восстановления после ошибок памяти, это около 50% для синхронного кода. 

В сумме на сервисах с выкаченными изменениями оверхед упал более чем на 60%.

В проде профилировщик нашёл бесконечный цикл в библиотеке pylzstring, которую затем починили в апстриме, и внутреннюю библиотеку, строившую большие debug-строки при логгере уровня INFO. Отдельно ИИ-агент через MCP и Dynamic Instrumentation оптимизировал функ
ции на NumPy и снизил CPU в них на 15-30%. Улучшения доступны в свежих версиях ddtrace. Автор отмечает, что похожий подход принят в Tachyon, профилировщике CPython 3.15, но сравнения не делает, как и абсолютных цифр оверхеда.

Источник: https://www.datadoghq.com/blog/engineering/async-python-profiler/

Indra: OCR-модель всего на 1M параметров, которая рвёт PaddleOCR и Tesseract по скорости

Вик Паручури, автор Marker и Surya, выпустил Indra, крошечную OCR-модель на 1 миллион параметров. Главная фишка в том, что при таком размере она гоняет текст прямо на CPU и делает это очень быстро.

Цифры такие. На CPU Indra обрабатывает 49 страниц в секунду. Это в 11 раз быстрее PaddleOCR и в 17 раз быстрее Tesseract. При этом по качеству она тоже впереди: на тексте из OmniParseBench у неё 41,3 против 35,8 у PaddleOCR и 19,3 у Tesseract.

Модель не только распознаёт текст, но и отдаёт полную разметку страницы и bounding box по строкам, так что её удобно ставить в пайплайны обработки документов.

Миниатюрный размер означает, что её можно запускать локально без GPU и гонять большие объёмы сканов дёшево, а не платить за облачный OCR по страницам.

Модель: https://huggingface.co/datalab-to/indra-ocr
Код: https://github.com/datalab-to/indra
Блог: https://datalab.to/blog/indra-ocr

Трюк Карпаты сработал: локальная LLM на Mac M5 выдает 117 токенов в секунду

Как open-source движок Uzu от Mirai обходит потолок пропускной способности памяти на Apple M5 и разгоняет Qwen3.5 9B с 22 до 117 токенов в секунду: квантизация, спекулятивный декодинг, Weaver и бенчмарк против llama.cpp и MLX.

https://uproger.com/uzu-uskorenie-lokalnyh-llm-apple-m5/