#prog #rust #python #performancetrap #article

Rust-Python FFI

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

Внезапный #python

#prog #cpp #python #meme изобличающий

#prog #rust #python #article #suckassstory #performancetrap

Rust std fs slower than Python!? No, it's hardware!

Редкий случай, когда удалось отследить баг и подтвердить, что он действительно в железе. Ссылки на патчи в glibc прилагаются.

TL;DR: оба варианта кода используют mmap в качестве буфера для считывания из файла, но в Python этот буфер используется с некоторым смещением. На некоторых процессорах — в том числе в том, который используется на машине автора — команда rep movsb — которая использовалась в реализации memcpy — парадоксальным образом работает на порядок более медленно при работе с выровненным буфером.

#prog #python #article #suckassstory

node.example.com Is An IP Address

Или про проблему с tipchikami в Python2

#prog #python #article

ABI compatibility in Python: How hard could it be?

Нативные расширения для Python могут распространяться в двух формах: в исходниках и в пресобранных бинарях.

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

Для второго варианта — распространения в заранее собранных бинарях — есть стандартный формат, wheel. Недостатком этого подхода является то, что под каждую комбинацию OS, версии CPython и архитектуры нужно делать свой бинарь, что выливается в дополнительную нагрузку для разработчиков для тестирования под каждую из комбинаций. Вдобавок, если поддерживаемой версии wheel под тройку требований нет, пользователь в пролёте — ему остаётся только собирать самостоятельно. В частности, при релизе новой минорной версии CPython пользователям надо ждать, пока разработчики не соберут wheel под эту новую версию.

Для того, чтобы облегчить жизнь и пользователям, и разработчикам, разработчики CPython предоставили ручки, позволяющие выставлять разработчикам нативных расширений стабильное API со стабильным ABI. С технической точки зрения это выражается в установке макроса Py_LIMITED_API в значение конкретной версии API перед включением заголовочных файлов, предоставляющих интерфейс к CPython. Это стабильное ABI называется abi3, и пакет с нативным расширением может иметь тег, говорящий, что код собран относительно этого ABI конкретной версии.

У этого подхода, однако, есть гигантский недостаток: никакой инструмент цепочки упаковки пакета, его распространения и использования — включая сам CPython — не проверяет, что тег abi3 и конкретная версия выставлены корректно. Иными словами, ничто не останавливает пользователей от того, чтобы подгрузить к интерпретатору расширение с некорректным ABI. Последствия этого также плачевны, как и при любом несовпадении ABI, и могут варьироваться от (при удаче) отсутствия каких-либо проблем до крашей или, что гораздо хуже, порчи памяти.

В Trail of bits разработали инструмент, который как раз и проверяет, насколько расширение, заявленное, как поддерживающее abi3, действительно является таковым. Для исследования того, насколько этот инструмент полезен, авторы статьи проверили пакеты, скаченные с PyPI за последние 21 день (на момент написания статьи, т. е. 15 ноября 2022 года). По части результатов процитирую статью дословно:

Of the 357 valid packages, 54 (15 percent) contained wheels with ABI version violations. In other words: roughly one in six packages had wheels that claimed support for a particular Python version, but actually used the ABI of a newer Python version.

More severely: of those same 357 valid packages, 11 (3.1 percent) contained outright ABI violations. In other words: roughly one in thirty packages had wheels that claimed to be stable ABI compatible, but weren’t at all!

In total, 1139 (roughly 3 percent) Python extensions had version violations, and 90 (roughly 0.02 percent) had outright ABI violations. This suggests two things: that the same packages tend to have ABI violations across multiple wheels and extensions, and that multiple extensions within the same wheel tend to have ABI violations at the same time (which makes sense, since they should share the same build).

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