2010-10-31 9 views
7

Come noto, il GC di traccia non può evitare il blocco del thread durante il GC completo.GC di Lua e gioco in tempo reale

Avevo usato XNA + C# e il tempo di GC era impossibile da rimuovere. Così sono passato al linguaggio di livello inferiore C, ma ho capito che avevo bisogno di un linguaggio di scripting. Sto considerando Lua, ma mi preoccupo del meccanismo GC di Lua. Lua utilizza GC di tracciamento incrementale e dovrebbe esserlo anche il blocco dei thread.

Quindi, come devo gestirlo nel gioco in tempo reale?

+2

Si sia non si scrive un gioco con i requisiti FPS così stretto in una lingua GC'd, o non si crea abbastanza spazzatura per fare un ciclo di GC impiegare più tempo di quanto sia accettabile. Prima prova se c'è qualche colpo notevole. – delnan

risposta

10

Il potere di Lua è che ti toglie di mezzo. Vuoi le lezioni? Questo può essere costruito con metatables. Vuoi il sandboxing? utilizzare lua_setfenv.

Come per il netturbino. Usalo come prima. Se in seguito si riscontrano problemi di prestazioni, utilizzare lua_gc per perfezionare il proprio comportamento.

Alcuni esempi:

  • disattivare il garbage collector nei periodi in cui il rallentamento sarebbe un problema.

  • Lascia il garbage collector disabilitato e agisci solo quando la logica del gioco dice che hai qualche spazio sul numero di FPS. È possibile eseguire la messa a punto della dimensione del passo o scoprire la dimensione del passo ottimale in fase di esecuzione.

  • Disabilitare il raccoglitore ed eseguire la raccolta completa nei punti di arresto, ad esempio una schermata di caricamento o una scena di taglio o al cambio di turno in una partita a caldo.

Si potrebbe anche prendere in considerazione un linguaggio di scripting alternativo. Squirrel si sforza molto di essere una Lua di seconda generazione. Cerca di mantenere tutte le buone caratteristiche di Lua, mentre elimina gli errori di progettazione. Una delle grandi differenze tra i due è squirrel uses reference counting invece di garbage collection. Risulta che il conteggio dei riferimenti può essere un po 'più lento della garbage collection ma è molto deterministico (AKA realtime).

+0

Grazie per la risposta. Il tuo suggerimento 'Scoiattolo' sembra molto bello. Lo scaverò presto :) – Eonil

3

Il modo corretto per gestire questa situazione è:

  1. scrivere un piccolo prototipo con solo le cose fondamentali che si desidera testare.
  2. Profila molto, riproducendo i diversi scenari che potrebbero accadere nel tuo gioco (molta memoria disponibile, poca memoria disponibile, diversi numeri di thread, quel genere di cose)
  3. Se non trovi un collo di bottiglia visibile , puoi usare Lua. Altrimenti, dovrai cercare soluzioni alternative (forse Lisp o Javascript)
+0

È triste che questo problema non sia evitabile, può essere ridotto solo. – Eonil

2

È possibile applicare una patch al GC Lua in modo da limitare nel tempo ciascun ciclo di raccolta. E.g: http://www.altdevblogaday.com/2011/07/23/predictable-garbage-collection-with-lua/

Credo che sia ancora possibile avere tempi di passo GC lunghi durante la raccolta di tabelle molto grandi. Pertanto è necessario adottare uno stile di programmazione che eviti tabelle di grandi dimensioni.

Il seguente articolo illustra due strategie per l'utilizzo di Lua per il controllo del robot in tempo reale (1. non generare garbage o 2.usando un O (1) allocatore e sintonizzare quando la raccolta GC viene eseguito): https://www.osadl.org/?id=1117

+0

Il primo collegamento è andato 404. Fortunatamente era un repost e l'originale può ancora essere trovato qui: http://kalogirou.net/2011/07/23/predictable-garbage-collection- con-lua / –

Problemi correlati