Python/ django

👾 Русскоязычный каталог из 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/