Question Le ramasse-miettes de MATLAB?


Quel est votre modèle mental? Comment est-il mis en œuvre? Quelles sont ses forces et ses faiblesses? MATLAB GC vs Python GC?

Je vois parfois d'étranges goulots d'étranglement lors de l'utilisation de fonctions imbriquées MATLAB dans un code à l'apparence anormale, je suis sûr que c'est à cause du GC. Garbage Collector est une partie importante de VM et Mathworks ne le rend pas public.

Ma question concerne les propres MATLAB tas et GC! Pas sur la gestion des objets Java / COM / prévention des erreurs de mémoire / allocation des variables de la pile.

MODIFIER: la première réponse est en fait la méta-réponse "Pourquoi devrais-je m'en soucier?". Je m'inquiète parce que GC se manifeste lors de la mise en œuvre liste liée ou MVC modèle.


27
2017-09-18 18:51


origine


Réponses:


C'est la liste des faits que j'ai recueillis. Au lieu de GC le terme allocation mémoire (de) semble être plus approprié dans ce contexte.

Ma principale source d’information est le blog de Loren (notamment ses commentaires) et ce article de MATLAB Digest.

En raison de son orientation pour le calcul numérique avec d’éventuels grands ensembles de données, MATLAB fait un excellent travail d’optimisation empiler des objets la performance comme l'utilisation opérations sur place sur les données et appel par référence sur les arguments de fonction. En raison de son orientation, son modèle de mémoire est fondamentalement différent à partir de langages OO tels que Java.

MATLAB n'avait officiellement aucune mémoire de tas définie par l'utilisateur jusqu'à la version 7 (dans la version 6, il n'y avait pas de document reference fonctionnalité dans schema.m des dossiers). MATLAB 7 a accumulé les deux sous forme de fonctions imbriquées (fermetures) et objets manipulés, leur mise en œuvre partage les mêmes fondements. En guise de note, OO pourrait être émulé avec fermetures dans MATLAB (intéressant pour la pré-2008a).

Étonnamment, il est possible d’examiner tout l’espace de travail de la fonction englobante capturée par la poignée de fonction (fermeture), voir la fonction fonctions (poignée) dans l'aide de MATLAB. Cela signifie que l'espace de travail est en train d'être congelé en mémoire. C'est pourquoi cellfun/arrayfun sont parfois très lents lorsqu'ils sont utilisés dans des fonctions imbriquées.

Il y a aussi des billets intéressants par Loren et Brad Phelan sur le nettoyage des objets.

Le fait le plus intéressant à propos de la désallocation de tas dans MATLAB est, à mon avis, que MATLAB essaie de le faire chaque fois que la pile est libérée, c'est-à-dire en quittant chaque fonction. Cela a avantages mais est également une énorme pénalité CPU si la désallocation de tas est lente. Et en fait, il est très lent dans MATLAB dans certains scénarios!

Les problèmes de performances de la désallocation de mémoire MATLAB qui peuvent frapper du code sont plutôt graves. Je remarque toujours que j'introduis involontairement des références cycliques dans mon code quand il tourne soudainement plus lentement x20 et nécessite parfois quelques secondes entre le départ de la fonction et le retour à l'appelant (temps passé à nettoyer). C'est un problème connu, voir Dave Foti et cet ancien post du forum quel code est utilisé pour rendre cette image visualisant les performances (les tests sont effectués sur des machines différentes, donc la comparaison temporelle absolue des différentes versions de MATLAB n'a pas de sens):

L'augmentation linéaire de la taille du pool pour les objets de référence signifie une diminution polynomiale (ou exponentielle) des performances MATLAB! Pour les objets de valeur, les performances sont, comme prévu, linéaires.

Compte tenu de ces faits, je ne peux que spéculer sur le fait que MATLAB utilise une forme non encore très efficace de comptage de référence pour la désallocation de tas.

MODIFIER: J'ai toujours rencontré des problèmes de performance avec beaucoup de petits fonctions imbriquées mais récemment, j'ai remarqué qu'au moins avec 2006a le nettoyage d'un portée imbriquée unique avec quelques mégaoctets de données est également terrible, il faut seulement 1,5 secondes pour définir la variable de portée imbriquée à vider!

EDIT 2: enfin j'ai eu la réponse - par Dave Foti lui-même. Il reconnaît les failles mais dit que MATLAB va conserver son approche actuelle de nettoyage déterministe.

Légende: Un temps d'exécution plus court est préférable

R2006a R2008a R2009a


44
2017-09-28 22:50



MATLAB rend l'espace de travail très clair dans le navigateur de l'espace de travail ou avec la commande "whos". Cela vous montre tous les objets créés par vos commandes et combien de mémoire ils prennent.

feature('memstats')

affichera le plus grand bloc de mémoire contigu disponible pour MATLAB, ce qui signifie que c'est la plus grande matrice que vous pouvez créer. L'utilisation de la commande "clear" supprime de manière synchrone ces objets de la mémoire et libère l'espace à utiliser à nouveau.

La machine virtuelle Java gère uniquement le nettoyage des éléments Java. Donc, si vous ouvrez un fichier dans l'éditeur et le fermez, Java prend soin de supprimer la fenêtre et le texte, etc. de la mémoire. Si vous créez un objet Java dans l'espace de travail MATLAB, il doit d'abord être effacé, puis il peut être nettoyé par le jvm.

Il y a beaucoup d'informations sur la gestion de la mémoire du programme dans notre note technique: http://www.mathworks.com/support/tech-notes/1100/1106.html

Et j'ai récemment écrit sur la gestion de la mémoire Java sur le blog MATLAB Desktop: http://blogs.mathworks.com/desktop/2009/08/17/calling-java-from-matlab-memory-issues/

Si vous vous intéressez académiquement à ce qui arrive à la mémoire allouée lorsqu’une fonction s’arrête ou quand vous redimensionnez une variable, je suis sûr que c’est un secret commercial et que cela change à chaque version. Vous ne devriez jamais le remarquer, et si vous rencontrez des problèmes de performances que vous soupçonnez être liés à la gestion des objets, veuillez déposer un ticket d'aide avec le support technique: http://www.mathworks.com/support


13
2017-09-19 12:03



Il semble que vous essayiez de construire une sorte d'argument Python vs MATLAB. Je ne suis pas intéressé par cet argument.

Une méta-réponse à votre méta-question.

Il est en effet assez important que vous ne vous souciez pas. Quand je dis cela, je ne veux pas le limiter à la gestion de la mémoire MATLAB. Cela s'étend à Python, Java, .NET et à tout autre langage qui alloue une mémoire dynamique et qui est encore en développement actif.

Plus vous en saurez sur le mécanisme actuel de gestion de la mémoire, plus vous aurez de chances de coder de manière défensive contre cette implémentation spécifique, plus il sera probable que vous ne bénéficierez pas d’améliorations futures des performances. Un certain nombre de bons exemples de ceci peuvent être trouvés dans le gc de Java, écrit de manière compétente par Brian Goetz sur developerworks.com:

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

Vous pouvez dire que c'est important de savoir. Je réponds que tout est question d'exigences. La question la plus appropriée est la suivante: les langues que je considère pour mon projet répondent-elles à mes besoins en termes de performances, d'effort de développement, de maintenabilité, de portabilité, d'expertise de mes développeurs, etc.?

Je n'ai jamais vu un projet ayant besoin d'utiliser un balayage de génération en général sur le comptage de références. Je ne m'attends pas à en voir un bientôt.


2
2017-09-21 19:56