È possibile trascurare il costo di GC quando si analizza il tempo di esecuzione delle strutture di dati nel caso peggiore specificate in un linguaggio di programmazione raccolto in modo inutile?

22

Ho appena capito che ho assunto la risposta alla mia domanda è "sì", ma non ho una buona ragione. Immagino che forse esista un garbage collector che introduce in modo dimostrabile solo il rallentamento del caso peggiore di . C'è un riferimento definitivo che posso citare? Nel mio caso sto lavorando su una struttura di dati puramente funzionale e utilizzo ML standard, se questi dettagli contano. $O(1)$

E forse questa domanda sarebbe ancora più rilevante se applicata a strutture di dati specificate in, diciamo, Java? Forse ci sono alcune discussioni rilevanti nei manuali di algoritmi / struttura dati che usano Java? (So che Sedgewick ha una versione Java, ma ho accesso solo alla versione C.)

— Maverick Woo
fonte

17

Sì, gc è tempo costante ammortizzato. Supponiamo di avere un algoritmo che gira per il tempo con un set di picco di lavoro di dimensione . Ora, nota che puoi allocare al massimo parole durante l'esecuzione del programma e che il costo del tempo di esecuzione di un garbage collector copiante è (cioè, il costo di un gc è proporzionale al totale quantità di dati in tempo reale). Quindi, se si esegue gc al massimo volte, il costo di runtime totale è limitato da $n$ $k$ $O(n)$ $O(k)$ $O(n/k)$ $O(n)$ , il che significa che il costo ammortizzato del gc è costante. Quindi se hai un raccoglitore in stile Cheney, con ogni semispace di dimensioni , allora è facile vedere che una collezione completa non può essere invocata più di una volta ogni passi di , poiché l'allocazione di parole richiede tempo e il set di lavoro non supera mai la dimensione , che ti dà il limite desiderato. Ciò giustifica l'ignoranza dei problemi di gc. $2k$ $n/k$ $k$ $O(k)$ $k$

Tuttavia, un caso in cui la presenza o l'assenza di gc non è ignorabile è quando si scrivono strutture di dati senza blocco. Molte moderne strutture dati prive di blocchi perdono deliberatamente memoria e si affidano a gc per la correttezza. Questo perché ad un livello elevato, il modo in cui funzionano è copiare alcuni dati, modificarli e provare ad aggiornarli atomicamente con un'istruzione CAS ed eseguirli in un ciclo fino a quando il CAS ha esito positivo. L'aggiunta della deallocazione deterministica a questi algoritmi li rende molto più complessi, e quindi le persone spesso non si preoccupano (specialmente perché sono spesso indirizzate ad ambienti simili a Java).

EDIT: Se vuoi limiti non ammortizzati, il collezionista Cheney non lo farà - scansiona l'intero set live ogni volta che viene invocato. La parola chiave per google per è "raccolta dei rifiuti in tempo reale", e Djikstra et al. e Steele ha dato i primi collezionisti mark-and-sweep in tempo reale, e Baker ha dato il primo compattatore in tempo reale gc.

@article {dijkstra1978fly,
  title = {{Raccolta dei rifiuti al volo: un esercizio di collaborazione}},
  autore = {Dijkstra, EW e Lamport, L. e Martin, AJ e Scholten, CS e Steffens, EFM},
  journal = {Comunicazioni dell'ACM},
  = Volume {21},
  numero = {11},
  Pagine = {}, 966--975
  ISSN 0001-0782 = {},
  anno = {1978},
  publisher = {} ACM
}

@article {steele1975multiprocessing,
  title = {{Multiprocessing compactifying garbage collection}},
  autore = {Steele Jr, GL},
  journal = {Comunicazioni dell'ACM},
  = Volume {18},
  numero = {9},
  Pagine = {}, 495--508
  ISSN 0001-0782 = {},
  anno = {1975},
  publisher = {} ACM
}

@article {baker1978list,
  title = {{Elaborazione dell'elenco in tempo reale su un computer seriale}},
  autore = {Baker Jr, HG},
  journal = {Comunicazioni dell'ACM},
  = Volume {21},
  numero = {} 4,
  Pagine = {}, 280--294
  ISSN 0001-0782 = {},
  anno = {1978},
  publisher = {} ACM
}

— Neel Krishnaswami
fonte

a

$a$

b

$b$

a

$a$

b

$b$

1

"Sì, gc è tempo costante ammortizzato". Questo non è vero in generale. Potresti sostenere che GC può essere, ma non lo sono necessariamente e quelli reali non lo sono. Ad esempio, l'ingenuo List.mapin OCaml è in realtà una complessità quadratica perché la profondità dello stack è lineare e lo stack viene attraversato ogni volta che viene evacuato il vivaio. Lo stesso vale per le sezioni principali che incontrano grandi matrici di puntatori.

— Jon Harrop,

12

$O(n)$

$O(1)$

Il riferimento definitivo alla raccolta dati inutili è:

Garbage Collection di Richard Jones e Rafael Lin

Ben Zorn ha svolto alcuni lavori per misurare i costi effettivi dei diversi algoritmi di raccolta dei rifiuti, sebbene il seguente documento più recente presenti un confronto molto più completo:

Miti e realtà: l'impatto sulle prestazioni di Garbage Collection , SM Blackburn, P. Cheng e KS McKinley, conferenza ACM SIGMETRICS su sistemi informatici di misurazione e modellizzazione, pp. 25--36, New York, NY, giugno 2004.

Per di più vedi:

Una teoria unificata della raccolta dei rifiuti , Bacon, Cheng e Rajan, conferenza ACM sulla programmazione orientata agli oggetti, sistemi, lingue e applicazioni, Vancouver, BC, Canada, pp. 50-68, 2004.

— Dave Clarke
fonte