🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 134 (from laksa102)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa134.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://habr.com/ru/companies/exness/articles/542106/\')), getAhrefsUnparsedNoserviceFromURL(\'https://habr.com/ru/companies/exness/articles/542106/\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/habr.com\/ru\/companies\/exness\/articles\/542106\/","crawl_time":1775476588,"first_indexed_time":0,"http_code":200,"src_unparsed":"com,habr!\/ru\/companies\/exness\/articles\/542106\/ s443","src_root_hash":"14843476518697139734","history_drop_reason":null,"meta_title":"Как скомпилировать Python \/ Хабр","meta_descriptions":["Привет, Хабр! Я хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов,..."],"attrs_boilerpipe_text":"Привет, Хабр!\nЯ хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь\nPyInstaller\n-ом, а про честную\nAhead-of-time\nкомпиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат.\nОбъясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: \nAhead-of-time (AOT)\n, когда весь код компилируется до запуска программы и\nJust in time compiler (JIT)\n, когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором.\nЕсли сгруппировать популярные языки программирования по типу компиляции, то получим следующий список:\nAhead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart;\nJust in time compiler: Lua, С#, Groovy, Dart.\nВ python из коробки нет JIT компилятора, но отдельные библиотеки, предоставляющие такую возможность, существуют давно\nСмотря на эту таблицу, можно заметить определенную закономерность:\nстатически типизированные языки находятся в обеих строках\n. Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin\/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично. \nПри запуске виртуальная машина сначала накапливает информацию о типах переменных, затем после накопления статистики, запускается компиляция наиболее нагруженных частей программы. Виртуальная машина отслеживает типы аргументов и переключает выполнение программы между уже скомпилированными и не скомпилированными участками кода в зависимости от текущих значений переменных.\nПри использовании JIT компиляции типы не очень то и нужны, ведь информация о типах собирается во время работы программы. Поэтому все популярные динамически типизированные языки программирования распространяются именно с JIT компилятором.\nНо как быть с AOT компиляцией кода, в котором нет типов?\nМеня очень заинтересовал этот вопрос, и я полез разбираться.\nИтак, вернемся к утилите, о которой говорилось в начале статьи. Речь про\nmypy\n- наиболее популярный синтаксический анализатор python-кода.\nС апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в\nблоге\nпроекта. А для компиляции используется еще одна утилита от тех же авторов —\nmypyc\n. Погуглив немного, я нашел достаточно большую статью “\nПуть к проверке типов 4 миллионов строк Python-кода\n” про становление и развитие mypy (на Хабре доступен перевод:\nчасть 1\n,\nчасть 2\n,\nчасть 3\n). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на\ngo\nили на\ncython\n. В результате проект пошел по третьему пути —\nнаписание своего AOT python-компилятора\n.\nДело в том, что для правильной работы\nmypy\nи так необходимо построить то же синтаксическое дерево, что и интерпретатору во время исполнения кода. То есть\nmypy уже “понимает” python\n, но использует эту информацию только для статистического анализа, а вот\nmypyc\nможет преобразовывать эту информацию в полноценный бинарный код.\nДумаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а\nmypy\nкак раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что\nmypyc\nможет компилировать и неаннотированный код\n!\nФункция bubble_sort\nДля примера рассмотрим функцию сортировки “пузырьком”. Файл\nlib.py:\ndef bubble_sort(data):\n   n = len(data)\n   for i in range(n - 1):\n       for j in range(n - i - 1):\n           if data[j] > data[j + 1]:\n               buff = data[j]\n               data[j] = data[j + 1]\n               data[j + 1] = buff\n   return data\nУ типов нет аннотаций, но это не мешает\nmypyc\nее скомпилировать. Чтобы запустить компиляцию, нужно установить\nmypyc\n. Он не распространяется отдельным пакетом, но если у вас установлен\nmypy\n, то и\nmypyc\nуже присутствует в системе! Запускаем\nmypyc\n, следующей командой:\n> mypyc lib.py\nПосле запуска в проекте будут созданы следующие директории:\n.mypy_cache\n  —\nmypy\nкэш, mypyc неявно запускает mypy для разбора программы и получения AST;\nbuild\n— артефакты сборки;\nlib.cpython-38-x86_64-linux-gnu.so\n— собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension.\nCPython Extension\n— встроенный в\nCPython\nмеханизм взаимодействия с кодом, написанным на С\/C++. По сути это динамическая библиотека, которую\nCPython\nумеет загружать при импорте нашего модуля\nlib\n. Через данный механизм осуществляется взаимодействие с модулями, написанными на python.\nКомпиляция состоит из двух фаз:\nКомпиляция python кода в код С;\nКомпиляция С в бинарный\n.so\nфайл, для этого\nmypyc\nсам запускает gcc (\ngcc\nи\npython-dev\nтакже должен быть установлены).\nФайл\nlib.cpython-38-x86_64-linux-gnu.so\nимеет преимущество перед\nlib.py\nпри импорте на соответствующей платформе, и исполняться теперь будет именно он.\nНу и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл\nmain.py\nс кодом запуска сортировки:\nimport lib\n\n\ndata = lib.bubble_sort(list(range(5000, 0, -1)))\n\nassert data == list(range(1, 5001))\nПолучим примерно следующие результаты:\nДо\nПосле\nreal 5.68\nuser 5.60\nsys 0.01\nreal 2.78\nuser 2.73\nsys 0.01\nОжидаемо скомпилированный код\nоказался быстрее (~ в 2 раза)\n, что неплохо, так как для такого результата нам потребовалось запустить лишь одну команду. Хотя от скомпилированного кода привычно ожидаешь большего.\nЧтобы ответить на вопрос\n“как компилируется динамически типизированный код”\n, придется заглянуть в представление этой функции на С. Но разобрать ее будет достаточно сложно, поэтому давайте попробуем разобраться с примером попроще.  \nФункция sum(a, b)\nСкомпилируем функцию суммы от двух переменных:\ndef sum(a, b):\n  return a + b\nПеред запуском компиляции я ожидал увидеть примерно следующий код на С:\nint sum(int a, int b) {\n   return a + b;\n}\nОднако результат оказался cущественно иным (\nкод немного упрощен\n):\nPyObject *CPyDef_sum(PyObject *cpy_r_a, PyObject *cpy_r_b){\n    return PyNumber_Add(cpy_r_a, cpy_r_b);\n}\nРассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса\nPyObject\n, по сути это внутренние\nCPython\nструктуры. Далее\nкомпилятор должен сложить эти объекты\n, но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc? \nКак оказалось, все очень просто: он просит\nCPython\nсамостоятельно сложить эти аргументы. Функция\nPyNumber_Add\n— это внутренняя функция\nСPython\n, которая доступна из расширения, ведь\nСPython\nотлично умеет складывать свои объекты\n.\nВзаимодействие CPython c Extension можно изобразить следующим диалогом:\n — А посчитай-ка мне функцию sum для A, B;\n — Хорошо, но скажи сначала, сколько будет A + B;\n — Будет С;\n — Хорошо, тогда держи ответ - С.\nВот такой нехитрый прием используется при компиляции динамического кода:\nкомпилируем все, что можем, а все остальное отдаем интерпретатору\n. \nКонечно, данный пример выглядит гротескно, но даже\nнесмотря на такую неэффективность\n, mypyc позволяет добиться существенного\nприроста производительности\n, как в примере с сортировкой.\nФункция sum(a: int, b: int)\nИтак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во\nмножественном взаимодействии\nCPython - Extension\n. Но как это побороть? \nДля повышения эффективности, нужно, чтобы расширение, получив управление, могло как можно\nдольше оставлять его у себя\nбез обращения к\nCPython\n. Если бы у mypyc была информация о типах переменных, то он бы мог самостоятельно произвести сложение без возврата управления. Но вывести типы самостоятельно mypyc не может, он даже\nне контролирует код\n, из которого осуществляется вызов функции sum. Соответственно, ему нужно помочь, проставив аннотации вручную. Давайте посмотрим, как поменяется результирующая С-функция, если добавить аннотацию типов:\ndef sum(a: int, b: int):\n  return a + b\nСкомпилированный результат на C (\nнемного очищенный\n):\nPyObject *CPyDef_sum(CPyTagged cpy_r_a, CPyTagged cpy_r_b) {\n   CPyTagged cpy_r_r0;\n   PyObject *cpy_r_r1;\n   cpy_r_r0 = CPyTagged_Add(cpy_r_a, cpy_r_b);\n   cpy_r_r1 = CPyTagged_StealAsObject(cpy_r_r0);\n\n   return cpy_r_r1;\n}\nГлавное, что можно заметить:\nфункция существенно поменялась\n, а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось. \nТеперь\nCPyDef_sum\nполучает на вход не указатели на\nPyObject\n, а структуры\nCPyTagged\n. Это все еще не\nint\n, но уже и не часть\nCPython\n, а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция\nsum\nработает только с\nint\nи обойти аннотацию не получится.\nДалее происходит вызов\nCPyTaggetAdd\nвместо\nPyNumber_Add\n. Это уже\nвнутренняя функция mypyc\n. Если заглянуть в\nкод\nCPyTaggetAdd\n, то можно понять, что там происходит проверка диапазонов значений\na\nи\nb\n, и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение:\nif (likely(CPyTagged_CheckShort(left) && CPyTagged_CheckShort(right))) {\n    CPyTagged sum = left + right;\n\n    if (likely(!CPyTagged_IsAddOverflow(sum, left, right))) {\n        return sum;\n    }\n}\nТаким образом, наш диалог\nCPython - Extension\nпревращается\nиз абсурдного в нормальный\n:\n — А посчитай-ка мне функцию sum для A, B;\n — Хорошо, тогда держи ответ С.\nФункция bubble_sort(data: List[int])\nНастало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для\ndata\n:\ndef bubble_sort(data: List[int]):\n    …\nСкомпилируем результат и замерим время сортировки:\nБез компиляции\nС компиляцией, без аннотации типов\nС компиляцией и аннотацией типов\nreal 5.68\nuser 5.60\nsys 0.01\nreal 2.78\nuser 2.73\nsys 0.01\nreal 1.32\nuser 1.30\nsys 0.01\nИтак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального!\nПара слов о mypyc\nЕсли вы уже бросились компилировать ваши пакеты, то стоит задержаться на пару минут, чтобы дочитать этот абзац до конца. Главным недостатком\nmypyc\nпока остается стабильность: он все еще в альфе, точнее, сейчас это вообще не самостоятельный проект, а часть\nmypy\n. Собственно он и создавался специально под задачу увеличения производительности\nmypy\nи для этой цели он уже\nболее года как стабилен\n. Но как общее решение по компиляции любого python-кода, он еще сыроват, о чем авторы предупреждают на странице проекта.\nТакже существуют принципиальные ограничения, накладываемые на компилируемый код или на код, взаимодействующий со скомпилированным:\nПринудительная проверка типов в рантайме;\nВ компилируемом коде запрещается monkey patching;\nMypy хранит классы в С структурах для увеличения скорости доступа к атрибутам, но это приводит к проблемам совместимости.\nЭти ограничения носят\nпринципиальный\nхарактер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код\ngcc\nотказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока результат таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно\n20 % модулей\n, зато каких либо проблем при работе с уже скомпилированными модулями я не заметил.\nТем не менее, большая часть улучшений в их\nRoadmap\nзакрыта, и проект готовится к публичному\nрелизу\n.\nNuitka\nУже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы\nNuitka\nсильно напоминает описанный выше. Разница заключается в том, что\nNuitka\nкомпилирует Python модуль в С++ код, который также собирается в\nСPython Extension\n. Дополнительно существует возможность собрать весь проект в\nодин исполняемый файл\n, тогда уже сам\nCPython\nподключается к проекту как динамическая библиотека\nlibpython\n.\nNuitka\nпока не учитывает аннотацию типов, поэтому результирующий код и скорость работы не зависят от наличия аннотаций. Полученная же скорость в моем тесте\nсоответствует результату mypy\nна не аннотированном коде.\nЗавершение\nНедавно один мой коллега высказал мнение, что\nmypy\nсильно усложняет\nему жизнь: из текста ошибок невозможно понять, “чего он от меня хочет”, а анализатор из\nPyCharm\nнемного лучше. Теперь я понимаю, что он недооценивает\nmypy\n. Так как он\nнамного большее, чем просто синтаксический анализатор\n. По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание\nmypy\nв пайплайн проекта — инвестиция не только в поиск ошибок, но и\nбудущий перфоманс\nприложения. Мне очень понравилось, что взаимодействие с\nCPython\nосуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне\nнаиболее безопасным\n(учитывая, что\nmypyc\nдо сих пор в альфе). Конечно, использовать ли\nmypyc\nна продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить\nmypyc\n, тем более, что сделать это просто, если вы уже используете mypy.\nP.S.\nНадеюсь, вам было интересно узнать о новом способе повышения производительности python, а также глубже разобраться в механизме компиляции динамически типизированного кода. Если тема окажется интересной, то в следующей статье планирую больше рассказать про\nmypyc\n, его ограничения и частые ошибки,  а также, как их можно обойти.\nUPD\nВ комментариях подсказали, об еще одном python компиляторе -\nCython\n, оказывается теперь он умеет компилировать python код напрямую (минуя ручную фазу преобразования кода в\ncython\n-код). Судя по замерам cython пока\nне учитыват\nаннотацию типов, но время выполнения (\nreal 1.82\n) оказалось посередине между результатом mypyc на аннотированном и не аннотированном кода. Но возможно ее добавят в будущем.","attrs_markdown":"[Все потоки](https:\/\/habr.com\/ru\/articles\/)\n\n[Войти](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr\/?back=\/ru\/companies\/exness\/articles\/542106\/&hl=ru)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/company\/0d2\/a3c\/808\/0d2a3c80845887b559d3602a5e085d5f.png)](https:\/\/habr.com\/ru\/companies\/exness\/profile\/)\n\n[Exness](https:\/\/habr.com\/ru\/companies\/exness\/profile\/)\n\nTech professionals. Good people\n\n182\n\nПодписчики\n\nПодписаться\n\n[![](https:\/\/habrastorage.org\/r\/w48\/getpro\/habr\/avatars\/caa\/9c9\/cad\/caa9c9cad82105a9a46f4848dbe4aa86.jpg)](https:\/\/habr.com\/ru\/users\/zueve\/)\n\n[zueve](https:\/\/habr.com\/ru\/users\/zueve\/)\n\n12 фев 2021 в 12:41\n# Как скомпилировать Python\n10 мин\n\n68K\n\n[Блог компании Exness](https:\/\/habr.com\/ru\/companies\/exness\/articles\/)[Высоконагруженные системы \\*](https:\/\/habr.com\/ru\/hubs\/hi\/) [Python \\*](https:\/\/habr.com\/ru\/hubs\/python\/) [Программирование \\*](https:\/\/habr.com\/ru\/hubs\/programming\/) [Компиляторы \\*](https:\/\/habr.com\/ru\/hubs\/compilers\/)\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/1e9\/1ba\/b49\/1e91bab4996a417303df57b5b644da5b.jpg)\n\nПривет, Хабр\\!\n\nЯ хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь *PyInstaller*\\-ом, а про честную *Ahead-of-time* компиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат.\n\nОбъясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: *Ahead-of-time (AOT)*, когда весь код компилируется до запуска программы и *Just in time compiler (JIT)*, когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором.\n\nЕсли сгруппировать популярные языки программирования по типу компиляции, то получим следующий список:\n\n- Ahead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart;\n- Just in time compiler: Lua, С\\#, Groovy, Dart.\n\n*В python из коробки нет JIT компилятора, но отдельные библиотеки, предоставляющие такую возможность, существуют давно*\n\nСмотря на эту таблицу, можно заметить определенную закономерность: **статически типизированные языки находятся в обеих строках**. Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin\/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично.\n\n> *При запуске виртуальная машина сначала накапливает информацию о типах переменных, затем после накопления статистики, запускается компиляция наиболее нагруженных частей программы. Виртуальная машина отслеживает типы аргументов и переключает выполнение программы между уже скомпилированными и не скомпилированными участками кода в зависимости от текущих значений переменных.*\n\nПри использовании JIT компиляции типы не очень то и нужны, ведь информация о типах собирается во время работы программы. Поэтому все популярные динамически типизированные языки программирования распространяются именно с JIT компилятором. **Но как быть с AOT компиляцией кода, в котором нет типов?** Меня очень заинтересовал этот вопрос, и я полез разбираться.\n\nИтак, вернемся к утилите, о которой говорилось в начале статьи. Речь про [mypy](http:\/\/mypy-lang.org\/) - наиболее популярный синтаксический анализатор python-кода.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/6f3\/fb7\/42d\/6f3fb742d999b54bb8d8bfc3daf1c923)\n\nС апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в [блоге](https:\/\/mypy-lang.blogspot.com\/2019\/04\/mypy-0700-released-up-to-4x-faster.html) проекта. А для компиляции используется еще одна утилита от тех же авторов — *mypyc*. Погуглив немного, я нашел достаточно большую статью “[Путь к проверке типов 4 миллионов строк Python-кода](https:\/\/dropbox.tech\/application\/our-journey-to-type-checking-4-million-lines-of-python)” про становление и развитие mypy (на Хабре доступен перевод: [часть 1](https:\/\/habr.com\/ru\/company\/ruvds\/blog\/468233\/), [часть 2](https:\/\/habr.com\/ru\/company\/ruvds\/blog\/468235\/), [часть 3](https:\/\/habr.com\/ru\/company\/ruvds\/blog\/468237\/)). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на *go* или на *cython*. В результате проект пошел по третьему пути — **написание своего AOT python-компилятора**.\n\nДело в том, что для правильной работы *mypy* и так необходимо построить то же синтаксическое дерево, что и интерпретатору во время исполнения кода. То есть **mypy уже “понимает” python**, но использует эту информацию только для статистического анализа, а вот *mypyc* может преобразовывать эту информацию в полноценный бинарный код.\n\nДумаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а *mypy* как раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что *mypyc* **может компилировать и неаннотированный код**\\!\n\n## Функция bubble\\_sort\nДля примера рассмотрим функцию сортировки “пузырьком”. Файл *lib.py:*\n```\n\n```\nУ типов нет аннотаций, но это не мешает *mypyc* ее скомпилировать. Чтобы запустить компиляцию, нужно установить *mypyc*. Он не распространяется отдельным пакетом, но если у вас установлен *mypy*, то и *mypyc* уже присутствует в системе! Запускаем *mypyc*, следующей командой:\n```\n> mypyc lib.py\n```\nПосле запуска в проекте будут созданы следующие директории:\n\n- `.mypy_cache` — *mypy* кэш, mypyc неявно запускает mypy для разбора программы и получения AST;\n- `build` — артефакты сборки;\n- `lib.cpython-38-x86_64-linux-gnu.so` — собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension.\n\n> *CPython Extension* — встроенный в *CPython* механизм взаимодействия с кодом, написанным на С\/C++. По сути это динамическая библиотека, которую *CPython* умеет загружать при импорте нашего модуля *lib*. Через данный механизм осуществляется взаимодействие с модулями, написанными на python.\n\nКомпиляция состоит из двух фаз:\n\n1. Компиляция python кода в код С;\n2. Компиляция С в бинарный *.so* файл, для этого *mypyc* сам запускает gcc (*gcc* и *python-dev* также должен быть установлены).\n\nФайл `lib.cpython-38-x86_64-linux-gnu.so` имеет преимущество перед *lib.py* при импорте на соответствующей платформе, и исполняться теперь будет именно он.\n\nНу и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл *main.py* с кодом запуска сортировки:\n```\n\n```\nПолучим примерно следующие результаты:\n\n|   |   |\n|---|---|\n| До | После |\n| real 5.68user 5.60sys 0.01 | real 2.78user 2.73sys 0.01 |\n\nОжидаемо скомпилированный код **оказался быстрее (~ в 2 раза)**, что неплохо, так как для такого результата нам потребовалось запустить лишь одну команду. Хотя от скомпилированного кода привычно ожидаешь большего.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/5a3\/bbe\/285\/5a3bbe28516bfd798ed394c0e46afaf7)\n\nЧтобы ответить на вопрос *“как компилируется динамически типизированный код”*, придется заглянуть в представление этой функции на С. Но разобрать ее будет достаточно сложно, поэтому давайте попробуем разобраться с примером попроще.\n\n## Функция sum(a, b)\nСкомпилируем функцию суммы от двух переменных:\n```\n\n```\nПеред запуском компиляции я ожидал увидеть примерно следующий код на С:\n```\n\n```\nОднако результат оказался cущественно иным (**код немного упрощен**):\n```\n\n```\nРассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса *PyObject*, по сути это внутренние *CPython* структуры. Далее **компилятор должен сложить эти объекты**, но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc?\n\nКак оказалось, все очень просто: он просит *CPython* самостоятельно сложить эти аргументы. Функция *PyNumber\\_Add* — это внутренняя функция *СPython*, которая доступна из расширения, ведь ***СPython* отлично умеет складывать свои объекты**.\n\nВзаимодействие CPython c Extension можно изобразить следующим диалогом:\n\n> — А посчитай-ка мне функцию sum для A, B;\n> \n> — Хорошо, но скажи сначала, сколько будет A + B;\n> \n> — Будет С;\n> \n> — Хорошо, тогда держи ответ - С.\n\nВот такой нехитрый прием используется при компиляции динамического кода: **компилируем все, что можем, а все остальное отдаем интерпретатору**.\n\nКонечно, данный пример выглядит гротескно, но даже **несмотря на такую неэффективность**, mypyc позволяет добиться существенного **прироста производительности**, как в примере с сортировкой.\n\n## Функция sum(a: int, b: int)\nИтак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во **множественном взаимодействии** *CPython - Extension*. Но как это побороть?\n\nДля повышения эффективности, нужно, чтобы расширение, получив управление, могло как можно **дольше оставлять его у себя** без обращения к *CPython*. Если бы у mypyc была информация о типах переменных, то он бы мог самостоятельно произвести сложение без возврата управления. Но вывести типы самостоятельно mypyc не может, он даже **не контролирует код**, из которого осуществляется вызов функции sum. Соответственно, ему нужно помочь, проставив аннотации вручную. Давайте посмотрим, как поменяется результирующая С-функция, если добавить аннотацию типов:\n```\n\n```\nСкомпилированный результат на C (*немного очищенный*):\n```\n\n```\nГлавное, что можно заметить: **функция существенно поменялась**, а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось.\n\nТеперь *CPyDef\\_sum* получает на вход не указатели на *PyObject*, а структуры *CPyTagged*. Это все еще не *int*, но уже и не часть *CPython*, а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция *sum* работает только с *int* и обойти аннотацию не получится.\n\nДалее происходит вызов *CPyTaggetAdd* вместо *PyNumber\\_Add*. Это уже **внутренняя функция mypyc**. Если заглянуть в [код](https:\/\/github.com\/python\/mypy\/blob\/5e20a26b922e2f5b71425ea7f57d2b4cba5a9324\/mypyc\/lib-rt\/int_ops.c#L136) *CPyTaggetAdd*, то можно понять, что там происходит проверка диапазонов значений *a* и *b*, и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение:\n```\n\n```\nТаким образом, наш диалог *CPython - Extension* превращается **из абсурдного в нормальный**:\n\n> — А посчитай-ка мне функцию sum для A, B;\n> \n> — Хорошо, тогда держи ответ С.\n## Функция bubble\\_sort(data: List\\[int\\])\nНастало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для *data*:\n```\n\n```\nСкомпилируем результат и замерим время сортировки:\n\n|   |   |   |\n|---|---|---|\n| Без компиляции | С компиляцией, без аннотации типов | С компиляцией и аннотацией типов |\n| real 5.68user 5.60sys 0.01 | real 2.78user 2.73sys 0.01 | real 1.32user 1.30sys 0.01 |\n\nИтак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального\\!\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/1a6\/2b9\/4e6\/1a62b94e684142f6991bf6637ef9ed81)\n\n## Пара слов о mypyc\nЕсли вы уже бросились компилировать ваши пакеты, то стоит задержаться на пару минут, чтобы дочитать этот абзац до конца. Главным недостатком *mypyc* пока остается стабильность: он все еще в альфе, точнее, сейчас это вообще не самостоятельный проект, а часть *mypy*. Собственно он и создавался специально под задачу увеличения производительности *mypy* и для этой цели он уже **более года как стабилен**. Но как общее решение по компиляции любого python-кода, он еще сыроват, о чем авторы предупреждают на странице проекта.\n\nТакже существуют принципиальные ограничения, накладываемые на компилируемый код или на код, взаимодействующий со скомпилированным:\n\n- Принудительная проверка типов в рантайме;\n- В компилируемом коде запрещается monkey patching;\n- Mypy хранит классы в С структурах для увеличения скорости доступа к атрибутам, но это приводит к проблемам совместимости.\n\nЭти ограничения носят **принципиальный** характер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код *gcc* отказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока результат таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно **20 % модулей**, зато каких либо проблем при работе с уже скомпилированными модулями я не заметил.\n\nТем не менее, большая часть улучшений в их *Roadmap* закрыта, и проект готовится к публичному [релизу](https:\/\/github.com\/mypyc\/mypyc\/issues\/780).\n\n## Nuitka\nУже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы [Nuitka](https:\/\/nuitka.net\/) сильно напоминает описанный выше. Разница заключается в том, что *Nuitka* компилирует Python модуль в С++ код, который также собирается в *СPython Extension*. Дополнительно существует возможность собрать весь проект в **один исполняемый файл**, тогда уже сам *CPython* подключается к проекту как динамическая библиотека *libpython*.\n\n*Nuitka* пока не учитывает аннотацию типов, поэтому результирующий код и скорость работы не зависят от наличия аннотаций. Полученная же скорость в моем тесте **соответствует результату mypy** на не аннотированном коде.\n\n## Завершение\nНедавно один мой коллега высказал мнение, что *mypy* **сильно усложняет** ему жизнь: из текста ошибок невозможно понять, “чего он от меня хочет”, а анализатор из *PyCharm* немного лучше. Теперь я понимаю, что он недооценивает *mypy*. Так как он **намного большее, чем просто синтаксический анализатор**. По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание *mypy* в пайплайн проекта — инвестиция не только в поиск ошибок, но и **будущий перфоманс** приложения. Мне очень понравилось, что взаимодействие с *CPython* осуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне **наиболее безопасным** (учитывая, что *mypyc* до сих пор в альфе). Конечно, использовать ли *mypyc* на продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить *mypyc*, тем более, что сделать это просто, если вы уже используете mypy.\n\n## P.S.\nНадеюсь, вам было интересно узнать о новом способе повышения производительности python, а также глубже разобраться в механизме компиляции динамически типизированного кода. Если тема окажется интересной, то в следующей статье планирую больше рассказать про *mypyc*, его ограничения и частые ошибки, а также, как их можно обойти.\n\n## UPD\nВ комментариях подсказали, об еще одном python компиляторе - *Cython*, оказывается теперь он умеет компилировать python код напрямую (минуя ручную фазу преобразования кода в *cython*\\-код). Судя по замерам cython пока [не учитыват](https:\/\/github.com\/cython\/cython\/issues\/2587) аннотацию типов, но время выполнения (*real 1.82*) оказалось посередине между результатом mypyc на аннотированном и не аннотированном кода. Но возможно ее добавят в будущем.\n\nТеги:\n\n- [python](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[python])\n- [mypy](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[mypy])\n- [compiler](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[compiler])\n- [nuitka](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[nuitka])\n\nХабы:\n\n- [Блог компании Exness](https:\/\/habr.com\/ru\/companies\/exness\/articles\/)\n- [Высоконагруженные системы](https:\/\/habr.com\/ru\/hubs\/hi\/)\n- [Python](https:\/\/habr.com\/ru\/hubs\/python\/)\n- [Программирование](https:\/\/habr.com\/ru\/hubs\/programming\/)\n- [Компиляторы](https:\/\/habr.com\/ru\/hubs\/compilers\/)\n\n\\+27\n\n162\n\n[28](https:\/\/habr.com\/ru\/companies\/exness\/articles\/542106\/comments\/)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/company\/0d2\/a3c\/808\/0d2a3c80845887b559d3602a5e085d5f.png)](https:\/\/habr.com\/ru\/companies\/exness\/profile\/)\n\n[Exness](https:\/\/habr.com\/ru\/companies\/exness\/profile\/)\n\nTech professionals. Good people\n\n[Хабр Карьера](https:\/\/career.habr.com\/companies\/exness)[Facebook](https:\/\/facebook.com\/Exness.careers)[Instagram](https:\/\/instagram.com\/exness_careers_)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/avatars\/caa\/9c9\/cad\/caa9c9cad82105a9a46f4848dbe4aa86.jpg)](https:\/\/habr.com\/ru\/users\/zueve\/)\n\n15\n\nКарма\n\nEвгений Зуев[@zueve](https:\/\/habr.com\/ru\/users\/zueve\/)\n\nФилософия и IT\n\nПодписаться\n\nХабр доступен 24\/7 благодаря поддержке друзей\n\n![Хабр Карьера Курсы](https:\/\/habrastorage.org\/webt\/qq\/ey\/pn\/qqeypn-py71suynxbusbakjdfjw.png)\n\nХабр Курсы для всех\n\nРЕКЛАМА\n\nПрактикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать\\!\n\n[Перейти](https:\/\/career.habr.com\/courses\/?erid=2VSb5wDLYUH&utm_source=habr&utm_medium=sponsorship_hub)\n\n[Комментарии 28](https:\/\/habr.com\/ru\/companies\/exness\/articles\/542106\/comments\/)\n\n## Публикации\nЛучшие за сутки\n\nПохожие\n\n## Информация\nСайт\n\n[exness-careers.com](https:\/\/exness-careers.com\/)\n\nДата регистрации\n\n12 февраля 2020\n\nДата основания\n\n1 июля 2008\n\nЧисленность\n\n1 001–5 000 человек\n\nМестоположение\n\nКипр\n\nПредставитель\n\n[Inna\\_russa](https:\/\/habr.com\/ru\/users\/Inna_russa\/)\n\nВаш аккаунт\n\n- [Войти](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr\/?back=\/ru\/companies\/exness\/articles\/542106\/&hl=ru)\n- [Регистрация](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr-register\/?back=\/ru\/companies\/exness\/articles\/542106\/&hl=ru)\n\nРазделы\n\n- [Статьи](https:\/\/habr.com\/ru\/articles\/)\n- [Новости](https:\/\/habr.com\/ru\/news\/)\n- [Хабы](https:\/\/habr.com\/ru\/hubs\/)\n- [Компании](https:\/\/habr.com\/ru\/companies\/)\n- [Авторы](https:\/\/habr.com\/ru\/users\/)\n- [Песочница](https:\/\/habr.com\/ru\/sandbox\/)\n\nИнформация\n\n- [Устройство сайта](https:\/\/habr.com\/ru\/docs\/help\/)\n- [Для авторов](https:\/\/habr.com\/ru\/docs\/authors\/codex\/)\n- [Для компаний](https:\/\/habr.com\/ru\/docs\/companies\/corpblogs\/)\n- [Документы](https:\/\/habr.com\/ru\/docs\/docs\/transparency\/)\n- [Соглашение](https:\/\/account.habr.com\/info\/agreement\/?hl=ru_RU)\n- [Конфиденциальность](https:\/\/account.habr.com\/info\/confidential\/?hl=ru_RU)\n\nУслуги\n\n- [Корпоративный блог](https:\/\/company.habr.com\/ru\/corporate-blogs\/)\n- [Медийная реклама](https:\/\/company.habr.com\/ru\/advertising\/)\n- [Нативные проекты](https:\/\/company.habr.com\/ru\/native-special\/)\n- [Образовательные программы](https:\/\/company.habr.com\/ru\/education-programs\/)\n- [Стартапам](https:\/\/company.habr.com\/ru\/hello-startup\/)\n\nНастройка языка\n\n[Техническая поддержка](https:\/\/habr.com\/ru\/feedback\/)\n\n© 2006–2026, [Habr](https:\/\/company.habr.com\/)","attrs_readable_markdown":"![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/1e9\/1ba\/b49\/1e91bab4996a417303df57b5b644da5b.jpg)\n\nПривет, Хабр\\!\n\nЯ хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь *PyInstaller*\\-ом, а про честную *Ahead-of-time* компиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат.\n\nОбъясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: *Ahead-of-time (AOT)*, когда весь код компилируется до запуска программы и *Just in time compiler (JIT)*, когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором.\n\nЕсли сгруппировать популярные языки программирования по типу компиляции, то получим следующий список:\n\n- Ahead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart;\n- Just in time compiler: Lua, С\\#, Groovy, Dart.\n\n*В python из коробки нет JIT компилятора, но отдельные библиотеки, предоставляющие такую возможность, существуют давно*\n\nСмотря на эту таблицу, можно заметить определенную закономерность: **статически типизированные языки находятся в обеих строках**. Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin\/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично.\n\n> *При запуске виртуальная машина сначала накапливает информацию о типах переменных, затем после накопления статистики, запускается компиляция наиболее нагруженных частей программы. Виртуальная машина отслеживает типы аргументов и переключает выполнение программы между уже скомпилированными и не скомпилированными участками кода в зависимости от текущих значений переменных.*\n\nПри использовании JIT компиляции типы не очень то и нужны, ведь информация о типах собирается во время работы программы. Поэтому все популярные динамически типизированные языки программирования распространяются именно с JIT компилятором. **Но как быть с AOT компиляцией кода, в котором нет типов?** Меня очень заинтересовал этот вопрос, и я полез разбираться.\n\nИтак, вернемся к утилите, о которой говорилось в начале статьи. Речь про [mypy](http:\/\/mypy-lang.org\/) - наиболее популярный синтаксический анализатор python-кода.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/6f3\/fb7\/42d\/6f3fb742d999b54bb8d8bfc3daf1c923)\n\nС апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в [блоге](https:\/\/mypy-lang.blogspot.com\/2019\/04\/mypy-0700-released-up-to-4x-faster.html) проекта. А для компиляции используется еще одна утилита от тех же авторов — *mypyc*. Погуглив немного, я нашел достаточно большую статью “[Путь к проверке типов 4 миллионов строк Python-кода](https:\/\/dropbox.tech\/application\/our-journey-to-type-checking-4-million-lines-of-python)” про становление и развитие mypy (на Хабре доступен перевод: [часть 1](https:\/\/habr.com\/ru\/company\/ruvds\/blog\/468233\/), [часть 2](https:\/\/habr.com\/ru\/company\/ruvds\/blog\/468235\/), [часть 3](https:\/\/habr.com\/ru\/company\/ruvds\/blog\/468237\/)). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на *go* или на *cython*. В результате проект пошел по третьему пути — **написание своего AOT python-компилятора**.\n\nДело в том, что для правильной работы *mypy* и так необходимо построить то же синтаксическое дерево, что и интерпретатору во время исполнения кода. То есть **mypy уже “понимает” python**, но использует эту информацию только для статистического анализа, а вот *mypyc* может преобразовывать эту информацию в полноценный бинарный код.\n\nДумаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а *mypy* как раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что *mypyc* **может компилировать и неаннотированный код**\\!\n\n## Функция bubble\\_sort\nДля примера рассмотрим функцию сортировки “пузырьком”. Файл *lib.py:*\n```\ndef bubble_sort(data):\n   n = len(data)\n   for i in range(n - 1):\n       for j in range(n - i - 1):\n           if data[j] > data[j + 1]:\n               buff = data[j]\n               data[j] = data[j + 1]\n               data[j + 1] = buff\n   return data\n```\nУ типов нет аннотаций, но это не мешает *mypyc* ее скомпилировать. Чтобы запустить компиляцию, нужно установить *mypyc*. Он не распространяется отдельным пакетом, но если у вас установлен *mypy*, то и *mypyc* уже присутствует в системе! Запускаем *mypyc*, следующей командой:\n```\n> mypyc lib.py\n```\nПосле запуска в проекте будут созданы следующие директории:\n\n- `.mypy_cache` — *mypy* кэш, mypyc неявно запускает mypy для разбора программы и получения AST;\n- `build` — артефакты сборки;\n- `lib.cpython-38-x86_64-linux-gnu.so` — собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension.\n\n> *CPython Extension* — встроенный в *CPython* механизм взаимодействия с кодом, написанным на С\/C++. По сути это динамическая библиотека, которую *CPython* умеет загружать при импорте нашего модуля *lib*. Через данный механизм осуществляется взаимодействие с модулями, написанными на python.\n\nКомпиляция состоит из двух фаз:\n\n1. Компиляция python кода в код С;\n2. Компиляция С в бинарный *.so* файл, для этого *mypyc* сам запускает gcc (*gcc* и *python-dev* также должен быть установлены).\n\nФайл `lib.cpython-38-x86_64-linux-gnu.so` имеет преимущество перед *lib.py* при импорте на соответствующей платформе, и исполняться теперь будет именно он.\n\nНу и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл *main.py* с кодом запуска сортировки:\n```\nimport lib\n\n\ndata = lib.bubble_sort(list(range(5000, 0, -1)))\n\nassert data == list(range(1, 5001))\n```\nПолучим примерно следующие результаты:\n\n|   |   |\n|---|---|\n| До | После |\n| real 5.68user 5.60sys 0.01 | real 2.78user 2.73sys 0.01 |\n\nОжидаемо скомпилированный код **оказался быстрее (~ в 2 раза)**, что неплохо, так как для такого результата нам потребовалось запустить лишь одну команду. Хотя от скомпилированного кода привычно ожидаешь большего.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/5a3\/bbe\/285\/5a3bbe28516bfd798ed394c0e46afaf7)\n\nЧтобы ответить на вопрос *“как компилируется динамически типизированный код”*, придется заглянуть в представление этой функции на С. Но разобрать ее будет достаточно сложно, поэтому давайте попробуем разобраться с примером попроще.\n\n## Функция sum(a, b)\nСкомпилируем функцию суммы от двух переменных:\n```\ndef sum(a, b):\n  return a + b\n```\nПеред запуском компиляции я ожидал увидеть примерно следующий код на С:\n```\nint sum(int a, int b) {\n   return a + b;\n}\n```\nОднако результат оказался cущественно иным (**код немного упрощен**):\n```\nPyObject *CPyDef_sum(PyObject *cpy_r_a, PyObject *cpy_r_b){\n    return PyNumber_Add(cpy_r_a, cpy_r_b);\n}\n```\nРассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса *PyObject*, по сути это внутренние *CPython* структуры. Далее **компилятор должен сложить эти объекты**, но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc?\n\nКак оказалось, все очень просто: он просит *CPython* самостоятельно сложить эти аргументы. Функция *PyNumber\\_Add* — это внутренняя функция *СPython*, которая доступна из расширения, ведь ***СPython* отлично умеет складывать свои объекты**.\n\nВзаимодействие CPython c Extension можно изобразить следующим диалогом:\n\n> — А посчитай-ка мне функцию sum для A, B;\n> \n> — Хорошо, но скажи сначала, сколько будет A + B;\n> \n> — Будет С;\n> \n> — Хорошо, тогда держи ответ - С.\n\nВот такой нехитрый прием используется при компиляции динамического кода: **компилируем все, что можем, а все остальное отдаем интерпретатору**.\n\nКонечно, данный пример выглядит гротескно, но даже **несмотря на такую неэффективность**, mypyc позволяет добиться существенного **прироста производительности**, как в примере с сортировкой.\n\n## Функция sum(a: int, b: int)\nИтак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во **множественном взаимодействии** *CPython - Extension*. Но как это побороть?\n\nДля повышения эффективности, нужно, чтобы расширение, получив управление, могло как можно **дольше оставлять его у себя** без обращения к *CPython*. Если бы у mypyc была информация о типах переменных, то он бы мог самостоятельно произвести сложение без возврата управления. Но вывести типы самостоятельно mypyc не может, он даже **не контролирует код**, из которого осуществляется вызов функции sum. Соответственно, ему нужно помочь, проставив аннотации вручную. Давайте посмотрим, как поменяется результирующая С-функция, если добавить аннотацию типов:\n```\ndef sum(a: int, b: int):\n  return a + b\n```\nСкомпилированный результат на C (*немного очищенный*):\n```\nPyObject *CPyDef_sum(CPyTagged cpy_r_a, CPyTagged cpy_r_b) {\n   CPyTagged cpy_r_r0;\n   PyObject *cpy_r_r1;\n   cpy_r_r0 = CPyTagged_Add(cpy_r_a, cpy_r_b);\n   cpy_r_r1 = CPyTagged_StealAsObject(cpy_r_r0);\n\n   return cpy_r_r1;\n}\n```\nГлавное, что можно заметить: **функция существенно поменялась**, а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось.\n\nТеперь *CPyDef\\_sum* получает на вход не указатели на *PyObject*, а структуры *CPyTagged*. Это все еще не *int*, но уже и не часть *CPython*, а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция *sum* работает только с *int* и обойти аннотацию не получится.\n\nДалее происходит вызов *CPyTaggetAdd* вместо *PyNumber\\_Add*. Это уже **внутренняя функция mypyc**. Если заглянуть в [код](https:\/\/github.com\/python\/mypy\/blob\/5e20a26b922e2f5b71425ea7f57d2b4cba5a9324\/mypyc\/lib-rt\/int_ops.c#L136) *CPyTaggetAdd*, то можно понять, что там происходит проверка диапазонов значений *a* и *b*, и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение:\n```\nif (likely(CPyTagged_CheckShort(left) && CPyTagged_CheckShort(right))) {\n    CPyTagged sum = left + right;\n\n    if (likely(!CPyTagged_IsAddOverflow(sum, left, right))) {\n        return sum;\n    }\n}\n```\nТаким образом, наш диалог *CPython - Extension* превращается **из абсурдного в нормальный**:\n\n> — А посчитай-ка мне функцию sum для A, B;\n> \n> — Хорошо, тогда держи ответ С.\n## Функция bubble\\_sort(data: List\\[int\\])\nНастало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для *data*:\n```\ndef bubble_sort(data: List[int]):\n    …\n```\nСкомпилируем результат и замерим время сортировки:\n\n|   |   |   |\n|---|---|---|\n| Без компиляции | С компиляцией, без аннотации типов | С компиляцией и аннотацией типов |\n| real 5.68user 5.60sys 0.01 | real 2.78user 2.73sys 0.01 | real 1.32user 1.30sys 0.01 |\n\nИтак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального\\!\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/1a6\/2b9\/4e6\/1a62b94e684142f6991bf6637ef9ed81)\n\n## Пара слов о mypyc\nЕсли вы уже бросились компилировать ваши пакеты, то стоит задержаться на пару минут, чтобы дочитать этот абзац до конца. Главным недостатком *mypyc* пока остается стабильность: он все еще в альфе, точнее, сейчас это вообще не самостоятельный проект, а часть *mypy*. Собственно он и создавался специально под задачу увеличения производительности *mypy* и для этой цели он уже **более года как стабилен**. Но как общее решение по компиляции любого python-кода, он еще сыроват, о чем авторы предупреждают на странице проекта.\n\nТакже существуют принципиальные ограничения, накладываемые на компилируемый код или на код, взаимодействующий со скомпилированным:\n\n- Принудительная проверка типов в рантайме;\n- В компилируемом коде запрещается monkey patching;\n- Mypy хранит классы в С структурах для увеличения скорости доступа к атрибутам, но это приводит к проблемам совместимости.\n\nЭти ограничения носят **принципиальный** характер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код *gcc* отказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока результат таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно **20 % модулей**, зато каких либо проблем при работе с уже скомпилированными модулями я не заметил.\n\nТем не менее, большая часть улучшений в их *Roadmap* закрыта, и проект готовится к публичному [релизу](https:\/\/github.com\/mypyc\/mypyc\/issues\/780).\n\n## Nuitka\nУже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы [Nuitka](https:\/\/nuitka.net\/) сильно напоминает описанный выше. Разница заключается в том, что *Nuitka* компилирует Python модуль в С++ код, который также собирается в *СPython Extension*. Дополнительно существует возможность собрать весь проект в **один исполняемый файл**, тогда уже сам *CPython* подключается к проекту как динамическая библиотека *libpython*.\n\n*Nuitka* пока не учитывает аннотацию типов, поэтому результирующий код и скорость работы не зависят от наличия аннотаций. Полученная же скорость в моем тесте **соответствует результату mypy** на не аннотированном коде.\n\n## Завершение\nНедавно один мой коллега высказал мнение, что *mypy* **сильно усложняет** ему жизнь: из текста ошибок невозможно понять, “чего он от меня хочет”, а анализатор из *PyCharm* немного лучше. Теперь я понимаю, что он недооценивает *mypy*. Так как он **намного большее, чем просто синтаксический анализатор**. По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание *mypy* в пайплайн проекта — инвестиция не только в поиск ошибок, но и **будущий перфоманс** приложения. Мне очень понравилось, что взаимодействие с *CPython* осуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне **наиболее безопасным** (учитывая, что *mypyc* до сих пор в альфе). Конечно, использовать ли *mypyc* на продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить *mypyc*, тем более, что сделать это просто, если вы уже используете mypy.\n\n## P.S.\nНадеюсь, вам было интересно узнать о новом способе повышения производительности python, а также глубже разобраться в механизме компиляции динамически типизированного кода. Если тема окажется интересной, то в следующей статье планирую больше рассказать про *mypyc*, его ограничения и частые ошибки, а также, как их можно обойти.\n\n## UPD\nВ комментариях подсказали, об еще одном python компиляторе - *Cython*, оказывается теперь он умеет компилировать python код напрямую (минуя ручную фазу преобразования кода в *cython*\\-код). Судя по замерам cython пока [не учитыват](https:\/\/github.com\/cython\/cython\/issues\/2587) аннотацию типов, но время выполнения (*real 1.82*) оказалось посередине между результатом mypyc на аннотированном и не аннотированном кода. Но возможно ее добавят в будущем.","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

