Комментарии 29
Instagram использует на сервере CPython? Чего-то я не понимаю в змеях...
Интересно, правда, а чем было в итоге вызвано то, что «пострадали только машины со старыми моделями процессоров (Sandy Bridge)» во время одного из экспериментов? Это же нелогично, когда абстракция минимум третьего уровня является процессорно-зависимой.
Неясна реальная логика вызова GC в finalize(). Зачем собирать мусор, если все равно всю память при выходе отдавать?
Какая-нибудь очистка ресурсов может быть завязана на уничтожении объекта сборщиком.
А разве в языках со сборкой мусора не предписывается в таких случаях вызывать функцию уничтожения объекта явно? Финализаторы нужны на крайний случай, когда программист забыл освободить ресурсы явно.
Он на счётчиках ссылок построен — до весии 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 же рассчитан на работу не только в операционках с поддержкой виртуальной памяти. Его ещё и просто встраивать можно.
Наконец-то до многих начало доходить очевидная вещь, что когда важна скорость работы, то сборкой мусора лучше не пользоваться.
конечно, в случае инстаграмма 10% экономии на серверах может стоить десятки/сотни тысяч долларов в месяц, но сколько капитализации они потеряют если их сервис упадёт на пару часиков потому что какая-нибудь dependency будет делать неочевидные вещи в деструкторе своих классов? как отмечается выше, своими действиями они выпилили защиту от такого рода проблем убрав вызов GC в finalize().
Так что они, фактически, просто вернули режим в котором Python существовал много лет…
И много вы знаете успешных проектов написанных на Python за те «много лет», что в нем не было сборки мусора?
ещё стоит учесть что с годами софта пишется всё больше, так что импакт доGCшного питона на инстаграм в той части, которую затрагивают эти хаки ничтожен. сомневаюсь, что какой-то используемый ими код дожил с 2003 до 2017 без изменений.
конечно, в случае инстаграмма 10% экономии на серверах может стоить десятки/сотни тысяч долларов в месяцВы потеряли пару, а то и тройку нуликов в своих оценках.
но сколько капитализации они потеряют если их сервис упадёт на пару часиков потому что какая-нибудь dependency будет делать неочевидные вещи в деструкторе своих классов?Как показывает опыт — почти нисколько.
Да, в момент, когда оно всё упадёт — капитализация может скакнуть вниз довольно серьёзно, но если потери данных не будет, то уже через неделю-другую об этом все забудут.
— экономии на электричестве
— экономии на рабочих часах обслуживающего персонала (что скорее всего влияет слабо, ибо всё делается автоматически и не зависит от количества серверов)
— единоразовой экономии на средствах на закупку железа (что тоже ничтожно в контексте хотя бы года работы сервиса)
, то сомневаюсь, что они на электричестве сэкономили 1-100 миллионов долларов.
единоразовой экономии на средствах на закупку железа (что тоже ничтожно в контексте хотя бы года работы сервиса)Конечно Instagram (как и сам Facebook, как и Google и как все другие «большие» компании) покупают железо со скидкой, но она всёж-таки не настолько велика.
, то сомневаюсь, что они на электричестве сэкономили 1-100 миллионов долларов.Могли и больше экономию получить. Вы вообще учитываете, что речь идёт о сервисе с почти миллиардом пользователей? Сколько, по вашему, потребуется ресурсов чтобы хранить 200 миллиардов фоток?
Вас не удивляет тот факт, что Google входит в пятёрку крупнейших производителей серверов в мире — где-то сразу после HP, Dell'а и IBM? Притом что Google, в общем-то, серверами не торгует?
Понятно что Instagram и Facebook «поменьше будут» — но они тоже тратят на железо суммы, измеряемые в миллиардах. Так что 10% легко могу дать экономию не в один миллион.
О том, как в Instagram отключили сборщик мусора Python и начали жить