Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy. Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy, который, возможно, станет способом реализации сверхбыстрого Python.

Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

Предыстория

Моя команда занимается разработкой медицинского ПО: приложения для передачи направлений пациентов в системе здравоохранения Австралии.

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

Система электронных направлений удобна для всех. Когда врач создаёт новое направление, мы автоматически извлекаем информацию из PMS (patient management software, системы управления пациентами, которой владеет наша компания) с данными пациента, этнической принадлежностью, индексом массы тела, принимаемыми лекарствами, медицинской историей и всем остальным, что необходимо для направления. В бланке направления есть валидируемая «форма специализации» с полями, относящимися к конкретной услуге, для которой выписывается направление.

Благодаря этому в направлении содержится вся необходимая информация. И, разумеется, в форме также есть большое текстовое поле для свободного текста (referral letter), в котором терапевт может объяснить, почему он решил выписать пациенту направление.

При отправке направления данные передаются в цифровом виде. Они преобразуются в один из нескольких форматов в зависимости от получателя. Некоторые получатели используют для приёма направлений наш продукт Referral Manager; в этом случае нам не нужно ничего преобразовывать, они просто получают доступ в веб-интерфейсе к тем данным, которые хранятся в базе данных. Однако обычно данные преобразуются в HL7 (старый текстовый формат файлов медицинской информации), CDA (XML-документ с отдельной таблицей стилей) или просто в PDF с человекочитаемой информацией. Благодаря этому данные совместимы со множеством различных электронных систем других компаний.

Также выполняется сохранение PDF-копии направления в PMS врача для ведения его собственной картотеки. Это позволяет ему просматривать всю историю пациента в PMS без необходимости поиска документов в куче приложений разных разработчиков.

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

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

Посмотрев два видео PewDiePie, в которых он узнал об установке Arch (задача эта считается довольно сложной даже для любителей Linux) и о создании трёх проектов (камеры для собаки, устройства для получения информации о погоде/напоминания о питьевом режиме/медитаций и кто знает, что будет ещё) из опенсорсных напечатанных на 3D-принтере деталей, я стал размышлять о самостоятельном проектировании, своём хостинге и технологической независимости. Эти темы уже давно очень близки мне.

Когда меня спрашивают, как начать писать блог или как получить работу, я всегда говорю, что сначала нужно купить домен. Во-вторых, нужно хостить собственный веб-сайт блога, если вы обладаете техническими навыками (впрочем, сегодня это уже несложно). Я говорю так потому, что всё накапливается со временем. Разумеется, вы можете начать с готового блога и не принадлежащего вам URL, но если вы хотите заниматься этим на долгосрочной основе, то что будет дальше? Я видел, как многие люди скачут с WordPress на Medium, потом на Substack, потом на Ghost. Иногда они не выполняют миграцию своих постов, на написание которых было потрачено много времени, а просто создают новые.

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

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

Слишком многие люди преступно пренебрегают резервным копированием. Из-за заблуждений в этой области теряется слишком много данных; это связано и с ошибочными техниками наподобие «бэкапов Шрёдингера» (то есть никогда не тестируемых, а значит, валидных и невалидных одновременно), и с концептуальными заблуждениями о том, что такое бэкапы и как они работают (RAID — это не бэкап!).

Сегодня о резервном копировании зачастую думают по остаточному принципу. Многие полностью полагаются на «облако», не задаваясь даже вопросами о том, каким образом защищаются их данные. Большинство упускает из виду, что даже крупные поставщики облачных услуг работают по модели коллективной ответственности. В условиях пользования они часто подчёркивают, что, несмотря на обеспечение ими безопасности инфраструктуры, в конечном итоге ответственность за защиту и резервное копирование данных лежит на пользователях. Когда хранишь всё «в облаке», в кластерах, которыми владеют другие компании, или в распределённых системах Kubernetes, бэкапы часто кажутся ненужными. Иногда я спрашиваю коллег или разработчиков о том, как они реализуют резервное копирование, и они смотрят на меня так, как будто я говорю на каком-то древнем забытом языке. Они попросту никогда об этом не задумывались. Но данные не эфемерны, их необходимо защищать любыми возможными способами.

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

