Miglior linguaggio per giochi?

[marco.r]

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.

Nei microbenchmark java vince quanto vuoi, ma all'atto pratico in generale le applicazioni Java sono piu' lente. Intanto perche' per quanto Java come linguaggio possa essere veloce, Java come piattaforma e' piuttosto una ciofeca (performance-wise). D'altra parte e' il prezzo da pagare per avere un'api decisamente piu' fruibile di quelle tipicamente disponibili in C++.
Inoltre, visto che di solito i punti veramente critici per le performance sono pochi, in C++ hai maggiori strumenti per ottimizzarli.
Il codice sopra potresti ad esempio cambiarlo un po' per renderlo a costo zero in termini di heap.


Per tornare al discorso del GC, e' vero che uno puo' adattarne l'uso per diminuire le latenze introdotte (cosa che tra l'altro non e' neanche sempre necessaria per un gioco, vedi la quintalata di giochi flash che trovi su internet...), ma questo va al di la' delle competenze standard del tipico programmatore Java ( C# etc.) ed e' un tipo di attivita' che si avvicina alla gestione manuale della memoria in un linguaggio come C++. Tra star li' a calcolare quanto devo ridimensionare una generazione del GC perche' entri in azione quando voglio e una semplice arena di memoria gestita dalla creazione/cancellazione di un singolo oggetto non vedo grandi differenze di complessita'...

[tecno789]

interessante...mi iscrivo al thread!

[marco.r]

Originariamente inviato da PGI-Bis

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

Si potrebbe provare con qualcosa che vada a toccare molto piu' spesso la memoria. Ad esempio qualcosa tipo creare un albero di ricerca (BR, avl, quel che si vuole) con qualche milionata di oggetti e poi fare una dose massiccia di rimozioni e inserzioni. Dovrebbe dare una idea.

[clockover]

Originariamente inviato da tecno789

interessante...mi iscrivo al thread!

É un po che speravo di poter leggere una discussione del genere posso fare solo da spettatore

[MissaW_RaZ_98]

Originariamente inviato da clockover

É un po che speravo di poter leggere una discussione del genere posso fare solo da spettatore

siete i benvenuti

[tecno789]

Originariamente inviato da clockover

É un po che speravo di poter leggere una discussione del genere posso fare solo da spettatore

eh purtroppo anche io

[MissaW_RaZ_98]

Originariamente inviato da tecno789

eh purtroppo anche io

bhè,io neanche mi aspettavo che la mia domanda fosse così "ricca" di risposte

Siete grandi raga!

[pabloski]

Originariamente inviato da MissaW_RaZ_98

bhè,io neanche mi aspettavo che la mia domanda fosse così "ricca" di risposte

la cosa importante credo che sia: "sei riuscito ad avere una risposta accettabile alla tua domanda?"

[LMCH]

Originariamente inviato da marco.r

D'altra parte e' il prezzo da pagare per avere un'api decisamente piu' fruibile di quelle tipicamente disponibili in C++.

Dipende da cosa si intende per "tipicamente disponibili".

Il vero problema di C++ è che "si adatta troppo bene alle varie esigenze"
e non avendo un azienda dietro interessata a spingere delle librerie standard "complete" di solito si usa "C++ e qualcosaltro".
Bisogna quindi fare lo sforzo in più di fare più attenzione a cosa ci si appoggia in termini di librerie.

[cdimauro]

Originariamente inviato da PGI-Bis

Questo.

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

Intanto è da vedere come ciò sia possibile. A quanto pare NON da codice...

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

In C++ posso avere de/allocatori multipli per decidere finemente cosa fare con ogni tipo di oggetto.

In Java posso al più scegliere un tipo di GC, e nemmeno da codice, visto che stiamo parlando di un parametro della virtual machine e non del compilatore.

La differenza fra le due cose è sostanziale.

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.

Questo potrebbe andare bene se tutti gli oggetti fossero young. Ne parlo meglio dopo.

Comunque in C++ posso anche allocare memoria sullo stack o in maniera statica, e togliere di mezzo i tempi di deallocazione nei casi in cui riconosco che si possa fare. Questo in Java non si può fare.

Parliamo in ogni caso di caratteristiche standard del linguaggio. Niente alchimie con settaggi vari della virtual machine.

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.

La fai troppo facile. In un gioco servono anche delle informazioni di stato che variano nel tempo (inter-frame) e la cui de/allocazione non è facilmente prevedibile a priori.

Per essere chiari, potresti applicare lo stesso principio su esposto per gli oggetti young, ma significherebbe controllare in un preciso punto del codice (dove ti fa comodo) lo stato del GC, e riempirlo arbitrariamente di oggetti da deallocare in modo farne scattare la pulizia se ti accorgi che lo spazio rimasto potrebbe non essere sufficiente fino alla fine del frame.

La classica cura che funziona, ma ammazza il malato, insomma.

Come ricordava fek, in 10ms bisogna renderizzare un terzo del frame, non perdere tempo a fare da balia al GC...

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

In questo caso stai andando a toccare la virtual machine, e non il linguaggio, per cercare di mimare quello che in altri linguaggi (e solo il linguaggio) si fa in maniera semplice, naturale, ed efficiente.

Il martello puoi anche usarlo per intonacare una parete, ma un fracasso lo fa LEGGERMENTE meglio...

Fu per la verità Alan Kay a deciderlo e ci ha pure vinto un Turing (non credo intitolato a "la minchionata colossale").

Non mi risulta che Alan Key abbia inventato la programmazione a oggetti, ma potrei anche sbagliarmi...

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.

Basta non confondere la OOP con quello che non lo è.

Per la OOP è necessario il collegamento dinamico, ma ciò non vuol dire che in un linguaggio che supporti la OOP tutto debba essere collegato dinamicamente. Non c'è bisogno di un premio Turing per capirlo.

Un oggetto non deve necessariamente avere tutti i membri polimorfici. Il polimorfismo si applica dove t'interessa modellare il comportamento di un oggetto. Non a membri che possono benissimo essere non dinamici.

In Java è possibile definire membri non dinamici per una classe? Se la risposta è sì, permane l'affermazione di cui sopra: Gosling fece la minchiatona colossale, perché avrebbe dovuto utilizzarli di default, e lasciare al programmatore il compito di definire quelli per cui serve il collegamento dinamico.

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

Non è certo la stessa cosa, visto che parliamo di mettere le mani ai dettagli della virtual machine. Qualcosa che va al di fuori del mero linguaggio.

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.

Gli oggetti che definisci all'interno della funzione e che vengono utilizzati soltanto in quello scope finiscono nello stack, e vengono automaticamente distrutti all'uscita della funzione.

Nessuno m'impedisce di definire un vettore di byte nello stack, e costruirmi un de/allocatore in C++ che lo usi per particolari mie esigenze.

Lo si fa, appunto, nei giochi, quando sai che dovrai allocare al più n oggetti di un certo tipo, che dovranno essere distrutti alla fine dei calcoli, e t'interessa che allocazione e deallocazione siano operazioni velocissime. E hai pure il pregio di non frammentare la memoria...

E' una cosa che in Java non puoi fare. Sic et simpliciter.

E' un esempio dell'enorme flessibilità che il C++ ti mette a disposizione. Difatti il codice hai postato alla fine ha sortito l'effetto opposto, perché non ha fatto che rafforzare quanto già detto.

Originariamente inviato da pabloski

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

Se trovi il link postalo, perché sarebbe interessante vedere in quali scenari avviene ciò.

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++

Questo già non mi risulta:
http://www.phoronix.com/scan.php?pag...nchmarks&num=1
http://www.g-truc.net/post-0372.html#menu
http://software.intel.com/en-us/arti...er-xe/#details

Da notare l'ultimo, che è il più recente, e che sfrutta la nota batteria di test SPEC, che è abbastanza corposa ed eterogenea in termini delle varie (tante) tipologie di codice utilizzate.

[ingframin]

Apprezzo sempre queste discussioni, si imparano un sacco di cose...
Solo che mentre qui si discute di C++ vs Java rimane il problema di fare giochi.
Anche se ora mi prendo una sputazza in un occhio ritengo che prima di pensare ad ottimizzare il gioco al bit bisognerebbe pensare al gameplay e al tipo di grafica. Fatto ciò si parte, si fa un prototipo funzionante e poi, se il prototipo non va sufficientemente rapido o bisogna aggiungere cose e limare i tempi, si passa all'ottimizzazione.
Ecco perché in una delle mie prime risposte avevo scritto "usa il linguaggio che preferisci".

Non esiste il miglior linguaggio per fare i giochi, questa è la risposta alla domanda originale del thread.

Che C++ vada più veloce di Java è cosa nota (sempre che il programmatore sia all'altezza, altrimenti...), che per fare un gioco serva necessariamente di spremere la macchina all'osso direi proprio di no.
Anche perché, il singolo sviluppatore, difficilmente ti programmerà un AAA, è più facile che ti tiri fuori un Angry Birds

Però continuatela la discussione Java vs C++ che sto imparando più cose qui che nel corso di POO dell'università

[cdimauro]

Di un gioco si può benissimo realizzare un modello/prototipo, e si può tranquillamente fare a meno del C++ per questo. Anzi, meglio linguaggi di gran lunga più produttivi.

Riflettendo ancora sulla discussione, il tracking di qualunque cosa in Java non è affatto semplice. Se per una classe che ho scritto ho assoluta cognizione e controllo, lo stesso non si potrebbe dire per le altre, ad esempio quelle del framework.

Se devo convertire un oggetto in stringa, sono sicuro che verrà istanziato esattamente un oggetto? Non si sa. E se in alcuni casi, invece, vengono istanziati n oggetti, in altri casi m, in altri p, ecc.? E magari quel codice non è sotto il mio controllo (leggi: non posso sfruttare il sistema di tracking che ho messo in piedi)?

Dovrei conoscere i dettagli del framework in maniera maniacale, e ciò non mi salverebbe comunque da casi complicati.

Questo non significa che il C++ non sia del tutto esente dalla problematica, ma nel momento in cui posso definire arbitrariamente gli allocatori, vuol dire che posso comunque reindirizzare le allocazioni e le deallocazioni come e dove voglio, e quindi tenere sotto controllo qualunque aspetto del lifetime degli oggetti, probabilmente anche senza conosce alcunché degli internal del framework.

Alla luce di ciò affermare che il GC sia assolutamente prevedibile risulta ampiamente discutibile.

[marco.r]

Originariamente inviato da ingframin

Che C++ vada più veloce di Java è cosa nota (sempre che il programmatore sia all'altezza, altrimenti...), che per fare un gioco serva necessariamente di spremere la macchina all'osso direi proprio di no.

Ah chiaro, anzi queste discussioni sono principalmente disquisizioni tecniche ("seghe mentali" ) valide per categorie particolari di programmi, quelli che coinvolgono una qualche simulazione in tempo reale (RTS, FPS...).
In un'avventura grafica (alla Monkey Island), o meglilo ancora uno strategico a turni la cosa conta molto meno. Li' anche se devi aspettare diversi secondi perche' finisca il turno il computer piu' di tanto non ti lamenti.

[pabloski]

Originariamente inviato da cdimauro

Questo già non mi risulta:
http://www.phoronix.com/scan.php?pag...nchmarks&num=1
http://www.g-truc.net/post-0372.html#menu
http://software.intel.com/en-us/arti...er-xe/#details

onestamente sono 3 link che non dicono niente

il primo confronta 3 versioni di gcc e quindi non lo confronta con icc e vc++

il secondo non dice su che os fa i benchmark....quello che ho visto dal benchmark di cui parlavo è che su windows vincono vc++ e .net, su linux ( con gli stessi benchmark ) gcc e mono impiegano meno tempo di vc++ e .net rispettivamente ( su windows )

magari la differenza dipende dal sistema operativo

il terzo link mi pare onestamente un bel pò di marketing.....comunque in moltissimi benchmark, icc arriva ad un 10% di performance in più rispetto a gcc, ma è il massimo che riesce ad ottenere....in media siamo sul 3-5%

trovai pure questo all'epoca http://attractivechaos.github.com/plb/ dove si vede che tra gcc e icc passa ben poca differenza

[MissaW_RaZ_98]

Originariamente inviato da pabloski

la cosa importante credo che sia: "sei riuscito ad avere una risposta accettabile alla tua domanda?"

si,troppe anche

[pabloski]

Originariamente inviato da MissaW_RaZ_98

si,troppe anche

l'importante è aver trovato almeno una risposta....troppe però possono creare confusione e riportare al punto di partenza, cioè "che diavolo di linguaggio devo usare?"

ma penso che ormai sia chiaro che il linguaggio è l'ultimo dei problemi in questo caso

e c++ ha l'enorme vantaggio di avere tonnellate di codice già pronto

[marco.r]

Originariamente inviato da cdimauro

Questo già non mi risulta:
http://www.phoronix.com/scan.php?pag...nchmarks&num=1
http://www.g-truc.net/post-0372.html#menu
http://software.intel.com/en-us/arti...er-xe/#details

Da notare l'ultimo, che è il più recente, e che sfrutta la nota batteria di test SPEC, che è abbastanza corposa ed eterogenea in termini delle varie (tante) tipologie di codice utilizzate.

In realta' l'ultimo dice che ICC genera codice tra il 9% e il 12% piu' performante di gcc sotto linux (in determinati test), mentre sotto windows genera codice tra il 21% e il 42% piu' performante di VS2010, quindi e' in linea con quanto diceva pabloski.

[marco.r]

Originariamente inviato da LMCH

Dipende da cosa si intende per "tipicamente disponibili".

Il vero problema di C++ è che "si adatta troppo bene alle varie esigenze"
e non avendo un azienda dietro interessata a spingere delle librerie standard "complete" di solito si usa "C++ e qualcosaltro".
Bisogna quindi fare lo sforzo in più di fare più attenzione a cosa ci si appoggia in termini di librerie.

Intendo quelle di maggiore diffusione, che facciano parte della libreria standard piuttosto che di librerie terze di maggior diffusione (boost etc.).
Prendi l'I/O ad esempio; in C++ fondamentalmente le due alternative principali sono l'api C classica oppure gli stream. In entrambi i casi se voglio implementare un classe che faccia un qualche filtro (boh, mettiamo una codifica RLE) devo fare molto piu' lavoro che non in Java.

[cdimauro]

Originariamente inviato da pabloski

onestamente sono 3 link che non dicono niente

il primo confronta 3 versioni di gcc e quindi non lo confronta con icc e vc++

Ho sbagliato a incollare il link. Ecco qui quello giusto.

il secondo non dice su che os fa i benchmark....

Al 99,9999999 (periodico) % sarà Windows.

quello che ho visto dal benchmark di cui parlavo è che su windows vincono vc++ e .net, su linux ( con gli stessi benchmark ) gcc e mono impiegano meno tempo di vc++ e .net rispettivamente ( su windows )

magari la differenza dipende dal sistema operativo

Il s.o. è invariante: è lo stesso per tutti i compilatori.

il terzo link mi pare onestamente un bel pò di marketing.....comunque in moltissimi benchmark, icc arriva ad un 10% di performance in più rispetto a gcc, ma è il massimo che riesce ad ottenere....in media siamo sul 3-5%

SPEC è un benchmark famosissimo, con centinaia di test e tantissime tipologie di codice.

Se a te non piace per i risultati, beh, non possiamo farci niente.

trovai pure questo all'epoca http://attractivechaos.github.com/plb/ dove si vede che tra gcc e icc passa ben poca differenza

Visto anche questo. Sono pochi, quasi tutti che sfruttano l'ALU, e soltanto in uno è ipotizzabile che vengano sfruttate SSE & compagnia.

Originariamente inviato da marco.r

In realta' l'ultimo dice che ICC genera codice tra il 9% e il 12% piu' performante di gcc sotto linux (in determinati test), mentre sotto windows genera codice tra il 21% e il 42% piu' performante di VS2010, quindi e' in linea con quanto diceva pabloski.

A lui non stanno bene comunque anche se dipingono una situazione simile a quella che ha citato, semplicemente perché li ho riportati io.

Comunque sono singolari i benchmark su Windows, perché su questa piattaforma ho visto che generalmente ICC >> VS >> GCC. Le differenze sono abbastanza marcate.

[tecno789]

Originariamente inviato da MissaW_RaZ_98

si,troppe anche

ora ti aspetta solo lo studio, matto e disperatissimo