программистское: о памяти

[avva]

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

Memory leaks are the least of your problems in a compiler; it's not like it's a long running process. You run it, it terminates, the OS cleans up for you.
I did some work on SDCC years ago and it went through a brief "lets use a garbage collector!" phase until everybody realized it was contributing negative value. It was more efficient to simply free memory where convenient and leak it where not.

... и дальше:

I believe it's well known that compilers leak memory like sieves. But the thing is, it doesn't really matter in most contexts. If the leak is linear with the size of the program you're probably fine and no one will notice anyway.

(кстати, всю эту дискуссию о компиляторах стоит проглядеть: там есть немало отличных ссылок)

Это очень полезный совет: иногда в языке и среде, которые казалось бы требуют тщательной работы с malloc()/free() или их эквивалентами, про free() можно просто забыть и не делать, если программа выполняется быстро и не требует очень много памяти. Полезный потому, что привыкший к тщательной дисциплине программист может об этом просто не подумать.

Но мне это напомнило еще вот какую давнюю мысль: по-моему, намного реже, чем следовало бы, программисты на языках с эксплицитной обработкой памяти пользуются отдельными кучами. "Отдельная куча" (private heap) означает всего лишь возможность отводить память в отдельном месте, идентифицируемом каким-то ключом. Например, в Win32 есть функции: HeapCreate() создает новую кучу и возвращает идентификатор, HeapAlloc() - вместе с желаемым размером получает идентификатор кучи и отводит память именно в ней, HeapFree() - очевидно, и HeapDestroy() - удалить всю кучу вместе со всей памятью в ней, которой еще не сделали HeapFree().

Иногда это называют не кучей, а "ареной", но суть та же. На самом деле самое главное во всем этом - возможность удалить кучу одним махом, потому что если она есть, и если вся память, что отводится из кучи, вместе не слишком велика, то отдельно освобождать ничего не надо. Собственно, можно обойтись без free() вообще. Куча тогда превращается в сплошной кусок памяти (или связанный список таких кускок, если надо), а malloc() становится тривиальным, он просто двигает указатель на свободную часть кучи.

Очень часто значительная часть логики программы устроена так. Начинаем строить какой-то объект (в C это может быть сложная структура, неважно), он в свою очередь создает и инициализирует другие объекты внутри себя, или целые массивы, или списки, или еще что, неважно. Все это по цепочке вложено друг в друга, а после создания еще начинает как-то работать и двигаться вместе, вызывать друг друга, хранить какую-то информацию итд. В конце концов объект выполнил свое дело и удаляется, по цепочке вначале удаляя все вложенные объекты и контейнеры и освобождая всю память. Все это делается через сложный танец new/delete или malloc/free. Но если вся память, что нужна объекту и всему, что в него вложено, не слишком велика на протяжении его жизни, то с помощью отдельной кучи только для этого объекта и всего, что в него вложено, можно избежать всего этого сложного танца и сделать код одновременно намного проще, лучше защищенным от ошибок и даже быстрее - да-да, быстрее, чем обычный танец malloc/free. Единственное, чем платишь - повышенным расходом памяти во время жизни объекта, да и то часто налог этот весьма невелик.

Я уже лет десять как не пишу под Windows, но до сих пор помню, какими полезными и правильными были функции для работы с отдельными кучами. Конечно, каждый может сам на коленке сколотить что-то свое для этого; я не раз такое встречал, да и сам несколько раз писал. Но все же меня удивляет, что в Юниксе нет стандартного интерфейса для этого дела. И я не раз видел исходники библиотек или приложений, которые бы этот простой прием сильно упростил и улучшил.

Comments

[http://users.livejournal.com/_navi_/]

А чем конкретно полезно это специфичное WinAPI для использования арен? Тем, что за тебя уже определён какой-то кастомный HeapAlloc, который наверняка содержит в себе что-то лишнее для данной проблемы, как минимум работу с фри-листами (вместо того, чтобы дать программисту возможность задать оптимальный алгоритм аллокации для арены)?

[(Anonymous)]

Мне нравится что я понимаю о чем ты говоришь. Я начал изучать C/С++ нерегулярно и для себя, непрограммиста (вернее в далеком прошлом).
Как не крути это высокая поэзия (разговоры о распределении памяти), хотя, видимо программирование уже давно ремесло.
Вообщем, мы все умрем:)

[egorfine.livejournal.com]