Когда я был зимой в Японии, одним из самых удивительных для меня явлений этой страны оказалась невероятная система общественного транспорта. Она не только была эффективной и надёжной, но и турникеты на станциях работали подозрительно быстро. Турникеты лондонской подземки не сравнятся с ними по скорости работы с Google Pay и другими моими бесконтактными картами. В чём же причина? Я решил изучить, почему японская система транспортных карт (IC-карт) так уникальна по сравнению с западными, и в процессе этого исследования узнал пару любопытных фактов.

Пару месяцев назад я купил Nanoleaf Pegboard Desk Dock — последнее слово в технологиях USB-хабов с RGB-светодиодами и крючками для устройств. К сожалению, это чудо инженерной мысли поддерживает только гейминговые операционные системы — Windows и macOS, поэтому возникла необходимость в драйвере для Linux.

В своих постах я уже настраивал Windows VM с пробросом USB и пытался выполнить реверс-инжиниринг официальных драйверов. При этом я задумался, а нельзя ли написать производителю и попросить у него спецификации или документацию его протокола. К моему удивлению, техподдержка Nanoleaf ответила мне всего через четыре часа, предоставив полное описание протокола, используемого Desk Dock, а также полосами RGB-светодиодов. Документация по большей мере подтвердила то, что я обнаружил самостоятельно, но также я нашёл в ней пару других мелких подробностей (например, управление питанием и яркостью), которые были мне неизвестны.

Сегодня мы попробуем написать драйвер на основании протокола (который я изучил реверс-инжинирингом), параллельно сверяясь с официальной документацией. Однако здесь есть одна небольшая проблема: раньше я ни разу не писал драйверов для устройств под Linux, а с USB-устройствами взаимодействовал только как пользователь.

Мой веб-сайт — это путешествие по волнам памяти. Я не хочу сказать, что нужно прекратить современную веб-разработку. На моём веб-сайте используются технологии, которые в обсуждаемые на нём времена были ещё недоступны. Он работает на мобильных (протестировано в Firefox для Android), отсутствует только фоновое изображение.

Свой первый веб-сайт я создал где-то в начале 2000-х, и как и большинство веб-сайтов того времени, он был очень простым. Это неудивительно, учитывая то, что большинство (включая и меня) писали такие веб-сайты в Блокноте, что накладывало ограничения на сложность. Можно было выбрать или Блокнот, или какой-то из WYSIWYG-редакторов, которые привязывали к себе тем, что сгенерированный ими HTML было бы совершенно невозможно поддерживать без них, а если вносить изменения вручную, то это вполне могло поломать всё в редакторе.

Тогда не было iPhone, почти не было SEO, а JavaScript, как и CSS, использовать было совсем необязательно.

Цветопередача первых ЖК-экранов была плохой, поэтому лучше было выбирать цветовую схему с высокой контрастностью.

Оптимальным разрешением было 1024×768 (или 1280×1024, если вы могли себе это позволить), однако стоило и обеспечить работоспособность размеров окна и панелей в 800×600. Вам же не нужно, чтобы контент выходил за левый или правый край экрана?

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

В этом посте я расскажу, как на помощь мне пришли Linux, WireGuard и Hetzner, благодаря которым я смог получить доступ ко всему Интернету через одно лишь соединение IPv6.

Мне очень нравится знаменитая цитата Ричарда Фейнмана:

«То, что я не могу создать, я не понимаю»

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

