С пятницей!

#meme #gil

Хм, есть шансы, что шутки про GIL в Python могут уйти в прошлое.

Sam Gross — разработчик из Facebook — предлагает набор изменений, которые удаляют GIL и позволяют Python эффективно утилизировать разные ядра процессора при помощи потоков. Эти изменения слегка замедляют однопоточные программы (которых большинство), но чтобы «подсластить пилюлю» автор также предлагает набор оптимизаций, которые ускоряют питон в целом примерно на 10%. В итоге получается быстрее.

Сообщество активно обсуждает предложение в списке рассылки. Работоспособный форк 3.9 без GIL там тоже прилагается.

https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/

#gil

Для контекста. Ещё 14 лет назад Гвидо сказал, что не позволит удалять GIL ценой замедления однопоточных программ. К тому моменту уже было несколько попыток, которые замедляли однопоточные программы на 30-50%.

https://www.artima.com/weblogs/viewpost.jsp?thread=214235

А новость из поста выше как раз потому и новость, что нет ощутимой просадки по single-threaded перфомансу. Насколько мне известно, это пока что самая успешная из попыток выпилить GIL.

#gil

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

Короче, самой большой проблемой при удалении GIL является сборщик мусора CPython, работающий по принципу счетчика ссылок. Важно, чтобы операции инкремента и декремента счетчика ссылок были атомарными, иначе сборщик мусора может либо удалить ещё используемый объект (и это будет segfault), либо пропустить уже неиспользуемый (утечки памяти). Если просто в тупую защитить операции со счетчиком ссылок при помощи какого-нибудь лока, то производительность интерпретатора сразу же сильно падает, потому что эти операции происходят очень-очень часто. Поэтому нужны более хитрые подходы. Автор предложения придумал три вещи (или скорее не придумал, а вдохновился в других языках).

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

2. Объекты-синглтоны (None, True, False, Ellipsis), а также некоторые числа и строки, бессмертны, они остаются в памяти навсегда. Эти объекты используются практически повсеместно. Тем не менее, в нынешней реализации для них ведётся подсчёт ссылок, что является бессмысленной работой. Вот, предлагается не делать этого. Такие объекты будут помечаться специальным флажком, чтобы сборщик мусора даже не смотрел в их сторону, и подсчёт ссылок для них тоже не будет вестись.

3. Объекты модулей и функций не бессмертны, но они как минимум живут долго. Зачастую они ссылаются друг на друга, образуя циклы, так что счётчики ссылок все равно не помогут понять, когда они перестанут использоваться. Я не совсем понял суть, но кажется, что можно тоже упразднить подсчёт ссылок для таких объектов, и доверить очистку более мудрому и медленному сборщику мусора, который просыпается время от времени, останавливает мир и отлавливает объекты с циклическими ссылками. Это уже реализовано в CPython, если что.

Также были переработаны имплементации списков и словарей, а механизм аллокации памяти был заменён на другой, который лучше работает с многопоточными программами.

Ещё автор применил и другие оптимизации, наверное, чтобы его предложение не было сразу же зарублено на корню, потому что оно все-таки слегка замедляет однопоточный кейс. Скорее всего, эти оптимизации в любом случае попадут в CPython, даже если работу, связанную с GIL, отклонят.

Некоторые бенчмарки показывают ускорение в 18-20 раз при 20 потоках, по сравнению с однопоточным исполнением, то есть Python действительно эффективно утилизирует разные ядра.

https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/

#gil #конспект

Предложение выпилить GIL продолжают активно обсуждать.

На ежегодный Python core development sprint пригласили Sam Gross (автор nogil), и задавали ему много разных вопросов. Все под впечатлением. Всерьёз обсуждается вливание этого экспериментального форка в основной код CPython, но спешить с этим точно не будут, потому что изменения такого масштаба в интерпретаторе потребуют адаптации многих библиотек и пользовательского кода.

Изменение крупное, но если его добавлять небольшими кусками и растянуть этот процесс на несколько лет, то получится избежать Python 4. А Python 4 никто не хочет.

Сэма пригласили присоединиться к числу core-разработчиков интерпретатора. Łukasz Langa будет его менторить.

Пока что всё выглядит очень оптимистично. Ждите Python 3.20 без GIL 😅

https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/

#gil

Обсуждения выпиливания GIL продолжаются.

Недавно Гвидо создал тред по поводу библиотек с нативным кодом, которые никак не защищают свои внутренние данные от других потоков и просто полагаются на наличие GIL, который исключит возможность одновременного доступа к данным. Таких библиотек много, и они начнут ломаться разными неожиданными способами, если просто отнять у них GIL. Нужно найти такой подход, чтобы они не сломались и тем самым не создали ещё одну несовместимую версию языка (никто не хочет повторения истории с 2->3).

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

https://discuss.python.org/t/nogil-mode-and-extensions/11546/11

#gil