Ars Ludica | Forum | Archivio | About

Ottimizzazione: Che ne è? Eh?

        Thursday, 6 March 2008, 21:51 - Monopoli

Eh sì.

Quante volte ho letto “Quel gioco non è ottimizzato!” o “Quel gioco non è ottimizzato!” oppure ancora “Quel gioco non è ottimizzato!”.

In genere mi irrito. Altre volte mi inquieto mentre altre mi pongo domande. Comunque molto spesso mi irrito.

Ma perchè, dopo tutto? E’ così bello discutere con la gente! Quindi proviamo a capire cosa è cambiato nell’ottimizzazione, così magari in futuro avremo le idee più chiare. Da una mente chiara ne deriva una buona digestione e una duratura erezione, quindi partiamo.

La leggenda vuole che nel passato si ottimizzasse l’assembly fino a consumarsi le cornee sui forsfori verdi dei monitor di quei bei tempi che furono.

Ah, quanta verità! Non vi è nulla di più vero! Pensate che talune volte bisognava programmare su un computer e lanciare il gioco su un altro, poichè non c’era memoria per contenere gioco e programma per scriverlo.

Tempi bui, nei quali si scriveva il codice macchina direttamente nelle locazioni di memoria.

Tempi grami, in cui dire “ho 10Kb liberi” significava dire che tutta la memoria di sistema era libera.

Ai tempi era necessario ottimizzare spazio e codice, in modo da far stare tutto in 64K (ad esempio). Quindi si scriveva in assembly, si usavano array fissi, si gestivano immagini a 16 colori e si facevano muovere sprite da 16×16 pixel.

Forse sono andato troppo indietro, ma veniamo ad oggi.

Ad oggi fare queste ottimizzazioni non porterebbe ad un risultato buono. Vediamo perchè.

Supponiamo di avere un computer che fa 10 operazioni al secondo. Chessò, una PS3…. oh no! Ho violato un NDA! Vabbè, dicevo: 10 operazioni al secondo.

Abbiamo un algoritmo che in 5 operazioni è fatto e viene chiamato una volta al secondo. Lo ottimizziamo fino a che non fa ciò che deve in 2 operazioni, miracolosamente senza intaccare la memoria, ma funziona solo su quel tipo di dato e con un numero di elementi fissi.

Uella, un incremento pazzesco! Abbiamo 8 operazioni libere invece che 5.

Ora supponiamo di far girare l’algoritmo da 5 su una macchina che fa 1.000.000.000.000 di operazioni al secondo.

Capiamo da soli che a questo punto, forse è meglio quello da 5 rispetto a quello da 2 poichè è più completo: potremo magari usarlo in più luoghi del codice, senza intaccare le performance.

Ad oggi l’ottimizzazione quindi non può andare sulle minuzie: con le minuzie non ci si mangia via nemmeno un millisecondo.

Bisogna andare più ad alto livello, poichè anche i dati da gestire sono diventati mostruosi.

Quindi i famosi discorsi “Eeeh, ai tempi sì che si ottimizzava, oggi i programmatori pensano solo a godersi i miliardi che guadagnano a colpi di Veline e modelle Victoria’s Secret” purtroppo non hanno senso. Non tanto per la faccenda di Victoria’s Secret (ormai sono anche un po’ stufo di farmi Adriana Lima), ma perchè quel tipo di ottimizzazioni ad oggi sarebbero del tutto inutili.

Quindi cosa è utile? In assoluto, ad oggi, sono fondamentali le strutture dati scelte, il multithreading che blocchi il meno possibile i vari Core, il numero delle draw call e l’ottimizzazione dei dati.

Eh sì, dei dati. Caricare un livello che pesa 500MB o uno che ne pesa 100 ma ha un “look and feel” identico ovviamente cambia un tantino :-D

E qui finalmente accantoniamo il dannato programmatore e andiamo dai grafici. Se i programmatori, con dieci giorni di lavoro, possono tagliare via 1 o 2 millisecondi per frame, beh, i grafici nello stesso tempo sono in grado di tagliarne tipo 7 o 8 :-D

Non male, vero? Quindi l’ottimizzazione dei dati è assolutamente fondamentale: decide se un gioco scatta in un dato punto del livello o meno.

Ma come possono fare i grafici a testare il tutto e tunare il livello? Con i tools. E chi li fa?

Il programmatore. E che palle. Sempre in mezzo.

Quindi, arrivati alla conclusione, cosa possiamo dire? Di certo che i programmatori passano la maggior parte del tempo a fare tools che producono dati ottimizzati, poichè è lì che si risparmia il grosso del tempo.

Quindi i tempi delle ottimizzazioni “una istruzione assembly in meno” sono finiti, da un bel po’.

Certo che però quelli erano bei tempi.

Cià vi saluto che c’è Persona 3 che mi aspetta: chissà che oggi quell’emo sfigato del mio personaggio non convinca qualche tipa ad accoppiarsi con lui.