MATLAB Сборщик мусора?

Ответ 1

Вот список фактов, которые я собрал. Вместо GC термин memory (de) в этом контексте представляется более подходящим.

Мой основной источник информации - это блог Лорен (особенно его комментарии) и эта статья из MATLAB Digest.

Благодаря своей ориентации на числовые вычисления с возможными большими наборами данных, MATLAB действительно делает хорошую работу по оптимизации характеристик стека, как при использовании операции с данными на месте и call-by-reference на аргументы функции. Также из-за своей ориентации его модель памяти принципиально отличается от таких языков OO, как Java.

MATLAB официально не определял пользовательскую память кучи до версии 7 (в версии 6 в документах schema.m была недокументирована reference). MATLAB 7 имеет кучу как в виде вложенных функций (закрытий) и объектов обработки, их реализация имеет одни и те же основы. В качестве дополнительной заметки OO может быть эмулировать с закрытием в MATLAB (интересно для pre-2008a).

Удивительно, что можно просмотреть всю рабочую область закрывающей функции, захваченной дескриптором функции (замыкание), см. функцию функции (fhandle) в Справка MATLAB. Это означает, что закрытие рабочего пространства замерзает в памяти. Вот почему cellfun/arrayfun иногда очень медленны при использовании внутри вложенных функций.

Есть также интересные сообщения Loren и Brad Phelan об очистке объектов.

Наиболее интересным фактом, касающимся освобождения кучи в MATLAB, является, на мой взгляд, то, что MATLAB пытается сделать это каждый раз, когда стек освобождается, т.е. оставляя каждую функцию. У этого есть преимущества, но также является огромным штрафом ЦП, если сброс кучи медленный. И в некоторых сценариях это очень медленно в MATLAB!

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

Линейное увеличение размера пула для ссылочных объектов означает полиномиальное (или экспоненциальное) снижение производительности MATLAB! Для объектов значений производительность, как и ожидалось, линейна.

Учитывая эти факты, я могу только предположить, что MATLAB использует еще не очень эффективную форму отсчета ссылок для освобождения кучи.

EDIT. Я всегда сталкивался с проблемой производительности со многими небольшими вложенными функциями, но недавно я заметил, что по крайней мере с 2006a очистка одной вложенной области с некоторыми мегабайтами данных также ужасна, требуется 1,5 секунд, чтобы установить вложенную переменную области видимости пустым!

EDIT 2: наконец, я получил ответ - сам Дейв Фоти. Он признает недостатки, но говорит, что MATLAB собирается сохранить свой нынешний детерминированный подход к очистке.

Легенда: более короткое время выполнения

Ответ 2

MATLAB делает рабочее пространство очень понятным в браузере Workspace или с помощью команды "whos". Это показывает вам все объекты, созданные вашими командами, и сколько памяти они занимают.

feature('memstats')

покажет вам самый большой непрерывный блок памяти, доступный для MATLAB, что означает, что это самая большая матрица, которую вы можете создать. Использование команды "clear" будет синхронно удалять эти объекты из памяти и освобождать пространство, которое будет использоваться снова.

JVM обрабатывает сбор мусора только для элементов Java. Поэтому, если вы открываете файл в редакторе и закрываете его, Java заботится об удалении окна и текста и т.д. Из памяти. Если вы создаете объект Java в рабочем пространстве MATLAB, он сначала должен быть очищен, а затем он может быть очищен jvm.

Там много информации об управлении памятью программы в нашем technote: http://www.mathworks.com/support/tech-notes/1100/1106.html

И я недавно писал о работе с памятью Java в блоге MATLAB Desktop: http://blogs.mathworks.com/desktop/2009/08/17/calling-java-from-matlab-memory-issues/

Если вам интересно узнать, что происходит с выделенной памятью, когда функция выходит или когда вы изменяете размер переменной... Я почти уверен, что торговый секрет и он меняет каждый выпуск. Вы никогда не заметите этого, и если у вас возникнут проблемы с производительностью, которые, как вы подозреваете, связаны с управлением объектами, пожалуйста, отправьте справку с технической поддержкой: http://www.mathworks.com/support

Ответ 3

Кажется, вы пытаетесь построить какой-то аргумент Python vs MATLAB. Меня не интересует этот аргумент.

Мета-ответ на ваш мета-вопрос.

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

Чем больше вы знаете о текущем механизме управления памятью, тем более вероятно, что вы будете защищать оборону от этой конкретной реализации, тем более вероятно, что вы не выиграете от будущих улучшений производительности. Несколько хороших примеров этого можно найти в Java gc, написанном Брайаном Гетцем на developerworks.com:

http://www.ibm.com/developerworks/library/j-jtp01274.html

Вы можете сказать, что это важно знать. Я отвечаю, что все это касается требований. Более подходящий вопрос заключается в том, соответствуют ли языки, которые я рассматриваю для моего проекта, для удовлетворения моих потребностей с точки зрения производительности, усилий по разработке, ремонтопригодности, переносимости, опыта моих разработчиков и т.д. И т.д.?

Я никогда не видел проект с требованием использовать генерацию gc над меткой sweep по подсчету ref. Я не ожидаю скоро увидеть его.