1 day ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	0 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://habr.com/ru/companies/exness/articles/542106/
Last Crawled	2026-04-06 11:56:28 (1 day ago)
First Indexed	not set
HTTP Status Code	200
Meta Title	Как скомпилировать Python / Хабр
Meta Description	Привет, Хабр! Я хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов,...
Meta Canonical	null
Boilerpipe Text	Привет, Хабр! Я хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь PyInstaller -ом, а про честную Ahead-of-time компиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат. Объясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: Ahead-of-time (AOT) , когда весь код компилируется до запуска программы и Just in time compiler (JIT) , когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором. Если сгруппировать популярные языки программирования по типу компиляции, то получим следующий список: Ahead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart; Just in time compiler: Lua, С#, Groovy, Dart. В python из коробки нет JIT компилятора, но отдельные библиотеки, предоставляющие такую возможность, существуют давно Смотря на эту таблицу, можно заметить определенную закономерность: статически типизированные языки находятся в обеих строках . Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично. При запуске виртуальная машина сначала накапливает информацию о типах переменных, затем после накопления статистики, запускается компиляция наиболее нагруженных частей программы. Виртуальная машина отслеживает типы аргументов и переключает выполнение программы между уже скомпилированными и не скомпилированными участками кода в зависимости от текущих значений переменных. При использовании JIT компиляции типы не очень то и нужны, ведь информация о типах собирается во время работы программы. Поэтому все популярные динамически типизированные языки программирования распространяются именно с JIT компилятором. Но как быть с AOT компиляцией кода, в котором нет типов? Меня очень заинтересовал этот вопрос, и я полез разбираться. Итак, вернемся к утилите, о которой говорилось в начале статьи. Речь про mypy - наиболее популярный синтаксический анализатор python-кода. С апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в блоге проекта. А для компиляции используется еще одна утилита от тех же авторов — mypyc . Погуглив немного, я нашел достаточно большую статью “ Путь к проверке типов 4 миллионов строк Python-кода ” про становление и развитие mypy (на Хабре доступен перевод: часть 1 , часть 2 , часть 3 ). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на go или на cython . В результате проект пошел по третьему пути — написание своего AOT python-компилятора . Дело в том, что для правильной работы mypy и так необходимо построить то же синтаксическое дерево, что и интерпретатору во время исполнения кода. То есть mypy уже “понимает” python , но использует эту информацию только для статистического анализа, а вот mypyc может преобразовывать эту информацию в полноценный бинарный код. Думаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а mypy как раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что mypyc может компилировать и неаннотированный код ! Функция bubble_sort Для примера рассмотрим функцию сортировки “пузырьком”. Файл lib.py: def bubble_sort(data): n = len(data) for i in range(n - 1): for j in range(n - i - 1): if data[j] > data[j + 1]: buff = data[j] data[j] = data[j + 1] data[j + 1] = buff return data У типов нет аннотаций, но это не мешает mypyc ее скомпилировать. Чтобы запустить компиляцию, нужно установить mypyc . Он не распространяется отдельным пакетом, но если у вас установлен mypy , то и mypyc уже присутствует в системе! Запускаем mypyc , следующей командой: > mypyc lib.py После запуска в проекте будут созданы следующие директории: .mypy_cache — mypy кэш, mypyc неявно запускает mypy для разбора программы и получения AST; build — артефакты сборки; lib.cpython-38-x86_64-linux-gnu.so — собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension. CPython Extension — встроенный в CPython механизм взаимодействия с кодом, написанным на С/C++. По сути это динамическая библиотека, которую CPython умеет загружать при импорте нашего модуля lib . Через данный механизм осуществляется взаимодействие с модулями, написанными на python. Компиляция состоит из двух фаз: Компиляция python кода в код С; Компиляция С в бинарный .so файл, для этого mypyc сам запускает gcc ( gcc и python-dev также должен быть установлены). Файл lib.cpython-38-x86_64-linux-gnu.so имеет преимущество перед lib.py при импорте на соответствующей платформе, и исполняться теперь будет именно он. Ну и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл main.py с кодом запуска сортировки: import lib data = lib.bubble_sort(list(range(5000, 0, -1))) assert data == list(range(1, 5001)) Получим примерно следующие результаты: До После real 5.68 user 5.60 sys 0.01 real 2.78 user 2.73 sys 0.01 Ожидаемо скомпилированный код оказался быстрее (~ в 2 раза) , что неплохо, так как для такого результата нам потребовалось запустить лишь одну команду. Хотя от скомпилированного кода привычно ожидаешь большего. Чтобы ответить на вопрос “как компилируется динамически типизированный код” , придется заглянуть в представление этой функции на С. Но разобрать ее будет достаточно сложно, поэтому давайте попробуем разобраться с примером попроще. Функция sum(a, b) Скомпилируем функцию суммы от двух переменных: def sum(a, b): return a + b Перед запуском компиляции я ожидал увидеть примерно следующий код на С: int sum(int a, int b) { return a + b; } Однако результат оказался cущественно иным ( код немного упрощен ): PyObject CPyDef_sum(PyObject cpy_r_a, PyObject cpy_r_b){ return PyNumber_Add(cpy_r_a, cpy_r_b); } Рассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса PyObject , по сути это внутренние CPython структуры. Далее компилятор должен сложить эти объекты , но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc? Как оказалось, все очень просто: он просит CPython самостоятельно сложить эти аргументы. Функция PyNumber_Add — это внутренняя функция СPython , которая доступна из расширения, ведь СPython отлично умеет складывать свои объекты . Взаимодействие CPython c Extension можно изобразить следующим диалогом: — А посчитай-ка мне функцию sum для A, B; — Хорошо, но скажи сначала, сколько будет A + B; — Будет С; — Хорошо, тогда держи ответ - С. Вот такой нехитрый прием используется при компиляции динамического кода: компилируем все, что можем, а все остальное отдаем интерпретатору . Конечно, данный пример выглядит гротескно, но даже несмотря на такую неэффективность , mypyc позволяет добиться существенного прироста производительности , как в примере с сортировкой. Функция sum(a: int, b: int) Итак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во множественном взаимодействии CPython - Extension . Но как это побороть? Для повышения эффективности, нужно, чтобы расширение, получив управление, могло как можно дольше оставлять его у себя без обращения к CPython . Если бы у mypyc была информация о типах переменных, то он бы мог самостоятельно произвести сложение без возврата управления. Но вывести типы самостоятельно mypyc не может, он даже не контролирует код , из которого осуществляется вызов функции sum. Соответственно, ему нужно помочь, проставив аннотации вручную. Давайте посмотрим, как поменяется результирующая С-функция, если добавить аннотацию типов: def sum(a: int, b: int): return a + b Скомпилированный результат на C ( немного очищенный ): PyObject CPyDef_sum(CPyTagged cpy_r_a, CPyTagged cpy_r_b) { CPyTagged cpy_r_r0; PyObject *cpy_r_r1; cpy_r_r0 = CPyTagged_Add(cpy_r_a, cpy_r_b); cpy_r_r1 = CPyTagged_StealAsObject(cpy_r_r0); return cpy_r_r1; } Главное, что можно заметить: функция существенно поменялась , а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось. Теперь CPyDef_sum получает на вход не указатели на PyObject , а структуры CPyTagged . Это все еще не int , но уже и не часть CPython , а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция sum работает только с int и обойти аннотацию не получится. Далее происходит вызов CPyTaggetAdd вместо PyNumber_Add . Это уже внутренняя функция mypyc . Если заглянуть в код CPyTaggetAdd , то можно понять, что там происходит проверка диапазонов значений a и b , и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение: if (likely(CPyTagged_CheckShort(left) && CPyTagged_CheckShort(right))) { CPyTagged sum = left + right; if (likely(!CPyTagged_IsAddOverflow(sum, left, right))) { return sum; } } Таким образом, наш диалог CPython - Extension превращается из абсурдного в нормальный : — А посчитай-ка мне функцию sum для A, B; — Хорошо, тогда держи ответ С. Функция bubble_sort(data: List[int]) Настало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для data : def bubble_sort(data: List[int]): … Скомпилируем результат и замерим время сортировки: Без компиляции С компиляцией, без аннотации типов С компиляцией и аннотацией типов real 5.68 user 5.60 sys 0.01 real 2.78 user 2.73 sys 0.01 real 1.32 user 1.30 sys 0.01 Итак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального! Пара слов о mypyc Если вы уже бросились компилировать ваши пакеты, то стоит задержаться на пару минут, чтобы дочитать этот абзац до конца. Главным недостатком mypyc пока остается стабильность: он все еще в альфе, точнее, сейчас это вообще не самостоятельный проект, а часть mypy . Собственно он и создавался специально под задачу увеличения производительности mypy и для этой цели он уже более года как стабилен . Но как общее решение по компиляции любого python-кода, он еще сыроват, о чем авторы предупреждают на странице проекта. Также существуют принципиальные ограничения, накладываемые на компилируемый код или на код, взаимодействующий со скомпилированным: Принудительная проверка типов в рантайме; В компилируемом коде запрещается monkey patching; Mypy хранит классы в С структурах для увеличения скорости доступа к атрибутам, но это приводит к проблемам совместимости. Эти ограничения носят принципиальный характер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код gcc отказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока результат таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно 20 % модулей , зато каких либо проблем при работе с уже скомпилированными модулями я не заметил. Тем не менее, большая часть улучшений в их Roadmap закрыта, и проект готовится к публичному релизу . Nuitka Уже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы Nuitka сильно напоминает описанный выше. Разница заключается в том, что Nuitka компилирует Python модуль в С++ код, который также собирается в СPython Extension . Дополнительно существует возможность собрать весь проект в один исполняемый файл , тогда уже сам CPython подключается к проекту как динамическая библиотека libpython . Nuitka пока не учитывает аннотацию типов, поэтому результирующий код и скорость работы не зависят от наличия аннотаций. Полученная же скорость в моем тесте соответствует результату mypy на не аннотированном коде. Завершение Недавно один мой коллега высказал мнение, что mypy сильно усложняет ему жизнь: из текста ошибок невозможно понять, “чего он от меня хочет”, а анализатор из PyCharm немного лучше. Теперь я понимаю, что он недооценивает mypy . Так как он намного большее, чем просто синтаксический анализатор . По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание mypy в пайплайн проекта — инвестиция не только в поиск ошибок, но и будущий перфоманс приложения. Мне очень понравилось, что взаимодействие с CPython осуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне наиболее безопасным (учитывая, что mypyc до сих пор в альфе). Конечно, использовать ли mypyc на продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить mypyc , тем более, что сделать это просто, если вы уже используете mypy. P.S. Надеюсь, вам было интересно узнать о новом способе повышения производительности python, а также глубже разобраться в механизме компиляции динамически типизированного кода. Если тема окажется интересной, то в следующей статье планирую больше рассказать про mypyc , его ограничения и частые ошибки, а также, как их можно обойти. UPD В комментариях подсказали, об еще одном python компиляторе - Cython , оказывается теперь он умеет компилировать python код напрямую (минуя ручную фазу преобразования кода в cython -код). Судя по замерам cython пока не учитыват аннотацию типов, но время выполнения ( real 1.82 ) оказалось посередине между результатом mypyc на аннотированном и не аннотированном кода. Но возможно ее добавят в будущем.
Markdown	[Все потоки](https://habr.com/ru/articles/) [Войти](https://habr.com/kek/v1/auth/habrahabr/?back=/ru/companies/exness/articles/542106/&hl=ru) [![](https://habrastorage.org/getpro/habr/company/0d2/a3c/808/0d2a3c80845887b559d3602a5e085d5f.png)](https://habr.com/ru/companies/exness/profile/) [Exness](https://habr.com/ru/companies/exness/profile/) Tech professionals. Good people 182 Подписчики Подписаться [![](https://habrastorage.org/r/w48/getpro/habr/avatars/caa/9c9/cad/caa9c9cad82105a9a46f4848dbe4aa86.jpg)](https://habr.com/ru/users/zueve/) [zueve](https://habr.com/ru/users/zueve/) 12 фев 2021 в 12:41 # Как скомпилировать Python 10 мин 68K [Блог компании Exness](https://habr.com/ru/companies/exness/articles/)[Высоконагруженные системы \](https://habr.com/ru/hubs/hi/) [Python \](https://habr.com/ru/hubs/python/) [Программирование \](https://habr.com/ru/hubs/programming/) [Компиляторы \](https://habr.com/ru/hubs/compilers/) ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/1e9/1ba/b49/1e91bab4996a417303df57b5b644da5b.jpg) Привет, Хабр\! Я хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь PyInstaller\-ом, а про честную Ahead-of-time компиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат. Объясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: Ahead-of-time (AOT), когда весь код компилируется до запуска программы и Just in time compiler (JIT), когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором. Если сгруппировать популярные языки программирования по типу компиляции, то получим следующий список: - Ahead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart; - Just in time compiler: Lua, С\#, Groovy, Dart. В python из коробки нет JIT компилятора, но отдельные библиотеки, предоставляющие такую возможность, существуют давно Смотря на эту таблицу, можно заметить определенную закономерность: статически типизированные языки находятся в обеих строках. Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично. > При запуске виртуальная машина сначала накапливает информацию о типах переменных, затем после накопления статистики, запускается компиляция наиболее нагруженных частей программы. Виртуальная машина отслеживает типы аргументов и переключает выполнение программы между уже скомпилированными и не скомпилированными участками кода в зависимости от текущих значений переменных. При использовании JIT компиляции типы не очень то и нужны, ведь информация о типах собирается во время работы программы. Поэтому все популярные динамически типизированные языки программирования распространяются именно с JIT компилятором. Но как быть с AOT компиляцией кода, в котором нет типов? Меня очень заинтересовал этот вопрос, и я полез разбираться. Итак, вернемся к утилите, о которой говорилось в начале статьи. Речь про [mypy](http://mypy-lang.org/) - наиболее популярный синтаксический анализатор python-кода. ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/6f3/fb7/42d/6f3fb742d999b54bb8d8bfc3daf1c923) С апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в [блоге](https://mypy-lang.blogspot.com/2019/04/mypy-0700-released-up-to-4x-faster.html) проекта. А для компиляции используется еще одна утилита от тех же авторов — mypyc. Погуглив немного, я нашел достаточно большую статью “[Путь к проверке типов 4 миллионов строк Python-кода](https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python)” про становление и развитие mypy (на Хабре доступен перевод: [часть 1](https://habr.com/ru/company/ruvds/blog/468233/), [часть 2](https://habr.com/ru/company/ruvds/blog/468235/), [часть 3](https://habr.com/ru/company/ruvds/blog/468237/)). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на go или на cython. В результате проект пошел по третьему пути — написание своего AOT python-компилятора. Дело в том, что для правильной работы mypy и так необходимо построить то же синтаксическое дерево, что и интерпретатору во время исполнения кода. То есть mypy уже “понимает” python, но использует эту информацию только для статистического анализа, а вот mypyc может преобразовывать эту информацию в полноценный бинарный код. Думаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а mypy как раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что mypyc может компилировать и неаннотированный код\! ## Функция bubble\_sort Для примера рассмотрим функцию сортировки “пузырьком”. Файл lib.py: ``` ``` У типов нет аннотаций, но это не мешает mypyc ее скомпилировать. Чтобы запустить компиляцию, нужно установить mypyc. Он не распространяется отдельным пакетом, но если у вас установлен mypy, то и mypyc уже присутствует в системе! Запускаем mypyc, следующей командой: ``` > mypyc lib.py ``` После запуска в проекте будут созданы следующие директории: - `.mypy_cache` — mypy кэш, mypyc неявно запускает mypy для разбора программы и получения AST; - `build` — артефакты сборки; - `lib.cpython-38-x86_64-linux-gnu.so` — собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension. > CPython Extension — встроенный в CPython механизм взаимодействия с кодом, написанным на С/C++. По сути это динамическая библиотека, которую CPython умеет загружать при импорте нашего модуля lib. Через данный механизм осуществляется взаимодействие с модулями, написанными на python. Компиляция состоит из двух фаз: 1. Компиляция python кода в код С; 2. Компиляция С в бинарный .so файл, для этого mypyc сам запускает gcc (gcc и python-dev также должен быть установлены). Файл `lib.cpython-38-x86_64-linux-gnu.so` имеет преимущество перед lib.py при импорте на соответствующей платформе, и исполняться теперь будет именно он. Ну и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл main.py с кодом запуска сортировки: ``` ``` Получим примерно следующие результаты: \| \| \| \|---\|---\| \| До \| После \| \| real 5.68user 5.60sys 0.01 \| real 2.78user 2.73sys 0.01 \| Ожидаемо скомпилированный код оказался быстрее (~ в 2 раза), что неплохо, так как для такого результата нам потребовалось запустить лишь одну команду. Хотя от скомпилированного кода привычно ожидаешь большего. ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/5a3/bbe/285/5a3bbe28516bfd798ed394c0e46afaf7) Чтобы ответить на вопрос “как компилируется динамически типизированный код”, придется заглянуть в представление этой функции на С. Но разобрать ее будет достаточно сложно, поэтому давайте попробуем разобраться с примером попроще. ## Функция sum(a, b) Скомпилируем функцию суммы от двух переменных: ``` ``` Перед запуском компиляции я ожидал увидеть примерно следующий код на С: ``` ``` Однако результат оказался cущественно иным (код немного упрощен): ``` ``` Рассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса PyObject, по сути это внутренние CPython структуры. Далее компилятор должен сложить эти объекты, но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc? Как оказалось, все очень просто: он просит CPython самостоятельно сложить эти аргументы. Функция PyNumber\_Add — это внутренняя функция СPython, которая доступна из расширения, ведь **СPython отлично умеет складывать свои объекты. Взаимодействие CPython c Extension можно изобразить следующим диалогом: > — А посчитай-ка мне функцию sum для A, B; > > — Хорошо, но скажи сначала, сколько будет A + B; > > — Будет С; > > — Хорошо, тогда держи ответ - С. Вот такой нехитрый прием используется при компиляции динамического кода: компилируем все, что можем, а все остальное отдаем интерпретатору. Конечно, данный пример выглядит гротескно, но даже несмотря на такую неэффективность, mypyc позволяет добиться существенного прироста производительности, как в примере с сортировкой. ## Функция sum(a: int, b: int) Итак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во множественном взаимодействии** CPython - Extension. Но как это побороть? Для повышения эффективности, нужно, чтобы расширение, получив управление, могло как можно дольше оставлять его у себя без обращения к CPython. Если бы у mypyc была информация о типах переменных, то он бы мог самостоятельно произвести сложение без возврата управления. Но вывести типы самостоятельно mypyc не может, он даже не контролирует код, из которого осуществляется вызов функции sum. Соответственно, ему нужно помочь, проставив аннотации вручную. Давайте посмотрим, как поменяется результирующая С-функция, если добавить аннотацию типов: ``` ``` Скомпилированный результат на C (немного очищенный): ``` ``` Главное, что можно заметить: функция существенно поменялась, а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось. Теперь CPyDef\_sum получает на вход не указатели на PyObject, а структуры CPyTagged. Это все еще не int, но уже и не часть CPython, а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция sum работает только с int и обойти аннотацию не получится. Далее происходит вызов CPyTaggetAdd вместо PyNumber\_Add. Это уже внутренняя функция mypyc. Если заглянуть в [код](https://github.com/python/mypy/blob/5e20a26b922e2f5b71425ea7f57d2b4cba5a9324/mypyc/lib-rt/int_ops.c#L136) CPyTaggetAdd, то можно понять, что там происходит проверка диапазонов значений a и b, и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение: ``` ``` Таким образом, наш диалог CPython - Extension превращается из абсурдного в нормальный: > — А посчитай-ка мне функцию sum для A, B; > > — Хорошо, тогда держи ответ С. ## Функция bubble\_sort(data: List\[int\]) Настало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для data: ``` ``` Скомпилируем результат и замерим время сортировки: \| \| \| \| \|---\|---\|---\| \| Без компиляции \| С компиляцией, без аннотации типов \| С компиляцией и аннотацией типов \| \| real 5.68user 5.60sys 0.01 \| real 2.78user 2.73sys 0.01 \| real 1.32user 1.30sys 0.01 \| Итак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального\! ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/1a6/2b9/4e6/1a62b94e684142f6991bf6637ef9ed81) ## Пара слов о mypyc Если вы уже бросились компилировать ваши пакеты, то стоит задержаться на пару минут, чтобы дочитать этот абзац до конца. Главным недостатком mypyc пока остается стабильность: он все еще в альфе, точнее, сейчас это вообще не самостоятельный проект, а часть mypy. Собственно он и создавался специально под задачу увеличения производительности mypy и для этой цели он уже более года как стабилен. Но как общее решение по компиляции любого python-кода, он еще сыроват, о чем авторы предупреждают на странице проекта. Также существуют принципиальные ограничения, накладываемые на компилируемый код или на код, взаимодействующий со скомпилированным: - Принудительная проверка типов в рантайме; - В компилируемом коде запрещается monkey patching; - Mypy хранит классы в С структурах для увеличения скорости доступа к атрибутам, но это приводит к проблемам совместимости. Эти ограничения носят принципиальный характер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код gcc отказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока результат таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно 20 % модулей, зато каких либо проблем при работе с уже скомпилированными модулями я не заметил. Тем не менее, большая часть улучшений в их Roadmap закрыта, и проект готовится к публичному [релизу](https://github.com/mypyc/mypyc/issues/780). ## Nuitka Уже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы [Nuitka](https://nuitka.net/) сильно напоминает описанный выше. Разница заключается в том, что Nuitka компилирует Python модуль в С++ код, который также собирается в СPython Extension. Дополнительно существует возможность собрать весь проект в один исполняемый файл, тогда уже сам CPython подключается к проекту как динамическая библиотека libpython. Nuitka пока не учитывает аннотацию типов, поэтому результирующий код и скорость работы не зависят от наличия аннотаций. Полученная же скорость в моем тесте соответствует результату mypy на не аннотированном коде. ## Завершение Недавно один мой коллега высказал мнение, что mypy сильно усложняет ему жизнь: из текста ошибок невозможно понять, “чего он от меня хочет”, а анализатор из PyCharm немного лучше. Теперь я понимаю, что он недооценивает mypy. Так как он намного большее, чем просто синтаксический анализатор. По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание mypy в пайплайн проекта — инвестиция не только в поиск ошибок, но и будущий перфоманс приложения. Мне очень понравилось, что взаимодействие с CPython осуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне наиболее безопасным (учитывая, что mypyc до сих пор в альфе). Конечно, использовать ли mypyc на продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить mypyc, тем более, что сделать это просто, если вы уже используете mypy. ## P.S. Надеюсь, вам было интересно узнать о новом способе повышения производительности python, а также глубже разобраться в механизме компиляции динамически типизированного кода. Если тема окажется интересной, то в следующей статье планирую больше рассказать про mypyc, его ограничения и частые ошибки, а также, как их можно обойти. ## UPD В комментариях подсказали, об еще одном python компиляторе - Cython, оказывается теперь он умеет компилировать python код напрямую (минуя ручную фазу преобразования кода в cython\-код). Судя по замерам cython пока [не учитыват](https://github.com/cython/cython/issues/2587) аннотацию типов, но время выполнения (real 1.82) оказалось посередине между результатом mypyc на аннотированном и не аннотированном кода. Но возможно ее добавят в будущем. Теги: - [python](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[python]) - [mypy](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[mypy]) - [compiler](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[compiler]) - [nuitka](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[nuitka]) Хабы: - [Блог компании Exness](https://habr.com/ru/companies/exness/articles/) - [Высоконагруженные системы](https://habr.com/ru/hubs/hi/) - [Python](https://habr.com/ru/hubs/python/) - [Программирование](https://habr.com/ru/hubs/programming/) - [Компиляторы](https://habr.com/ru/hubs/compilers/) \+27 162 [28](https://habr.com/ru/companies/exness/articles/542106/comments/) [![](https://habrastorage.org/getpro/habr/company/0d2/a3c/808/0d2a3c80845887b559d3602a5e085d5f.png)](https://habr.com/ru/companies/exness/profile/) [Exness](https://habr.com/ru/companies/exness/profile/) Tech professionals. Good people [Хабр Карьера](https://career.habr.com/companies/exness)[Facebook](https://facebook.com/Exness.careers)[Instagram](https://instagram.com/exness_careers_) [![](https://habrastorage.org/getpro/habr/avatars/caa/9c9/cad/caa9c9cad82105a9a46f4848dbe4aa86.jpg)](https://habr.com/ru/users/zueve/) 15 Карма Eвгений Зуев[@zueve](https://habr.com/ru/users/zueve/) Философия и IT Подписаться Хабр доступен 24/7 благодаря поддержке друзей ![Хабр Карьера Курсы](https://habrastorage.org/webt/qq/ey/pn/qqeypn-py71suynxbusbakjdfjw.png) Хабр Курсы для всех РЕКЛАМА Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать\! [Перейти](https://career.habr.com/courses/?erid=2VSb5wDLYUH&utm_source=habr&utm_medium=sponsorship_hub) [Комментарии 28](https://habr.com/ru/companies/exness/articles/542106/comments/) ## Публикации Лучшие за сутки Похожие ## Информация Сайт [exness-careers.com](https://exness-careers.com/) Дата регистрации 12 февраля 2020 Дата основания 1 июля 2008 Численность 1 001–5 000 человек Местоположение Кипр Представитель [Inna\_russa](https://habr.com/ru/users/Inna_russa/) Ваш аккаунт - [Войти](https://habr.com/kek/v1/auth/habrahabr/?back=/ru/companies/exness/articles/542106/&hl=ru) - [Регистрация](https://habr.com/kek/v1/auth/habrahabr-register/?back=/ru/companies/exness/articles/542106/&hl=ru) Разделы - [Статьи](https://habr.com/ru/articles/) - [Новости](https://habr.com/ru/news/) - [Хабы](https://habr.com/ru/hubs/) - [Компании](https://habr.com/ru/companies/) - [Авторы](https://habr.com/ru/users/) - [Песочница](https://habr.com/ru/sandbox/) Информация - [Устройство сайта](https://habr.com/ru/docs/help/) - [Для авторов](https://habr.com/ru/docs/authors/codex/) - [Для компаний](https://habr.com/ru/docs/companies/corpblogs/) - [Документы](https://habr.com/ru/docs/docs/transparency/) - [Соглашение](https://account.habr.com/info/agreement/?hl=ru_RU) - [Конфиденциальность](https://account.habr.com/info/confidential/?hl=ru_RU) Услуги - [Корпоративный блог](https://company.habr.com/ru/corporate-blogs/) - [Медийная реклама](https://company.habr.com/ru/advertising/) - [Нативные проекты](https://company.habr.com/ru/native-special/) - [Образовательные программы](https://company.habr.com/ru/education-programs/) - [Стартапам](https://company.habr.com/ru/hello-startup/) Настройка языка [Техническая поддержка](https://habr.com/ru/feedback/) © 2006–2026, [Habr](https://company.habr.com/)
Readable Markdown	![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/1e9/1ba/b49/1e91bab4996a417303df57b5b644da5b.jpg) Привет, Хабр\! Я хочу рассказать об удивительном событии, о котором я узнал пару месяцев назад. Оказывается, одна популярная python-утилита уже более года распространяется в виде бинарных файлов, которые компилируются прямо из python. И речь не про банальную упаковку каким-нибудь PyInstaller\-ом, а про честную Ahead-of-time компиляцию целого python-пакета. Если вы удивлены так же как и я, добро пожаловать под кат. Объясню, почему я считаю это событие по-настоящему удивительным. Существует два вида компиляции: Ahead-of-time (AOT), когда весь код компилируется до запуска программы и Just in time compiler (JIT), когда непосредственно компиляция программы под требуемую архитектуру процессора осуществляется во время ее выполнения. Во втором случае первоначальный запуск программы осуществляется виртуальной машиной или интерпретатором. Если сгруппировать популярные языки программирования по типу компиляции, то получим следующий список: - Ahead-of-time compiler: C, C++, Rust, Kotlin, Nim, D, Go, Dart; - Just in time compiler: Lua, С\#, Groovy, Dart. В python из коробки нет JIT компилятора, но отдельные библиотеки, предоставляющие такую возможность, существуют давно Смотря на эту таблицу, можно заметить определенную закономерность: статически типизированные языки находятся в обеих строках. Некоторые даже могут распространяться с двумя версиями компиляторов: Kotlin может исполняться как с JIT JavaVM, так и с AOT Kotlin/Native. То же самое можно сказать про Dart (версии 2). A вот динамически типизированные языки компилируются только JIT-ом, что впрочем вполне логично. > При запуске виртуальная машина сначала накапливает информацию о типах переменных, затем после накопления статистики, запускается компиляция наиболее нагруженных частей программы. Виртуальная машина отслеживает типы аргументов и переключает выполнение программы между уже скомпилированными и не скомпилированными участками кода в зависимости от текущих значений переменных. При использовании JIT компиляции типы не очень то и нужны, ведь информация о типах собирается во время работы программы. Поэтому все популярные динамически типизированные языки программирования распространяются именно с JIT компилятором. Но как быть с AOT компиляцией кода, в котором нет типов? Меня очень заинтересовал этот вопрос, и я полез разбираться. Итак, вернемся к утилите, о которой говорилось в начале статьи. Речь про [mypy](http://mypy-lang.org/) - наиболее популярный синтаксический анализатор python-кода. ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/6f3/fb7/42d/6f3fb742d999b54bb8d8bfc3daf1c923) С апреля 2019 года эта утилита распространяется в скомпилированном виде, о чем рассказывается в [блоге](https://mypy-lang.blogspot.com/2019/04/mypy-0700-released-up-to-4x-faster.html) проекта. А для компиляции используется еще одна утилита от тех же авторов — mypyc. Погуглив немного, я нашел достаточно большую статью “[Путь к проверке типов 4 миллионов строк Python-кода](https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python)” про становление и развитие mypy (на Хабре доступен перевод: [часть 1](https://habr.com/ru/company/ruvds/blog/468233/), [часть 2](https://habr.com/ru/company/ruvds/blog/468235/), [часть 3](https://habr.com/ru/company/ruvds/blog/468237/)). Там немного рассказывается о целях создания mypyc: столкнувшись с недостаточной производительностью mypy при разборе крупных python-проектов в Dropbox, разработчики добавили кеширование результатов проверки кода, а затем возможность запуска утилиты как сервиса. Но исчерпав очевидные возможности оптимизации, столкнулись с выбором: переписать все на go или на cython. В результате проект пошел по третьему пути — написание своего AOT python-компилятора. Дело в том, что для правильной работы mypy и так необходимо построить то же синтаксическое дерево, что и интерпретатору во время исполнения кода. То есть mypy уже “понимает” python, но использует эту информацию только для статистического анализа, а вот mypyc может преобразовывать эту информацию в полноценный бинарный код. Думаю тут многие решили, что разобрались в вопросе того, как скомпилировать динамически типизированный python-код. Python c версии 3.4 поддерживает аннотацию типов, а mypy как раз и используется для проверки корректности аннотаций. Получается, python как бы уже и не динамически типизированный язык, что позволяет применить AOT компиляцию. Но загвоздка в том, что mypyc может компилировать и неаннотированный код\! ## Функция bubble\_sort Для примера рассмотрим функцию сортировки “пузырьком”. Файл lib.py: ``` def bubble_sort(data): n = len(data) for i in range(n - 1): for j in range(n - i - 1): if data[j] > data[j + 1]: buff = data[j] data[j] = data[j + 1] data[j + 1] = buff return data ``` У типов нет аннотаций, но это не мешает mypyc ее скомпилировать. Чтобы запустить компиляцию, нужно установить mypyc. Он не распространяется отдельным пакетом, но если у вас установлен mypy, то и mypyc уже присутствует в системе! Запускаем mypyc, следующей командой: ``` > mypyc lib.py ``` После запуска в проекте будут созданы следующие директории: - `.mypy_cache` — mypy кэш, mypyc неявно запускает mypy для разбора программы и получения AST; - `build` — артефакты сборки; - `lib.cpython-38-x86_64-linux-gnu.so` — собственно сборка под целевую платформу. Данный файл представляет из себя готовый CPython Extension. > CPython Extension — встроенный в CPython механизм взаимодействия с кодом, написанным на С/C++. По сути это динамическая библиотека, которую CPython умеет загружать при импорте нашего модуля lib. Через данный механизм осуществляется взаимодействие с модулями, написанными на python. Компиляция состоит из двух фаз: 1. Компиляция python кода в код С; 2. Компиляция С в бинарный .so файл, для этого mypyc сам запускает gcc (gcc и python-dev также должен быть установлены). Файл `lib.cpython-38-x86_64-linux-gnu.so` имеет преимущество перед lib.py при импорте на соответствующей платформе, и исполняться теперь будет именно он. Ну и давайте сравним производительность модуля до и после компиляции. Для этого создадим файл main.py с кодом запуска сортировки: ``` import lib data = lib.bubble_sort(list(range(5000, 0, -1))) assert data == list(range(1, 5001)) ``` Получим примерно следующие результаты: \| \| \| \|---\|---\| \| До \| После \| \| real 5.68user 5.60sys 0.01 \| real 2.78user 2.73sys 0.01 \| Ожидаемо скомпилированный код оказался быстрее (~ в 2 раза), что неплохо, так как для такого результата нам потребовалось запустить лишь одну команду. Хотя от скомпилированного кода привычно ожидаешь большего. ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/5a3/bbe/285/5a3bbe28516bfd798ed394c0e46afaf7) Чтобы ответить на вопрос “как компилируется динамически типизированный код”, придется заглянуть в представление этой функции на С. Но разобрать ее будет достаточно сложно, поэтому давайте попробуем разобраться с примером попроще. ## Функция sum(a, b) Скомпилируем функцию суммы от двух переменных: ``` def sum(a, b): return a + b ``` Перед запуском компиляции я ожидал увидеть примерно следующий код на С: ``` int sum(int a, int b) { return a + b; } ``` Однако результат оказался cущественно иным (код немного упрощен): ``` PyObject CPyDef_sum(PyObject cpy_r_a, PyObject cpy_r_b){ return PyNumber_Add(cpy_r_a, cpy_r_b); } ``` Рассмотрим, что тут происходит. Во-первых, так как мы не знаем типы входных переменных, функция в качестве аргументов принимает указатели на объекты класса PyObject, по сути это внутренние CPython* структуры. Далее компилятор должен сложить эти объекты, но как, если настоящие типы аргументов неизвестны во время компиляции: это могут быть целые числа, числа с плавающей точкой, списки и вообще не факт, что аргументы можно складывать, тогда нужно вернуть ошибку. И что же делает в этом случае mypyc? Как оказалось, все очень просто: он просит CPython самостоятельно сложить эти аргументы. Функция PyNumber\_Add — это внутренняя функция СPython, которая доступна из расширения, ведь **СPython отлично умеет складывать свои объекты. Взаимодействие CPython c Extension можно изобразить следующим диалогом: > — А посчитай-ка мне функцию sum для A, B; > > — Хорошо, но скажи сначала, сколько будет A + B; > > — Будет С; > > — Хорошо, тогда держи ответ - С. Вот такой нехитрый прием используется при компиляции динамического кода: компилируем все, что можем, а все остальное отдаем интерпретатору. Конечно, данный пример выглядит гротескно, но даже несмотря на такую неэффективность, mypyc позволяет добиться существенного прироста производительности, как в примере с сортировкой. ## Функция sum(a: int, b: int) Итак, у нас получилось скомпилировать python, и мы разобрались с тем, как это работает, а также увидели определенную неэффективность полученного результата. Теперь попробуем разобраться в том, как можно это улучшить. Очевидно, что основная проблема заключается во множественном взаимодействии** CPython - Extension. Но как это побороть? Для повышения эффективности, нужно, чтобы расширение, получив управление, могло как можно дольше оставлять его у себя без обращения к CPython. Если бы у mypyc была информация о типах переменных, то он бы мог самостоятельно произвести сложение без возврата управления. Но вывести типы самостоятельно mypyc не может, он даже не контролирует код, из которого осуществляется вызов функции sum. Соответственно, ему нужно помочь, проставив аннотации вручную. Давайте посмотрим, как поменяется результирующая С-функция, если добавить аннотацию типов: ``` def sum(a: int, b: int): return a + b ``` Скомпилированный результат на C (немного очищенный): ``` PyObject CPyDef_sum(CPyTagged cpy_r_a, CPyTagged cpy_r_b) { CPyTagged cpy_r_r0; PyObject cpy_r_r1; cpy_r_r0 = CPyTagged_Add(cpy_r_a, cpy_r_b); cpy_r_r1 = CPyTagged_StealAsObject(cpy_r_r0); return cpy_r_r1; } ``` Главное, что можно заметить: функция существенно поменялась, а значит, компилятор реагирует на появление аннотации. Давайте разбираться, что изменилось. Теперь CPyDef\_sum получает на вход не указатели на PyObject, а структуры CPyTagged. Это все еще не int, но уже и не часть CPython, а часть библиотек mypyc, которую он добавляет в скомпилированный код расширения. Для ее инициализации в рантайме сначала проверяется тип, так что теперь функция sum работает только с int и обойти аннотацию не получится. Далее происходит вызов CPyTaggetAdd вместо PyNumber\_Add. Это уже внутренняя функция mypyc. Если заглянуть в [код](https://github.com/python/mypy/blob/5e20a26b922e2f5b71425ea7f57d2b4cba5a9324/mypyc/lib-rt/int_ops.c#L136) CPyTaggetAdd, то можно понять, что там происходит проверка диапазонов значений a и b, и если они укладываются в int, то происходит простое суммирование, а также проверка на переполнение: ``` if (likely(CPyTagged_CheckShort(left) && CPyTagged_CheckShort(right))) { CPyTagged sum = left + right; if (likely(!CPyTagged_IsAddOverflow(sum, left, right))) { return sum; } } ``` Таким образом, наш диалог CPython - Extension превращается из абсурдного в нормальный: > — А посчитай-ка мне функцию sum для A, B; > > — Хорошо, тогда держи ответ С. ## Функция bubble\_sort(data: List\[int\]) Настало время вернуться к функции сортировки, чтобы провести замеры скорости. Изменим начальную функцию, добавив аннотацию для data: ``` def bubble_sort(data: List[int]): … ``` Скомпилируем результат и замерим время сортировки: \| \| \| \| \|---\|---\|---\| \| Без компиляции \| С компиляцией, без аннотации типов \| С компиляцией и аннотацией типов \| \| real 5.68user 5.60sys 0.01 \| real 2.78user 2.73sys 0.01 \| real 1.32user 1.30sys 0.01 \| Итак, мы получили еще двукратное ускорение относительно скомпилированного, не аннотированного кода, и четырехкратное относительно оригинального\! ![](https://habrastorage.org/r/w1560/getpro/habr/upload_files/1a6/2b9/4e6/1a62b94e684142f6991bf6637ef9ed81) ## Пара слов о mypyc Если вы уже бросились компилировать ваши пакеты, то стоит задержаться на пару минут, чтобы дочитать этот абзац до конца. Главным недостатком mypyc пока остается стабильность: он все еще в альфе, точнее, сейчас это вообще не самостоятельный проект, а часть mypy. Собственно он и создавался специально под задачу увеличения производительности mypy и для этой цели он уже более года как стабилен. Но как общее решение по компиляции любого python-кода, он еще сыроват, о чем авторы предупреждают на странице проекта. Также существуют принципиальные ограничения, накладываемые на компилируемый код или на код, взаимодействующий со скомпилированным: - Принудительная проверка типов в рантайме; - В компилируемом коде запрещается monkey patching; - Mypy хранит классы в С структурах для увеличения скорости доступа к атрибутам, но это приводит к проблемам совместимости. Эти ограничения носят принципиальный характер и являются следствием архитектуры компилятора. Но из них проистекают другие ограничения, например, невозможность использования модуля стандартной библиотеки abc. Помимо этого, есть большая порция недоработок и багов. Чаще всего они приводят к тому, что код gcc отказывается компилировать полученный С код, при этом, чтобы понять настоящую причину ошибки, приходится прокручивать в голове непростую процедуру реверс инжиниринга. Пока результат таков, что при компиляции одного из моих проектов, без проблем компилировалось примерно 20 % модулей, зато каких либо проблем при работе с уже скомпилированными модулями я не заметил. Тем не менее, большая часть улучшений в их Roadmap закрыта, и проект готовится к публичному [релизу](https://github.com/mypyc/mypyc/issues/780). ## Nuitka Уже в процессе работы над статьей, я узнал про еще один проект с аналогичными целями. Механизм работы [Nuitka](https://nuitka.net/) сильно напоминает описанный выше. Разница заключается в том, что Nuitka компилирует Python модуль в С++ код, который также собирается в СPython Extension. Дополнительно существует возможность собрать весь проект в один исполняемый файл, тогда уже сам CPython подключается к проекту как динамическая библиотека libpython. Nuitka пока не учитывает аннотацию типов, поэтому результирующий код и скорость работы не зависят от наличия аннотаций. Полученная же скорость в моем тесте соответствует результату mypy на не аннотированном коде. ## Завершение Недавно один мой коллега высказал мнение, что mypy сильно усложняет ему жизнь: из текста ошибок невозможно понять, “чего он от меня хочет”, а анализатор из PyCharm немного лучше. Теперь я понимаю, что он недооценивает mypy. Так как он намного большее, чем просто синтаксический анализатор. По сути он реализует подмножество языка, потенциал которого в плане оптимизации сильно превосходит обычный python. Поэтому встранивание mypy в пайплайн проекта — инвестиция не только в поиск ошибок, но и будущий перфоманс приложения. Мне очень понравилось, что взаимодействие с CPython осуществляется через механизм расширений интерпретатора, ведь это позволяет сделать выборочную компиляцию наиболее нагруженных модулей, оставив большую часть кода без изменений. Такой путь представляется мне наиболее безопасным (учитывая, что mypyc до сих пор в альфе). Конечно, использовать ли mypyc на продакшене, решать вам, но если вы уже уперлись в потолок по производительности и подумываете о том, чтобы переписать какие-то части на низкоуровневые языки, то стоит попробовать запустить mypyc, тем более, что сделать это просто, если вы уже используете mypy. ## P.S. Надеюсь, вам было интересно узнать о новом способе повышения производительности python, а также глубже разобраться в механизме компиляции динамически типизированного кода. Если тема окажется интересной, то в следующей статье планирую больше рассказать про mypyc, его ограничения и частые ошибки, а также, как их можно обойти. ## UPD В комментариях подсказали, об еще одном python компиляторе - Cython, оказывается теперь он умеет компилировать python код напрямую (минуя ручную фазу преобразования кода в cython\-код). Судя по замерам cython пока [не учитыват](https://github.com/cython/cython/issues/2587) аннотацию типов, но время выполнения (real 1.82) оказалось посередине между результатом mypyc на аннотированном и не аннотированном кода. Но возможно ее добавят в будущем.
Shard	134 (laksa)
Root Hash	14843476518697139734
Unparsed URL	com,habr!/ru/companies/exness/articles/542106/ s443