Разработка

Всем привет! Сегодня продолжаем нырять в глубины питона, но в другом формате.

В субботу (20 сентября 2025го) у нас завершилась наша первая бесплатная конференция сообществ Нижнего Новгорода.

На ней у нас был шикарный Python-трек с очень глубокими докладами от наших любимых хабравчан про устройство разных частей интерпретатора и несколькими вводными на смежные темы. Выступали и новички, и «старички» :)

Как по мне — вышло отлично.

Под катом будет полный список докладов и материалов, заходите и смотрите!

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

В течение восьми лет такой была реальность моего взаимодействия с Dell Inspiron 5567. Этот необъяснимый баг возникал в каждой установленной ОС. В статье я расскажу историю о том, как погрузился в исходный код прошивки и обнаружил единственную команду-виновницу.

История Фила Катца — это классическая IT-драма: блестящий взлёт, жёсткая конкуренция, суды, огромный успех и, в конечном итоге, личная трагедия.

Надоело каждый раз лезть в терминал, чтобы скачать видео с YouTube? Мне тоже. Поэтому я сделал нормальный GUI для yt-dlp - без лишних кнопок, с современным интерфейсом и чтобы просто работал. Код на GitHub, готовая сборка тоже есть.

Зачем вообще это делать?

Да, yt-dlp крутой - качает с кучи сайтов, быстрый, надёжный. Но блин, каждый раз набирать команды в консоли - это не для всех. Особенно когда нужно быстро скачать что-то и не париться с параметрами.

Посмотрел на существующие GUI - одни выглядят как из 2005 года, другие напичканы настройками, которые 99% пользователей никогда не трогают. Захотелось сделать что-то простое: вставил ссылку, выбрал качество, скачал. Всё.

Что хотел получить:

Простоту - минимум кликов от ссылки до файла

Нормальный вид - тёмная тема, без уродских кнопок из 90-х

Скорость - никаких тормозов и зависаний

Работает везде - Windows точно, остальные ОС в планах

Не требует установки - скачал exe и пользуешься

Всем привет! Я Андрей, ML-разработчик из команды распознавания речи в Т-Банке. Мы занимаемся полным циклом разработки: сбором и разметкой данных, проведением экспериментов по обучению моделей, интеграцией в продакшен.

В русскоязычном сегменте давно не хватает открытых моделей распознавания речи, которые можно было бы быстро кастомизировать под реальные задачи. Более того, почти все доступные модели работают офлайн и не адаптированы под специфику телефонии. Поэтому мы решили опубликовать собственную потоковую акустическую модель с кодом для ее инференса и дообучения, а еще выложить 5-граммную языковую модель.

Акустическая модель является по-настоящему потоковой, легковесной, производительной и обгоняет по качеству более крупные открытые офлайн-модели в телефонии.

В статье расскажу, как устроена потоковая модель распознавания, как и на чем ее обучали и как ее можно использовать.

Я люблю вызовы - например, написать код в условиях ограниченных ресурсов: медленный процессор, странный набор инструкций, крохи памяти. У меня уже было несколько проектов такого рода - я запускал тяжелую вычислительную задачу на процессорах, которые уже разменяли пол-века: Intel 4004, Intel 4040 и Intel 8008. Очевидно, что на очереди Intel 8080!

В этой статье я опишу детали проекта по созданию системной платы с чипсетом на основе FPGA, на которой будет запущен Intel 8080A-1 на частоте выше 3Мгц. А также расскажу о том, как писать программы для этого процессора на C, и в финале покажу результаты бенчмарков - Dhrystone и CoreMark.

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86.

На первый взгляд, это абсурд В сущности, так и есть. Однако есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода. Так и задумано, что писать код с очень высоким показателем IPC непросто. Следовательно, челлендж «Напиши медленный код» оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

_{¹Но это не точно. Мы не сравнивали, конечно. Но крайне вероятно, что действительно самый быстрый. И вообще, он ещё не в машкодах.}

У нас был 6502-й, алгоритм Брезенхема, самый нелепищный и несуразный графический ускоритель и немного переключаемых страниц с маппером, в которые мы могли положить свои таблицы.

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

Но я знал, что рано или поздно мы докатимся и до этой дряни.

• Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
• Попросил превратить это в архитектурный план.
• Отревьюил, поправил тупые ошибки.
• Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
• Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
• Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
• Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
• Написал манифесты для Kubernetes и Docker Compose для локального запуска.
• Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

