pyop3: every assembled matrix keeps a second matrix of the same size alive

Aperta
  • Qualcosa non va?
#5,613 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #5614 di @sghelichkhani — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, performance

Direzione di ricerca

Start by tracing PetscMatBuffer.materialize() and how _lazy_template is retained by the sparsity buffer and cached loop executor in _compile. Check the related discussion in issue #5538 for context on the other reported memory leak. The issue is resolved when assembled matrices no longer leave an unnecessary same-sized PETSc matrix alive through cached sparsity buffers, with the example reporting only the matrix still in use.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

While looking at the peak memory of G-ADOPT with pyop3 I found that every assembled matrix keeps a second matrix of the same size alive.

PetscMatBuffer.materialize() builds a fully assembled matrix from the preallocator of the sparsity, stores it in _lazy_template and returns a duplicate of it. The sparsity buffer is then held by the executor of the loop that filled the sparsity, which stays in the heavy _compile cache, so the template is never freed. PyOP2 kept only the row counts of the sparsity. In G-ADOPT cases with many cells per rank this and the leak that #5538 fixes are the two largest parts of the extra PETSc memory of pyop3 against PyOP2.

A small example in serial:

import gc
from firedrake import *

mesh = UnitSquareMesh(20, 20)
V = VectorFunctionSpace(mesh, "CG", 2)
u, v = TrialFunction(V), TestFunction(V)
A = assemble(inner(grad(u), grad(v)) * dx)

gc.collect()
mats = [m for m in gc.get_objects()
        if isinstance(m, PETSc.Mat) and m.handle and m.type == "seqaij"]
print(len(mats))  # 2, although only A is in use

Is it intended that the template stays alive for as long as the sparsity buffer is in the cache? And is it intended that the cached executors hold on to the buffers of their first call?

Lingua principale
Python
Stelle
684
Fork
204
Merge medio
4g 14h
PR unite (30g)
46

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di firedrakeproject/firedrake

Tutte le issue di firedrakeproject/firedrake

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.