Pull to refresh

Comments 29

Instagram использует на сервере CPython? Чего-то я не понимаю в змеях...

Неясна реальная логика вызова GC в finalize(). Зачем собирать мусор, если все равно всю память при выходе отдавать? Молодцы, что поймали.

Интересно, правда, а чем было в итоге вызвано то, что «пострадали только машины со старыми моделями процессоров (Sandy Bridge)» во время одного из экспериментов? Это же нелогично, когда абстракция минимум третьего уровня является процессорно-зависимой.
Неясна реальная логика вызова GC в finalize(). Зачем собирать мусор, если все равно всю память при выходе отдавать?

Какая-нибудь очистка ресурсов может быть завязана на уничтожении объекта сборщиком.
Обьект может иметь деструктор, выполняющий нетривиальные действия. Например, сохранения статистики о использовании обьекта. Уборщик мусора вызывается, чтоб не пропустить такие деструкторы.

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

Python — это не «язык со сборкой мусора». Это «язык со сборкой мусора сбоку».

Он на счётчиках ссылок построен — до весии 2.0 в нём вообще ничего другого не было, но и сейчас — они используются тоже. GC — это, так сказать, «вторая линия обороны».

Поскольку финализаторы вызываются, в большинстве случаев, известно где — то многие на них полагаются (хотя, теоретичнски и не должны, так как существуют всякие Jython'ы — но кто их реально использует-то?).

Я даже при программировании на C++ не полагаюсь на деструкторы, да и вообще, не сторонник RAII-идиомы, т.к. считаю, что деструктор должен быть простым и иметь минимум побочных эффектов.


Если программист не освободил ресурс явно, значит, в программе имеется ошибка, требующая исправлений. В этом плане подход Java/C# с паттерном IDisposable мне более приятен.

Я даже при программировании на C++ не полагаюсь на деструкторы, да и вообще, не сторонник RAII-идиомы, т.к. считаю, что деструктор должен быть простым и иметь минимум побочных эффектов.
К сожалению или к счастью, но вы не пишите все компоненты, которые использует инстаграмм. RAII — это весьма распростанённый паттерн в С++ (по большому счёту без него написать сколько-нибудь надёжную программу с использованием исключений просто не получится, замучаятесь ловить и пробрасывать исключения) и многие используют его и в Python'е (хотя там есть и более надёжная альтернатива).

Если программист не освободил ресурс явно, значит, в программе имеется ошибка, требующая исправлений.
С чего вдруг? При использовании счётчиков ссылов (Python, Objective C, Swift) или вещей типа unique_ptr (в C++) выход переменной из области видимости гарантирует освобождение ресурса именно в этой точке.

То что вам этот подход не нравится по непонятной причине — не значит, что другие его не будут использовать.

Подход, который вы проповедуете (нет исходного кода == нет сгенерённого кода) это — скорее C, не C++ или Python.
К сожалению или к счастью, но вы не пишите все компоненты, которые использует инстаграмм. RAII — это весьма распростанённый паттерн в С++ (по большому счёту без него написать сколько-нибудь надёжную программу с использованием исключений просто не получится, замучаятесь ловить и пробрасывать исключения)

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


Проблема C++ в том, что в нём нет finally. Приходится пихать в деструктор то, что можно было бы поместить в finally. Но коварство деструкторов заключается в том, что с исключениями они дружат очень плохо. Если коротко: не пишите код, который может в деструкторе бросить исключение.


С чего вдруг? При использовании счётчиков ссылов (Python, Objective C, Swift) или вещей типа unique_ptr (в C++) выход переменной из области видимости гарантирует освобождение ресурса именно в этой точке.

Да я не против unique_ptr, я против того, чтобы в деструкторе содержалась навороченная логика.

Нет, конкретно в питоне деструкторы автоматические. Хотя вы можете их вызывать явно, если хотите.
Неясна реальная логика вызова GC в finalize(). Зачем собирать мусор, если все равно всю память при выходе отдавать? Молодцы, что поймали.


Python же рассчитан на работу не только в операционках с поддержкой виртуальной памяти. Его ещё и просто встраивать можно.

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

Очень спорно. Важно просто контролировать GC pressure и не выделять память направо и налево. Даже с GC есть языки и платформы дающие возможность детерминированного контроля памяти в некоторых случаях.
Дело не в самой сборке мусора, а в том, насколько она эффективна. В Python за эффективностью никто никогда не гонялся. Ну и, обычно, когда действительно важна скорость, то, скорее всего, Вы просто непишете некий custom-вариант сборки мусора. Размазывать malloc/free по коду тоже не самая лучшая практика для повышения произвоидтельности.
если честно, для меня выглядит как «мы потратили вагон человеко-часов и поставили под угрозу стабильность системы для того чтобы платить на 10% меньше за сервера».

конечно, в случае инстаграмма 10% экономии на серверах может стоить десятки/сотни тысяч долларов в месяц, но сколько капитализации они потеряют если их сервис упадёт на пару часиков потому что какая-нибудь dependency будет делать неочевидные вещи в деструкторе своих классов? как отмечается выше, своими действиями они выпилили защиту от такого рода проблем убрав вызов GC в finalize().
Ну, наверное, они достаточно хорошо знают о своих зависимостях, чтобы не рисковать.
сдаётся мне, они этим шагом ещё и повысили минимальную квалификацию программиста, работающего с их code base до уровня «выше некуда». просто senior уже не канает. ибо имея такие хаки в коде не наступить на грабли становится всё труднее. так что потенциальных рисков они себе добавили ого-го, дело не только в зависимостях.
Госсподя! Вы, я надеюсь, понимаете, что GC в Python — это необязательный компонент? До версии 2.0 его там вообще не было, а обязательным он стал только с версии 2.3!

Так что они, фактически, просто вернули режим в котором Python существовал много лет…

И много вы знаете успешных проектов написанных на Python за те «много лет», что в нем не было сборки мусора?

А много вы знаете вообще успешных проектов тех лет? Все управляющие скрипты RedHat'а и SuSE, Gentoo и Debian'а, всякие Bittorrent'ы и SCons — всё это и многое другое было написано именно «на той» версии Python'а.
нет, не понимаю. спасибо, что объяснили. но судя по release history, версия 2.0 вышла в 2000 году, а версия 2.3 вышла в 2003. с тех пор прошло больше лет, чем питон существовал без GC.

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

но сколько капитализации они потеряют если их сервис упадёт на пару часиков потому что какая-нибудь dependency будет делать неочевидные вещи в деструкторе своих классов?
Как показывает опыт — почти нисколько.

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

, то сомневаюсь, что они на электричестве сэкономили 1-100 миллионов долларов.
единоразовой экономии на средствах на закупку железа (что тоже ничтожно в контексте хотя бы года работы сервиса)
Конечно Instagram (как и сам Facebook, как и Google и как все другие «большие» компании) покупают железо со скидкой, но она всёж-таки не настолько велика.

, то сомневаюсь, что они на электричестве сэкономили 1-100 миллионов долларов.
Могли и больше экономию получить. Вы вообще учитываете, что речь идёт о сервисе с почти миллиардом пользователей? Сколько, по вашему, потребуется ресурсов чтобы хранить 200 миллиардов фоток?

Вас не удивляет тот факт, что Google входит в пятёрку крупнейших производителей серверов в мире — где-то сразу после HP, Dell'а и IBM? Притом что Google, в общем-то, серверами не торгует?

Понятно что Instagram и Facebook «поменьше будут» — но они тоже тратят на железо суммы, измеряемые в миллиардах. Так что 10% легко могу дать экономию не в один миллион.
Так вы это в Instagram-е или в Wunderfund-е отключали? Или у вас в Wunderfund-е свой собственный Instagram?

Читатели упорно продолжают не замечать ярлык "Перевод"...

Ок, ладно, не заметил. А ссылку на оригинал тоже только я не вижу?
На мобильном вверху, под заголовком; на дексктопе — внизу, вот тут:

image

Там же метка "перевод" стоит. Instagram это с полгода назад у себя в блоге публиковал.

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
wunderfund.io
Employees
11–30 employees
Registered