Miglior linguaggio per giochi?

[PGI-Bis]

Il problema non è l'artist, è l'artist aggratists che manca. Altrimenti avrei già assunto questo:

http://vimeo.com/25352771

[Tommo]

Originariamente inviato da PGI-Bis

Il problema non è l'artist, è l'artist aggratists che manca. Altrimenti avrei già assunto questo:

http://vimeo.com/25352771

Non ci piove che trovare l'artist aggratis è difficile, ma ci sono parecchi modi... non ultimo frequentare una community di sviluppatori /shamelessspam
Quello che conta è non cercare gente per fare il "tuo" gioco, e dimostrare che l'idea e la programmazione sono cazzute

[cdimauro]

Originariamente inviato da pabloski

mica tanto banale....ci sono giochi discreti che rientrano nella categoria di quelli realizzabili tramite java e soci

come ho detto più sopra, ci sono situazioni in cui è possibile farlo e altre in cui non è proprio possibile, ma sta al progettista valutare

però escludere a priori linguaggi diversi dal c++ è sbagliato

Nel contesto specifico di cui si parlava, il C++ è il linguaggio giusto da utilizzare per le motivazioni che sono state portate.

Infatti fek ha lavorato a giochi AAA. E io, non a caso, ho citato giochi AAA.

E' chiaro che se rilassiamo i requisiti, rientriamo nel discorso che ha fatto Tommo prima e che non fa una piega.

il punto fondamentale è che le latenze di cui parlava fek sono strettamente legate a quanto il gioco richiede in termini di potenza bruta e quanta è in grado di fornirne l'hardware

man mano che il carico di lavoro verrà sempre più spostato verso le gpu, diventerà sempre meno necessario usare il c++

Falso per diverse ragioni:
- le CPU continueranno a essere spremute come un limone perché per diverse tipologie di codice non c'è GPU con tanti core che tenga;
- anche le CPU stanno integrando sempre funzionalità che in precedenza erano appannaggio delle GPU (molti core, e unità SIMD massicciamente parallele);
- anche le GPU si programmano in C++ (vedi CUDA) se si vogliono ottenere certi risultati;
- la latenza è un fattore che è destinato a rimanere.

spesso leggo cose tipo "java non è adatto ad applicazioni real-time" o applicazioni che fanno uso intensivo della cpu...questo è parzialmente errato e ci sono vari articoli su developerworks e la stessa sun, in passato, ha cercato di spiegare come loro hanno mitigato il problema e come e cosa fare per rendere java adatto a tali scopi

Non è adatto per quanto già detto.

pure lo ius prime noctis era stabilito per legge, ciò non toglie che fosse una porcata

Senza dubbio.

così come lo sono le assurde pretese delle multinazionali del software

Qui, logica alla mano, hai fatto il passo più lungo della gamba, perché le due cose non c'entrano niente l'una con l'altra.

Il tuo discorso è viziato dal preconcetto che le multinazionali abbiano delle pretese che tu classifichi aprioristicamente come assurde, quando questa è una presa di posizione individuale e opinabilissima.

ma guarda che nel ventennio c'erano tanti leggi, poi definite fasciste, che erano totalmente regolari

Senza dubbio, ma vedi sopra.

tu confondi diritto e giustizia, due cose che quasi mai vanno a braccetto

No, tu confondi. Punto.

Stai generalizzando su un discorso assolutamente soggettivo, appioppando bollini rossi a chi ti sta antipatico.

ci sono scrocconi, ma c'è pure chi paga e vorrebbe garantiti i propri diritti

Quali? E, soprattutto, sono realmente loro diritti? A che titolo li possono pretendere su prodotti che NON hanno commercializzato loro?

no, io propendo per l'equità

Brutta parola di questi tempi.

L'equità la si ottiene esercitando la libertà di scelta che ha un consumatore. Ne parlo alla fine.

non passa giorno senza dover leggere assurdità fasciste come il controllo 24 ore sue di internet, lo spionaggio delle major, le lettere estorsive di Peppermint e soci,

Vero.

le sempre più restrittive eula, ecc...

Qui, invece, vale quanto scritto sopra: se non ti piace, non compri. Libertà di scelta del consumatore.