Сегодня, в 2025 году, красота и ремесло написания ПО подвергаются разрушению. ИИ угрожает тем, что заменит нас (или, по крайней мере, заберёт все самые приятные аспекты нашего ремесла), а разработка ПО становится всё более стандартизированной, выверенной, упакованной и индустриализированной. Разработке программного обеспечения нужно больше простых удовольствий. Я выяснил, что создание хобби-программ — отличный способ снова напомнить себе, почему вообще я начал работать с компьютерами.

В последнее время я много работал с TPU и мне было интересно наблюдать такие сильные различия в их философии дизайна по сравнению с GPU.

Главная сильная сторона TPU — это их масштабируемость. Она достигается благодаря и аппаратной (энергоэффективности и модульности), и программной стороне (компилятору XLA).

Общая информация

Если вкратце, то TPU — это ASIC компании Google, делающий упор на два фактора: огромную производительность перемножения матриц + энергоэффективность.

Их история началась в Google в 2006 году, когда компания впервые начала размышлять о том, что же ей стоит реализовывать: GPU, FPGA или специализированные ASIC. В те времена было лишь несколько областей применения, в которых требовалось специализированное оборудование, поэтому было решено, что потребности компании можно удовлетворить при помощи незадействованных вычислительных ресурсов (compute) CPU её крупных датацентров. Но в 2013 году ситуация изменилась: функция голосового поиска Google начала использовать нейросети, и по расчётам для её реализации потребовалось бы гораздо больше compute.

Перенесёмся в настоящее: сегодня TPU лежат в основе большинства ИИ-сервисов Google. Разумеется, сюда включены обучение и инференс Gemini и Veo, а также развёртывание моделей рекомендаций (DLRM).

Давайте начнём разбирать внутренности TPU с самого нижнего уровня.

Недавно меня заинтересовала такая задача: как лучше всего определить, что в строке есть гласная?

Казалось бы, тривиальный вопрос, правда?

Но, начав разбираться, я осознал, что задача гораздо глубже. Я бросил себе вызов: придумать как можно больше способов обнаружения гласной. Я даже попросил присоединиться ко мне нескольких друзей. Какой способ самый быстрый? Каким никогда не стоит пользоваться? Какой самый умный? Какой самый удобочитаемый?

В этом посте я рассмотрю 11 способов обнаружения гласных, алгоритмический анализ, дизассемблирование байт-кода Python, реализацию CPython и даже исследую опкоды скомпилированного регулярного выражения. Поехали!

В рамках этого проекта я сгенерировал около 30 миллиардов файлов случайных данных по 4 КБ. Из этих файлов на основании эвристик из полной коллекции файлов ROM Atari было выбрано примерно 10 тысяч. Затем система классификатора просканировала их при помощи эмулятора Atari 2600, чтобы проверить, окажется ли какой-то из этих случайных файлов игрой для Atari. Этот проект отвечает на вопросы, которые никто не задавал, он никому не нужен и представляет собой огромную пустую трату ресурсов. Что, если засунуть в GPU миллиард обезьян и заставить их написать игру для Atari 2600?

Благодаря прогрессу GPU, ИИ и машинного обучения сегодня мы можем (очень быстро) написать на Python скрипт, который дампит мусор в ROM по 4 КБ и спрашивает: «похоже ли это на игру?». Проект был создан не из ностальгии, моей первой консолью была NES. Я вознамерился исследовать нечто невообразимо обширное и посмотреть, найдётся ли там что-нибудь странное.

Как работает старый индикатор воздушной скорости? CuriousMarc приобрёл такое устройство для своего проекта, но при нём не было документации, поэтому я выполнил его реверс-инжиниринг. Этот индикатор использовался в панелях кокпитов таких самолётов бизнес-класса, как Gulfstream G-III, Cessna Citation и Bombardier Challenger CL600. Судя по датам на транзисторах, он был изготовлен примерно в 1977 году.

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

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

• Когда может потребоваться резервуарное сэмплирование.

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

• Простой способ реализации резервуарного сэмплирования на случай, если вам оно понадобится.