Comments 16
Почему до сих пор не избавились от алгоритма подсчета ссылок? Разве он не устарел?
Основным плюсом этого алгоритма является то, что объекты удаляются сразу как только они не нужны.
Этот метод практически не уступает по производительности ручному управлению памятью, но при этом позволяет существенно сократить количество присущих ему ошибок. Поддержка кода также упрощается.
А каким алгоритмом собственно предлагаете его заменить?
zhovner tewak
В случае с Python этот метод местами мешает ему, это одна из причин почему до сих пор никто не может избавится от GIL. Если убрать подсчет ссылок, то сразу сломается всё API, которое используют библиотеки, написанные с использованием компилиуремых языков (по сути любые компилируемые модули для питона). Из-за подсчета ссылок любое действие над объектом должно быть безопасным, т.к. постоянно меняется счетчик.
Поэтому убирать в обозримом будущем его никто не будет, это сломает очень большое количество популярных библиотек.
В производительном PyPy есть сразу 6 вариантов GC, которые можно выбирать отталкиваясь от задачи. Они сразу пошли по пути отказа от стандартного API CPython.
В случае с Python этот метод местами мешает ему, это одна из причин почему до сих пор никто не может избавится от GIL. Если убрать подсчет ссылок, то сразу сломается всё API, которое используют библиотеки, написанные с использованием компилиуремых языков (по сути любые компилируемые модули для питона). Из-за подсчета ссылок любое действие над объектом должно быть безопасным, т.к. постоянно меняется счетчик.
Поэтому убирать в обозримом будущем его никто не будет, это сломает очень большое количество популярных библиотек.
В производительном PyPy есть сразу 6 вариантов GC, которые можно выбирать отталкиваясь от задачи. Они сразу пошли по пути отказа от стандартного API CPython.
А почему нельзя использовать atomic integer как счётчик? Это частично решило бы проблему подсчёта ссылок в разных потоках.
Мне кажется всё опять упирается в API, в котором десятки лет четкие инструкции и порядок действий как работать с объектами, многие библиотеки просто сломаются. К тому же это может сильно замедлить работу (среднестатистическому скрипту потребуется более 10 000 atomic счетчиков), при этом не решает всех проблем.
Не очень понял, а почему «удаление потом» не является безопасным и не может использваться с компилируемыми языками? Имеется ввиду что подсчёт ссылок должен работать и вне интерпритатора, в нативном коде? Если да, то как мининмум можно оставить подсчёт ссылок только в нативном коде, а внутри интерпритатора запускать циклический сборщик, который будет учитывать досягаемость до объекта из пайтон кода и наличие ссылок на объект из нативного кода.
Да и вообще был бы очень признателен если бы пояснили почему в питон мире сложилась такая ситуация, что есть официальный CPython с рядом проблем под капотом (GC, GIL, нету JIT) и есть как минимум один кастомный питон (PyPy) в котором эти проблемы решены.
Да и вообще был бы очень признателен если бы пояснили почему в питон мире сложилась такая ситуация, что есть официальный CPython с рядом проблем под капотом (GC, GIL, нету JIT) и есть как минимум один кастомный питон (PyPy) в котором эти проблемы решены.
Я имел ввиду, что компилируемые языки используют CPython C API, в котором при работе с объектами нужно вручную вызывать определенные функции, которые работают со счетчиками, захватывают GIL и т.д. Оставить подсчет ссылок в нативном коде наверное можно, но это будет хак и не решит всех проблем, такое никто не пропустит в Python. Проще начать с чистого листа и выпустить Python 4.
Текущая модель работы с CPython просто не позволяет изменить многие моменты не ломая кучу библиотек (даже тех, которые написаны на чистом Python).
По поводу почему такая ситуация сложилась — тут всё просто, Python уже почти 30 лет, многие вещи проектировались в 90х годах, тогда даже многоядерных процессоров не было. Разработчики Python считают, что нужно поддерживать обратную совместимость. Ну а для полноценного JIT Python непредназначен, уж слишком он динамический сейчас.
Текущая модель работы с CPython просто не позволяет изменить многие моменты не ломая кучу библиотек (даже тех, которые написаны на чистом Python).
По поводу почему такая ситуация сложилась — тут всё просто, Python уже почти 30 лет, многие вещи проектировались в 90х годах, тогда даже многоядерных процессоров не было. Разработчики Python считают, что нужно поддерживать обратную совместимость. Ну а для полноценного JIT Python непредназначен, уж слишком он динамический сейчас.
UFO just landed and posted this here
не всё так однозначно.
есть масса ситуаций(и очень частых) где refcounter наиболее эффективен.
есть масса ситуаций(и очень частых) где refcounter наиболее эффективен.
Если мы заговорили об этом — питон самое слабое место?
Плюсы и минусы всегда зависят от контекста. Например GIL, который часто считают слабым местом — это один из факторов позволивших добиться простой и удобной интероперабельности с Сишным кодом, что является сильной стороной Python.
Я всегда спрашиваю в конкретном контексте. deadone — это не Вам. Если я летал на марс — то я и требую с меня как я летал на марс. Кто ставит минусы опять — автор боится отвечать, ибо и ему прилетит. Уже вон летит.
Если кратко, то GC итерирует каждый объект из выбранных поколений и временно удаляет все ссылки от отдельно взятого объекта (все ссылки на которые этот объект ссылается).
Как GC может обойти все объекты в поколении? Неужели где-то явно есть список всех объектов этого поколения? Мне кажется, такой список занимал бы слишком много места, его дорого было бы поддерживать.
Здесь стоит упомянуть известный опыт instagram, где добились существенного прироста производительности просто отключив сборщик мусора.
Поправочка, они уже включили его обратно. Но к их чести, они сделали патчик в Python 3.7 который решил их предыдущую проблему.
Sign up to leave a comment.
Всё, что нужно знать о сборщике мусора в Python