per fortuna i giudici ancora ragionano http://punto-informatico.it/3498695/...non-reato.aspx

almeno siamo sicuri di non vederci appioppare un ergastolo solo perchè abbiamo violato un'eula

Preferisco non aprire quel link. Mi secca leggere PI.

io sono un vero liberista, loro no

Se lo fossi veramente, e mi ricollego a quanto detto prima, dovresti lasciare che sia il mercato ad autoregolarsi, lasciando libertà alle aziende di proporre i LORO prodotti alle LORO condizioni, e ai consumatori di scegliere se acquistarli o meno.

Poiché i primi non possono vivere senza i soldi dei secondi, e questi sono interessati ai prodotti dei primi, la situazione del mercato è destinata ad equilibrarsi.

La condizione è, ovviamente, che le parti siano consapevoli del potere che hanno nelle loro mani. Cosa, purtroppo, tutt'altro che scontata, specialmente per i secondi.

Originariamente inviato da PGI-Bis

Vedi, la prospettiva che adotti è quella di un linguaggio unmanaged.

Suona come un indovinello ma è giusto dire che non puoi chiamare il gc a mano sebbene tu possa stabilire a mano quando interverrà.

Considera il serial collector (il JRE ha cinque diversi tipi di gc quindi il discorso non è generalizzabile) e prendiamo solo la tenured gen per semplicità.
Il serial collector esegue una pulizia completa della tenured gen esattamente quando questa è piena.
La dimensione della tenured gen è controllabile.
Se sai quando monnezza infili in quella regione per ogni ciclo del tuo motore di gioco sei anche in grado di predire con esattezza il momento in cui il gc interviene. E' una questione di mere divisioni.

Non è il garbage collector sia un programma che parte quando vuole lui, fa quello che gli pare... no: ha tempi e modi certi e misurabili e, soprattutto, che dipendono dal codice che scrivi tu.

L'effetto è lo stesso della gestione manuale della memoria C++. Cambia il modo in cui lo ottieni.

Anche dopo la tua descrizione, rimane il problema dell'indeterminabilità dell'esecuzione del GC.

Il tuo modello funziona nella misura in cui è possibile prevedere in maniera precisa quanti elementi vanno a finire nel GC, e la capienza di quest'ultimo.

Supponendo nota la capienza, non è comunque noto il numero di oggetti che andrà a finirvi.

Il motivo è semplice: un gioco non genera esattamente lo stesso ammontare di oggetti per ogni frame elaborato.

Ma anche se ciò fosse possibile, il GC non si attiverebbe esattamente nello stesso momento per ogni frame, ma in momenti diversi, magari in momenti in cui NON si vorrebbe che si attivasse.

Pertanto Java non è assolutamente paragonabile a C++.

Lo sarebbe nella misura in cui permettesse di impostare la capienza del GC E di abilitare, disabilitare, far eseguire un run/cleanup degli oggetti fino a quel momento collezionati (magari agendo anche sulle diverse generazioni degli oggetti).

A queste condizioni, visto che comunque è possibile stabilire un tetto massimo per il numero di oggetti istanziabili dal gioco per ogni frame, sarebbe possibile impostare una capienza opportuna per il GC, e decidere anche quando fargli eseguire il cleanup, divenendo perfettamente prevedibile allo scopo.

Ma non funziona così. Per cui... amen! Java != C++.

[pabloski]

Un interessante articolo di amd per chiarire un pò di dubbi http://developer.amd.com/documentati...ionTuning.aspx

Continuiamo a parlare di indeterminatezza, latenze, ecc... senza minimamente curarci del carico di lavoro che il gioco da sviluppare richiede all'hardware.

Faccio notare, solo a titolo di cronaca, che java e .net micro framework sono usati in ambito embedded realtime. Penso che questo dato, da solo, possa chiudere la diatriba.

Ripeto, se non so quanto "mi costa" il gioco, allora non posso dire se è meglio java, c++, c#, lua, javascript o che altro.

[cdimauro]

Originariamente inviato da pabloski

Un interessante articolo di amd per chiarire un pò di dubbi http://developer.amd.com/documentati...ionTuning.aspx