Когда-то я пытался завести ютуб канал и стать знаменитым, но оказалось что для этого нужна харизма, чувство юмора и четкая дикция, а не то что у меня.

Но все же мне удалось нафармить 3,5к подписчиков мучительными душными видео, которые совершенно не понятно зачем терпели мои зрители

Теперь, я принял себя и нашел более подходящую площадку для своей духоты, поэтому представляю вашему вниманию несколько графиков про видео хостинг ютуб, который я парсил в течение 4 месяцев

Новый перевод от команды Spring АйО расскажет вам о том, почему так вредно отвлекать разработчиков от их работы и как избежать большого убытка для компании из-за прерывания рабочего процесса сотрудников.

Хотелось бы прокомментировать публикацию Ильи Кабанова в Медузе по поводу новых разработок в алгоритмах хеширования: "Optimal Bounds for Open Addressing Without Reordering" (Farach-Colton, Krapivin, and Kuszmaul, 2025) и последующую "The Bathroom Model: A Realistic Approach to Hash Table Algorithm Optimization" (Wang, 2025). И особенно кликбейтное: "в перспективе метод Крапивина и его коллег может ускорить многие процессы в интернете."

Я около 7 лет очень плотно занимался темой хеш-таблиц и написал много их вариантов: Koloboke, SmoothieMap, memory-mapped вариации.

Я потерял к теме интерес с выходом гугловской SwissTable (2018), и ее фейсбучного варианта F14, которые основаны на SIMD. Они проверяют загруженность ячеек и совпадения "тега" элемента сразу блоками по 8 соседних слотов. Поэтому на любых разумных загрузках таблиц (до 90%) - "цепочка проверки" очень редко превышает 1 (то есть, одну проверку 8-элементного блока).

В этих SIMD-based алгоритмах, ухищрения и теоретические по поводу "алгоритма шагания" просто не играют никакой роли -- алгоритм шагания можно сказать отсутствует, потому что если можно вставить элемент внутри 8-элементного блока, то это и стоит сделать.

Именно эти разработки, а не Крут и не статья Yao, которую "опровергли" новые работы, стали "практическим концом теории" хеш-таблиц, на мой взгляд.

SwissTable стали стандартным алгоритмом хеш-таблиц в Расте, и, буквально в этом месяце, в Golang 1.24.

В заключение, отвечая Илье Кабанову: к "ускорению интернета" эти теоретические алгоритмы не приведут :)

Предыдущий проект о перепрограммировании заводского термостата вызвал достаточно большой интерес у сообщества (ссылка будет в конце статьи). И вот поступило предложение проверить, можно ли таким же образом избавиться от спама на датчике CO2.

ML‑модели применяются в сервисах Яндекса уже много лет, мы накопили большой опыт в их обучении. Статьи об этом коллеги регулярно публикуют, в том числе на Хабре. Но сегодня хочу обсудить другую не менее важную задачу — ускорение инференса (процесса работы на конечном устройстве) моделей. Скорость зависит от разных условий, главным образом от архитектуры и железа, но есть множество интересных способов повлиять на неё. Особенно актуальна проблема тяжёлого инференса при использовании больших языковых моделей (LLM) — на то они и large!

Для команды YandexGPT, в которой я и тружусь вместе со своими коллегами, тема инференса LLM находится в разряде вечных вопросов. С предыдущей статьи прошёл уже почти год, опыта у нас стало больше — получилось протестировать новые подходы, которыми и хочется поделиться сегодня.

Всё вроде должно быть просто

Сцена этого конкретного преступления может показаться неправдоподобной: аномалия производительности, возникающая в простейшем машинном коде. На самом деле, его даже можно назвать чрезмерно упрощённым, ведь он не выполняет никакой полезной работы. Он нужен лишь для того, чтобы продемонстрировать поведение оборудования в образовательных целях.

Но по моему опыту, чрезвычайно простой машинный код — это, на самом деле, один из самых частых источников чего-то странного. Так как мы передаём CPU ограниченное количество крайне специфичных команд без остальной части когда, то упираемся в границы того, что проектировщики оборудования ожидали встретить в реальном мире. В этой ситуации вы с большей вероятностью сможете пощупать границы микроархитектуры, чем в более стандартном сценарии.