Сейчас программирую под айфон - приходится очень внимательно относиться к памяти. Даже местный memory manamement в objc не спасает, надо ручками. Всего 128 мег памяти, из них приложению доступно в самый максимум сто мег.

[avva.livejournal.com]

Вы почитайте вот, вдохновитесь:

http://jordanmechner.com/wp-content/uploads/1989/10/popsource009.pdf

Особенно стр. 4 этого документа. Это к вопросу о "максимум сто мег".

[avva.livejournal.com]

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

То, что HeapAlloc() использует свой конкретный алгоритм, и в частности не так быстр, как, например, алгоритм сплошной аллокации без освобождения - в 99.99% случаев абсолютно неважно и никакой роли не играет. Давайте не забывать слова Кнута о преждевременной оптимизации.

[ygam.livejournal.com]

Быстродействие — 20 тыс. оп./с. Оперативное ЗУ на ферритных сердечниках (16 384 слова, слова 45-разрядные).

[izblank.livejournal.com]

Мы сейчас похожую стратегию к нашей базе данных думаем применить. Вместо того, чтобы заботиться о партициях, foreign keys, и прочих заморочках, просто посылать все новое в другую базу, а старую по происшествии какого-то времени дропнуть, и все дела. И так каждый год.

[http://users.livejournal.com/_navi_/]

Ну обычно арены просто так совсем без повода не используются, так что вопрос преждевременной оптимизации наверно не стоит. Иначе можно и обычным malloc'ом обходиться.

Про часть арсенала аргумент хороший, тут согласен.

[(Anonymous)]

Как не профи я все-таки не понимаю, почему бы os не чистить автоматически то что было сделано приложением. Такой большой брат следит за всеми malloc/new и потом все чистит.Есть что-то невозможное в этом?

[(Anonymous)]

Она и чистит. По завершению процесса.
До завершения она ведь не знает, когда именно что можно очистить.

[wizzard]

Когда приложение завершилось - мы точно знаем, что ему _ничего_ не нужно. Пока оно работает - ему что-то нужно, а что-то не нужно. Сложно именно определить, что именно.

[(Anonymous)]

Хорошо, запустили процесс, определили для процесса предельные величины использования памяти, типа, всего допустимой для выделения памяти/кол-во процессов. Дальше нужно os должна следить не за абсолютными величинами, а за динамикой и new - вдруг программер ошибся, возвращает указатели на аллоокированные куски из процедуры и т.д. можно придумать некие предыгадывающие механизмы, которые говорили бы os что девелопер ох..л или прога неправильно работает. По-моему, кол-во таких ситуаций конечно.

[msh.livejournal.com]

Memory leaks are the least of your problems in a compiler; it's not like it's a long running process. You run it, it terminates, the OS cleans up for you.

недавний пост одного из моих friends

Сборка libtorrent-rasterbar 0.14.6 уложила мне виртуальную машину, run out of swap space. Гиг памяти и гиг свопа.

[avva.livejournal.com]

Это почти наверняка линкер (или он запустил слишком много параллелизации).

[avva.livejournal.com]

Есть утилиты для отладки, которые именно так работают: следят за динамикой итд. Операционной системе в целом нет смысла этим заниматься, потому что она ничего интересного о приложении не знает, и ничего с ним не может сделать, кроме как убить; но если там какой-то баг или память сильно протекает, оно скорее всего и так произойдет. А если бы ОС на основании динамики выделения памяти пыталась убить приложение, то поубивала бы неизбежно кучу легитимных приложений с необычной динамикой памяти.

[avva.livejournal.com]

Я ж как раз говорю, что их стоит чаще использовать, и что они могут быть лучше обычного malloc'a не только из-за скорости выполнения, но и по другим причинам - упрощают код, защищают от утечек итд.

[msh.livejournal.com]

Компилятор распухает очень сильно, когда в коде много templates (например, boost, как в упомянутом случае). А что касается параллелизации - ну так нынче везде как минимум 4 cores, а может даже и 8, конечно, все собирают make -j

"в компиляторе можно не заботиться о memory leaks" это "640K ought to be enough for anybody". Через несколько лет все компьютеры будут 64-битные и с 16-32 CPUs, а вот размер памяти в такой же пропорции не вырастет

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

[breqwas.livejournal.com]

О, эти суровые времена, когда компьютеры были большими, когда men were men и сами писали драйвера для железа...


Ну что за подход, а? Ресурсов всегда не хватает, аксиома. Привыкнув к тому что 12гбайтный файл можно утянуть в память, отсортировать и иметь по нему быстрый доступ, очень трудно начать снова считать мегабайты. И когда это приходится делать - это неприятно.

Принца персии уместили в 130 кб, здорово. Но только принц персии - один, и графика там однообразна. А игр под айфон наверняка уже много, разных и более красочных. Это происходит в т.ч. от роста кол-ва ресурсов (и влезает больше, и программировать проще). И это - хорошо.

Собственно, кому я это говорю.


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

[nine_k]

Что до раздельных куч, то этот приём активно применялся, помнится, в Doom. Как раз для быстрой очистки всех ненужных объектов.
А ещё в древнем паскале (не помню версии, может, это ещё от Вирта идёт) для кучи были процедуры mark и release. Говоришь mark, делаешь какие хошь аллокации, говоришь release, куча сдувется обратно до состояния на момент mark. Но с раздельными удобнее.

[avva.livejournal.com]

Во-первых, не авторы, а автор.

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

В-третьих, да, все это верно, и я не призываю, конечно, всерьез втискиваться в сотни килобайтов в современной программе. Но уметь внимательно следить за памятью - не всегда, и везде, но в важных местах - все еще полезно, и полагаю, полезным быть в ближайшие лет 30 не перестанет.
И в этом смысле вышеприведенный документ меня несоменно вдохновляет. Смысл из него следует выносить не тот, что давайте все вернемся к 16-битной графике и запихаем ее в килобайты. А тот, что вот пример человека, который очень хорошо понимал и мог рассчитать, где у него ресурсы расходуются и на что. И умел там, где это надо, оптимизировать. Умение это неизбежно пригодится - не с 12-гигабайтным файлом, так с 50-гигабайтным.

[avva.livejournal.com]

может, он сделал -j32, кто его знает? В компилятор, съедающий на бусте 2 гигабайта, мне верится слабо.

Вот насчет кэша это справедливо сказано, да. Но не всегда это важно.

[msh.livejournal.com]

Ну я сам видел компилятор съедающий несколько сотен мегабайт, так что с -j5 гигабайт памяти легко, а сколько будет свопа - зависит от оптимизма.

Что важно и что неважно - это интересный вопрос. За весьма недолгое время все изменилось несколько раз -

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

- диск медленный, процессор быстрый. На диске только самые необходимые данные, причем часто компрессированные

- Память быстрая и много. Все кэшируется, кэшируется.

- Процессор гораздо быстрее памяти. Опять стараются минимизировать working set.

- Процессор слабый, зато их много. Как работает одна программа вообще неважно, важно как они работают все вместе.

Совет что можно особенно не париться с освобождением памяти вовремя был верен несколько лет назад, когда появилась быстрая и дешевая DDR. Сейчас опять главный bottleneck - memory bandwidth. Скоро, думаю, вообще ничего не будет важно по сравнению с минимизацией интеракций между разными процессами - потому что кэши будут большие, а bottleneck будет cache coherency

[m0riarty.ya.ru (from livejournal.com)]

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

[rxvm.livejournal.com]

4G памяти - это на самом деле очень мало. Я сталкивался с тем, что некий нехорошиий (сгенерированный) С-код в несколько сотен строк крешится на некоторых уважаемых компиляторах из-за нехватки 32-битного адресного пространства.

Память, в отличие от run-time, плохо масштабируется: в какой-то момент уже небольшой рост приводит к тому, что процесс падает или уходит в свап. Это, в частности, одна из проблем в model checking: ты можешь согласиться с тем, чтобы ждать недели, пока экспоненциальный алгоритм даст тебе ответ, но с экспоненциального размера моделью просто невозможно работать.

Private heap - хорошая штука.

[(Anonymous)]

Кому надо, делает не на коленке, а на столе, как человек :)

Например, в рантайме апача имеется соответствующая подсистема. В веб-сервере (и в любом stateless сервере) это единственная разумная стратегия работы с памятью. Память, связанная с запросом, живет не дольше, чем сам запрос. В апаче все еще несколько удобнее: пул может быть частью другого пула. Можно прибить пул и вместе с ним освобождаются все его дети. А освобождение кусков внутри пула не предусмотрено, ибо незачем.

Пы. Сы. В Калифорнийщину по поводу Хрома ездили?