Io mi chiedo se i link che passi prima li leggi oppure no:

Since the compaction can happen at an unpredictable time, your application requirements might not be met.

Continuiamo a parlare di indeterminatezza, latenze, ecc... senza minimamente curarci del carico di lavoro che il gioco da sviluppare richiede all'hardware.

Perché è un discorso che non c'entra nulla con quello di cui si sta discutendo.

Faccio notare, solo a titolo di cronaca, che java e .net micro framework sono usati in ambito embedded realtime. Penso che questo dato, da solo, possa chiudere la diatriba.

Sempre per la cronaca, se non rispettano i requisiti che ho espresso prima, la diatriba continua a rimanere aperta.

Ripeto, se non so quanto "mi costa" il gioco, allora non posso dire se è meglio java, c++, c#, lua, javascript o che altro.

Il costo lo si stabilisce, perché:
1) un gioco è tarato in base a requisiti minimi e massimi;
2) a runtime è possibile eseguire dei test di carico su CPU e GPU per gli scenari peggiori, e tarare l'engine di conseguenza.

Viceversa, il costo di un GC non è determinabile e/o non si può sapere quando si attiverà, ed è il motivo per cui non si sposa con la tipologia di giochi di cui abbiamo parlato finora.

E' chiaro adesso?

[=KaTaKliSm4=]

Originariamente inviato da cdimauro

Io mi chiedo se i link che passi prima li leggi oppure no:

Since the compaction can happen at an unpredictable time, your application requirements might not be met.

Evidentemente non leggono

Il discorso è che C++ oltre ad avere una piena libertà nella gestione della memoria (che è piu un bene che un male), è nettamente piu performante di qualsiasi altro linguaggio OOP e questo, è un dato di fatto constatabile perfino in un banalissimo ciclo che incrementa una altrettanto banale variabile, figuriamoci quando bisogna gestire modelli 3D complessi, effetti particolari e complesse elaborazioni per la simulazione della fisica.

Il confronto con minecraft non regge assolutamente, il gioco, tecnicamente parlando, non ha bisogno di grossi requisiti, a differenza di un gioco AAA.

Sembra uno scontro tra tifosi di calcio e non un dibattito tra professionisti/interessati.

P.S riguardo la portabilità : C++, OpenGl e framework QT, niente di piu "portabile", il fatto che Java sia "portabile" anche su piattaforme mobile è uno specchietto per allodole, un motore grafico che ha bisogno di determinati requisiti non può, per forza di cose, girare su dispositivi mobile e questo è un dato di fatto imprescindibile, ma, anche se lo fosse non sarebbe comunque possibile un porting senza la riscrittura parziale del codice.

Tanto per la cronaca : sviluppo la maggior parte dei miei software in C# e spesso mi avvalgo di componenti grafici di 3e parti (vedi DevExpress), vi posso garantire che in un software di media complessità che usa pesantemente elementi grafici e reflection, il calo di prestazioni si sente.

Poi ovvio, in base al progetto si è disponibili ad avere un leggero calo di prestazioni in cambio di altissima produttività, ma l'alta produttività non fa di un linguaggio il "MIGLIOR LINGUAGGIO" in senso assoluto, bensi fa di un linguaggio il "MIGLIOR LINGUAGGIO in QUEL contesto".

[PGI-Bis]

Che Java sia diverso da C++ nessuno sano di mente lo revocherebbe in dubbio ma il punto era, più generalmente, sulla possibilità di ottenere un risultato determinato in termini di tempi da una piattaforma "garbage collected".

Originariamente inviato da cdimauro

A queste condizioni, visto che comunque è possibile stabilire un tetto massimo per il numero di oggetti istanziabili dal gioco per ogni frame, sarebbe possibile impostare una capienza opportuna per il GC, e decidere anche quando fargli eseguire il cleanup, divenendo perfettamente prevedibile allo scopo.

E questo è perfettamente possibile. Lo fa in effetti Brackeen in Developing Games in Java (un vecchio libro per la verità): determina la quantità di spazzatura generata per frame e poi modifica la dimensione della young generation in modo tale da ottenere un intervento del gc a cadenze regolari. Perchè la condizione che attiva il gc (be', uno, quello più semplice e prevedibile) è determinata. Cioè sono tutte determinate ma quella del serial collector è "quando la regione da ripulire non può più essere riempita". E' questo che rende determinabile il momento in cui interviene la raccolta. E' anche il limite, nel senso che io posso fare la previsione se la quantità di spazzatura è costante a prescindere dal numero di oggetti gestiti, il che richiede una qualche forma di pooling "totale".

Che non si usa. Se guardiamo i motori Java esistenti il pooling è sempre limitato alle strutture di base per il calcolo delle trasformazioni (vettori, quaternioni e matrici). Per buone ragioni, in verità in un gioco non è carichi dinamicamente granchè, più che altro trasformi cose che hai già ficcato in memoria durante l'inizializzazione. E la maggior parte delle allocazioni che restano sono "young", una fetta di memoria il cui uso è praticamente gratuito dal punto di vista della garbage collection.

E l'articolo citato giustamente premette:

"One issue to consider with the concurrent collector is that"

[PGI-Bis]

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
    Object p = new Point(i, i);
    x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.

[PGI-Bis]

Sui garbage collector del JRE:

http://www.oracle.com/technetwork/ja...-5-138395.html

Qui ci sono tutti (quelli vecchi, che io sappia ne hanno aggiunto almeno un altro). Quello di cui parla l'articolo di AMD è verso la metà. Quello che "raccoglie quando trabocca" è il primo.

[ingframin]

Apro un leggero OT, ho trovato questo sito pieno di benchmark fatto molto bene:
http://shootout.alioth.debian.org/u6...arp=on&sbcl=on

[nico159]

A meno che non utilizzi la JVM commerciale Azul, parlare di un GC pauseless è fantascienza

La JVM di Oracle con 3GB di heap ti fa un stop the world di 4 secondi

Ah ovviamente Windows non è supportato da Azul Zing

[PGI-Bis]

Originariamente inviato da ingframin

Apro un leggero OT, ho trovato questo sito pieno di benchmark fatto molto bene:
http://shootout.alioth.debian.org/u6...arp=on&sbcl=on

Sono tutti benchmark di calcolo, non sulla gestione dinamica della memoria

[PGI-Bis]

Originariamente inviato da nico159

A meno che non utilizzi la JVM commerciale Azul, parlare di un GC pauseless è fantascienza

La JVM di Oracle con 3GB di heap ti fa un stop the world di 4 secondi

Ah ovviamente Windows non è supportato da Azul Zing

Azul in verità usa un truccone: anzichè far fare una grossa pausa al GC ne fanno fare tante piccole al kernel - tutti i riferimenti nella loro jvm sono protetti da delle barriere in lettura che hanno implementato direttamente nel kernel linux (o una roba del genere). Poi sarà anche un meccanismo migliore, per carità, ma quando dicono che è "pauseless" secondo me raccontano la storia del mago.

[nico159]

Originariamente inviato da PGI-Bis

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
    Object p = new Point(i, i);
    x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.

Uhum? Sto dando uno sguardo e tutti i principali compilatori convertono secondo alcune basi metodi virtual a chiamate dirette
http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx

Virtual Call Speculation – If a virtual call, or other call through a function pointer, frequently targets a certain function, a profile-guided optimization can insert a conditionally-executed direct call to the frequently-targeted function, and the direct call can be inlined.

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

-fdevirtualize
Attempt to convert calls to virtual functions to direct calls. This is done both within a procedure and interprocedurally as part of indirect inlining (-findirect-inlining) and interprocedural constant propagation (-fipa-cp). Enabled at levels -O2, -O3, -Os.

http://software.intel.com/sites/prod...s-analysis.htm

This option determines whether C++ class hierarchy information is used to analyze and resolve C++ virtual function calls at compile time. The option is turned on by default with the -ipo compiler option, enabling improved C++ optimization. If a C++ application contains non-standard C++ constructs, such as pointer down-casting, it may result in different behaviors.

[Tommo]

Originariamente inviato da PGI-Bis

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
    Object p = new Point(i, i);
    x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.

Veramente, ho fatto qualche test e da quello che ho visto le virtual in C++ sono più veloci di una chiamata a metodo normale di Java, mentre il 90% delle chiamate a metodo normali diventano inline e pesano esattamente 0, o al più una misera CALL assembly.
Senza contare che quando il tipo dato è conosciuto a runtime i compilatori moderni inseriscono un "non-virtual-thunk", che sarebbe una chiamata diretta inline alla sottoclasse in questione.

Mentre invece a quanto so in Java ogni metodo è "virtuale", tant'è che non sono stati previsti gli operatori *apposta* per rendere scomodo ai programmatori spammare chiamate a funzione.
Ora la situazione potrà essere pure migliorata, ma dubito seriamente che le chiamate a funzione di Java possano competere con C++.

L'unica cosa di java che è più veloce è la creazione di oggetti sull'heap: in quel codice ce ne sono due a loop (Point e String) e la cosa si sente. Prova a mettere le allocazioni fuori dal ciclo (o anche sullo stack) e vedi chi vince

[cdimauro]

Originariamente inviato da PGI-Bis

Che Java sia diverso da C++ nessuno sano di mente lo revocherebbe in dubbio ma il punto era, più generalmente, sulla possibilità di ottenere un risultato determinato in termini di tempi da una piattaforma "garbage collected".

Ed è per quello che l'ho scritto. Poi è lapalissiano che siano diversi, no?

E questo è perfettamente possibile. Lo fa in effetti Brackeen in Developing Games in Java (un vecchio libro per la verità): determina la quantità di spazzatura generata per frame e poi modifica la dimensione della young generation in modo tale da ottenere un intervento del gc a cadenze regolari.

Come fa a modificarne le dimensioni? Da quel che ho visto, puoi modificare alcuni parametri da command line, prima di lanciare la VM, ma non a runtime.

Supponendo di conoscere a priori la dimensione dello spazio che il GC ha riservato alla young generation, l'unico modo che mi viene in mente per far scattare la pulizia è di riempirlo per il numero di oggetti che mancano. Se, fino ad allora, ne ha contanti m che sono finiti nel GC, e la capacità di questo è n (maggiore di m), ne crea altri n - m e li fa finire subito nel GC.

Perchè la condizione che attiva il gc (be', uno, quello più semplice e prevedibile) è determinata. Cioè sono tutte determinate ma quella del serial collector è "quando la regione da ripulire non può più essere riempita". E' questo che rende determinabile il momento in cui interviene la raccolta. E' anche il limite, nel senso che io posso fare la previsione se la quantità di spazzatura è costante a prescindere dal numero di oggetti gestiti, il che richiede una qualche forma di pooling "totale".

Che non si usa. Se guardiamo i motori Java esistenti il pooling è sempre limitato alle strutture di base per il calcolo delle trasformazioni (vettori, quaternioni e matrici). Per buone ragioni, in verità in un gioco non è carichi dinamicamente granchè, più che altro trasformi cose che hai già ficcato in memoria durante l'inizializzazione. E la maggior parte delle allocazioni che restano sono "young", una fetta di memoria il cui uso è praticamente gratuito dal punto di vista della garbage collection.

E l'articolo citato giustamente premette:

"One issue to consider with the concurrent collector is that"

Nemmeno a queste condizioni puoi ottenere lo stesso funzionamento del C++.

A parte il casino di dover eseguire il tracking di ogni singolo oggetto (de)allocato per farti i conti alla fine, il problema principale è che stai supponendo che TUTTI gli oggetti allocati finiscano poi nella young generation, e vengano poi deallocati "forzando la mano" del GC.

Questo non è vero, perché in un frame un gioco non alloca soltanto oggetti che poi "butta via" alla fine. Non è assolutamente così. Lo è per moltissimi oggetti, ma non per tutti.

Ciò significa che ci saranno oggetti che andranno a finire nella young generation e altri nella tenured, e prima o poi il GC verrà attivato anche per questi.

Ma, soprattutto, non è possibile eliminare la frammentazione dell'heap di cui parlava fek nei suoi messaggi, che in Java prima o poi farebbe scattare un'operazione di pulizia generale per ricompattare lo spazio, e anche qui in maniera non deterministica.

Pensaci bene. Se la situazione fosse così semplice come l'hai dipinta finora, in C++ nemmeno servirebbe sbattersi la testa sulla meticolosa scelta di come e dove allocare i diversi tipi di oggetti generati durante un frame. Basterebbe sfruttare un solo allocatore, sfruttando proprio lo stack, e alla fine del frame non ti servirebbe nemmeno fare opera di deallocazione: rimetti a posto lo stack e hai finito, ottenendo peraltro prestazioni impareggiabili (NON deallochi nulla ).

Originariamente inviato da PGI-Bis

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
    Object p = new Point(i, i);
    x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.

Prima di tutto non è vero che la OOP è fatta tutta di chiamate virtuali: questo è un modello sbagliato perché in Java il buon Gosling ha fatto la minchiatona colossale di decidere che tutti i metodi debbano essere virtuali.
Un metodo dovrebbe essere virtuale quando lo decide il programmatore, quindi in maniera selettiva, quando serve (un'occhiata al Turbo Pascal 5.5 della Borland non avrebbe guastato).
Sia chiaro che pure in Python di default tutti i metodi sono virtuali. Ma è un linguaggio dinamico, ed è nato per fare cose "zozze" (agli occhi di un programmatore abituato a linguaggi staticamente tipati ).

Ciò detto, l'esempio che hai fornito tu in C++ lo si fa letteralmente volare costruendo un de/allocatore statico (nemmeno su stack: troppa grazia ) che:
- restituisce la stessa area di memoria alla prima chiamata (per Point);
- restituisce la stessa area di memoria alla seconda chiamata (conversione a stringa);
- non fa nulla nella deallocazione (di Point e della stringa).

E Java ci farebbe una figura, diciamo, barbina.

Fermo restando che se voglio giocare "più pulito", posso realizzare un de/allocatore più efficiente per la gestione dell'heap.

Perché non si può configurare come "sporca" la soluzione che ho proposto? Perché sto semplicemente sfruttando gli strumenti che C++ mi mette a disposizione per risolvere quel particolare problema. Esattamente come lo sviluppatore di giochi userà più de/allocatori a seconda del tipo di oggetti che sta creando e di come ha bisogno di distruggerli.

Originariamente inviato da PGI-Bis

Sui garbage collector del JRE:

http://www.oracle.com/technetwork/ja...-5-138395.html

Qui ci sono tutti (quelli vecchi, che io sappia ne hanno aggiunto almeno un altro). Quello di cui parla l'articolo di AMD è verso la metà. Quello che "raccoglie quando trabocca" è il primo.

Ho un perso un mare di tempo a smazzarmelo, ma non c'è proprio nulla che possa risolvere le problematiche che abbiamo affrontato finora. Maremma maiala.

@=KaTaKliSm4=: in linea generale concordo. Idem per gli ultimi messaggi.

[ingframin]

Originariamente inviato da PGI-Bis

Sono tutti benchmark di calcolo, non sulla gestione dinamica della memoria

Si lo so, l'ho detto che era un piccolo OT, volevo solo segnalare un sito fatto bene in qualche modo legato alla discussione.

[PGI-Bis]

Originariamente inviato da cdimauro

Supponendo di conoscere a priori la dimensione dello spazio che il GC ha riservato alla young generation, l'unico modo che mi viene in mente per far scattare la pulizia è di riempirlo per il numero di oggetti che mancano. Se, fino ad allora, ne ha contanti m che sono finiti nel GC, e la capacità di questo è n (maggiore di m), ne crea altri n - m e li fa finire subito nel GC.

Questo.

La dimensione delle fette di memoria usate dal GC devi tenerla fissa se vuoi sapere quanto interverrà.

E' la stessa cosa che fai in C++, nel senso di decidere quanto tempo dedicare alla deallocazione nel ciclo di gioco.

Con il collector "seriale" sai che il GC pulisce la young generation quando si riempie. Puoi stabilire quanto è grande la young con XX:NewSize/NewMaxSize. Se la young è grande 100 e il tuo ciclo genera monnezza per 100 ad ogni frame ottieni una pulizia per frame. Se la pulizia impiega 10 millisecondi ecco che spendi 10 millisecondi per frame nella gestione della memoria.

Per quanto riguarda la tenured e la sua frammentazione, certamente farla pulire nel ciclo di gioco ti affonda il framerate. MA, c'è una ma grosso come una casa: non è che stiamo parlando di meccanica quantistica, toh l'oggetto adesso è nella young, adesso è nella tenured e domani chissà.

Cioè qua sembra che i garbage collector siano esseri dotati di vita propria, largamente indeterminati nel loro comportamento...

Se io scrivo un programma maratoneta, io posso anche dire il gc interverrà quando vuole lui, spero ci metta poco e via.

Ma se scrivo un centometrista non posso più usare quella semplificazione: devo andare a vedere come effettivamente funziona.

Io posso scrivere il programma in modo tale che la tenured venga ripulita solo quando passo da un livello ad un altro, posso scriverlo in modo tale che, avendone a disposizione abbastanza, non si verifichi mai una pulizia. E' chiaro che non posso sperare nell'intervento divino.

Gli oggetti che finiranno nella tenured saranno solo quelli che sopravviveranno ad N passaggi del GC nella young, con N determinato dalle impostazioni di esecuzione della JVM.

Non facciamo passare l'idea - che è già passata - che un garbage collector renda tutto facile: è facile se i requisiti del programma sono facili.

Originariamente inviato da cdimauro

Prima di tutto non è vero che la OOP è fatta tutta di chiamate virtuali: questo è un modello sbagliato perché in Java il buon Gosling ha fatto la minchiatona colossale di decidere che tutti i metodi debbano essere virtuali.

Fu per la verità Alan Kay a deciderlo e ci ha pure vinto un Turing (non credo intitolato a "la minchionata colossale"). La programmazione orientata agli oggetti è intimamente vincolata al collegamento dinamico per il semplice fatto che la decisione sull'operazione da eseguire in presenza di un certa richiesta "nominale" (c->faiQuesto) spetta al ricevente che è variabile e quindi non puoi fissarlo a priori. C++ fa l'esatto contrario: tutti i metodi sono collegati staticamente a meno che non diversamente stabilito. E' un'innegabile fotografia: c'è la programmazione orientata agli oggetti, c'è C++ e nella foto si vede C++ che tira un cazzotto nell'occhio della OOP.

Non è che lo faccia perchè gli piace: lo fa per ragioni di performance.

Originariamente inviato da cdimauro

Perché non si può configurare come "sporca" la soluzione che ho proposto? Perché sto semplicemente sfruttando gli strumenti che C++ mi mette a disposizione per risolvere quel particolare problema. Esattamente come lo sviluppatore di giochi userà più de/allocatori a seconda del tipo di oggetti che sta creando e di come ha bisogno di distruggerli

Allo stesso modo il programmatore Java scriverà il codice in modo che il comportamento del GC sia predicibile.

Per quanto riguarda il benchmark la soluzione più semplice sarebbe prendere direttamente il codice (C) dell'allocatore usato dalla JVM per gli oggetti locali - che se non ricordo male è fatto in C e non in C++ perchè alloca sullo stack della funzione o una roba del genere e C++ non lo permette.

[=KaTaKliSm4=]

Originariamente inviato da ingframin

Si lo so, l'ho detto che era un piccolo OT, volevo solo segnalare un sito fatto bene in qualche modo legato alla discussione.

Non è assolutamente OT, anzi, da quei benchmark si vede chiaramente che c++ è il linguaggio OOP con le migliori prestazioni in senso assoluto.

Sarebbe stato interessante comparare anche C# su runtime .net e non Mono...

[pabloski]

Originariamente inviato da =KaTaKliSm4=

Sarebbe stato interessante comparare anche C# su runtime .net e non Mono...

non lo trovo adesso, ma c'era un post su un blog che confrontava java, c# .net/mono e c++ su linux e windows

su windows .net è più performante di mono, ma mono su linux è più performante di .net su windows

inutile dire che c++ era più performante degli altri e con mia sopresa ( perchè ho sentito dire diversamente da altri ) che gcc è quasi in pari con icc ( icc risultava max il 10% più veloce di gcc ) e molto più performante di vc++