Ho sempre trovato il termine "micro-ottimizzazione", piuttosto ambiguo. Se alcune modifiche a livello di istruzione al layout della memoria e ai modelli di accesso rendono qualcosa 80 volte più veloce da un professionista disciplinato che misura i loro hotspot senza ridurre la complessità algoritmica, è una "micro-ottimizzazione"? Per me questa è una "mega-ottimizzazione" per rendere qualcosa 80 volte più veloce su un caso d'uso reale. Le persone tendono a parlare di queste cose come tali ottimizzazioni hanno effetti microscopici.
Non lavoro più in Gamedev ma lavoro in VFX in aree come il tracciamento dei percorsi e ho visto molte implementazioni di BVH e alberi KD là fuori che elaborano ~ 0,5 milioni di raggi al secondo su una scena complessa (e questo è con valutazione multithread). In parole povere, tendo a vedere un'implementazione diretta di un BVH in un contesto di raytracing a meno di 1 milione di raggi / sec anche con una valutazione multithread. Tranne Embree ha un BVH in grado di elaborare oltre 100 milioni di raggi sulla stessa scena con lo stesso hardware.
Ciò è interamente dovuto alle "microottimizzazioni" secondo cui Embree è 200 volte più veloce (stesso algoritmo e struttura dati), ma ovviamente il motivo per cui è molto più veloce è perché gli sviluppatori di Intel sono professionisti che si affidano ai loro profilatori e misurazioni e sintonizzato davvero le aree che contavano. Non stavano cambiando il codice, volenti o nolenti, per intuizioni e per apportare modifiche che apportavano miglioramenti dello 0,000000001% a scapito della degradabilità significativa della manutenibilità. Si trattava di ottimizzazioni molto precise applicate in mani giudiziose: avrebbero potuto essere microscopiche in termini di messa a fuoco ma macroscopiche in termini di effetto.
Naturalmente con i requisiti di frequenza dei fotogrammi in tempo reale dei giochi, a seconda del livello elevato o basso con cui stai lavorando con il motore di gioco (anche i giochi realizzati con UE 4 sono spesso implementati almeno parzialmente in script di alto livello, ma non, diciamo, le parti più critiche del motore fisico), le microottimizzazioni diventano un requisito pratico in alcune aree.
Un'altra area di base che ci circonda quotidianamente è l'elaborazione delle immagini, come la sfocatura delle immagini ad alta risoluzione in tempo reale e forse fare altri effetti su di esse come parte di una transizione che probabilmente abbiamo visto da qualche parte, forse anche un effetto OS. Non è possibile implementare necessariamente tali operazioni di immagine da zero ciclicamente attraverso tutti i pixel di un'immagine e aspettarsi tali risultati in tempo reale a frame rate corrispondenti. Se è la CPU di solito guardiamo al SIMD e qualche micro-tuning, o stiamo guardando gli shader GPU che tendono a richiedere un tipo di mentalità a livello micro per scrivere in modo efficace.
In caso affermativo, poiché l'hardware migliora, dovremmo aspettarci che linguaggi di livello superiore prendano il controllo dell'industria del gioco?
Dubito piuttosto che i soli progressi dell'hardware potrebbero farlo, perché man mano che l'hardware avanza, anche le istruzioni e la tecnologia (es: fisica su GPU), le tecniche e le aspettative dei clienti per ciò che vogliono vedere e la concorrenza, in modi in cui spesso gli sviluppatori passano di nuovo a basso livello, come anche nel caso degli sviluppatori Web che ora scrivono shader GLSL di basso livello in WebGL (lo sviluppo web di questo tipo particolare è probabilmente anche di livello inferiore rispetto a un decennio o due fa, dato che GLSL è un linguaggio di livello C di livello estremamente basso, e non avrei mai immaginato un decennio o due fa che alcuni sviluppatori web avrebbero accettato di scrivere shader di GPU di basso livello).
Se ci sarà un modo in cui le aree critiche per le prestazioni passeranno a linguaggi di livello superiore, dovrà provenire maggiormente dal software, dai compilatori e dagli strumenti di cui disponiamo a mio avviso. Il problema per me in un futuro prevedibile non è che l'hardware non sia abbastanza potente. Ha più a che fare con il modo in cui non riusciamo a trovare il modo di parlarci nel modo più efficace ogni volta che cambia e avanza senza tornare di nuovo nella sua lingua. È in realtà il rapido ritmo con cui l'hardware cambia che rende la programmazione di alto livello piuttosto sfuggente per queste aree come la vedo io, poiché se ipoteticamente il nostro hardware ha smesso di avanzare all'improvviso per i decenni successivi,
Stranamente in questi giorni, quando lavoro in aree critiche per le prestazioni, devo pensare in qualche modo a un livello più basso di quello che ho iniziato (anche se ho iniziato nell'era Borland Turbo C DOS). Perché allora la cache della CPU era quasi inesistente. Per lo più era solo DRAM e registri, il che significava che potevo concentrarmi maggiormente sulla complessità algoritmica e scrivere strutture collegate come alberi in un modo molto semplice senza avere un grande impatto sulle prestazioni. In questi giorni i dettagli di basso livello della cache della CPU dominano il mio pensiero quasi quanto l'algoritmo stesso. E allo stesso modo abbiamo macchine multi-core che devono farci pensare al multithreading e agli atomici e ai mutex e alla sicurezza dei thread e alle strutture di dati simultanee e così via, che direi che è, sotto molti aspetti, un focus di livello molto più basso (come in, non così umanamente intuitivo) rispetto a quando ho iniziato.
Stranamente mi sembra molto vero ora. Penso di essere più influenzato dalle complessità e dai dettagli di base e di basso livello dell'hardware oggi rispetto a 30 anni fa, facendo del mio meglio per togliermi gli occhiali nostalgia. Ovviamente potremmo aver parlato un po 'di assemblaggio qui e abbiamo dovuto affrontare alcuni dettagli cruenti come XMS / EMS. Ma per la maggior parte direi che c'era meno complessità e consapevolezza dell'hardware e del compilatore di cui avevo bisogno allora rispetto a oggi quando lavoro in aree critiche per le prestazioni. E questo sembra quasi vero per l'intero settore se mettiamo da parte come la scritturaif/else dichiarazioni in un modo leggermente più umanamente leggibile e considera quante persone in generale in questi giorni stanno pensando di più ai dettagli di livello inferiore dell'hardware (da più core alle GPU al SIMD alla cache della CPU e ai dettagli interni di come i loro compilatori / interpreti / le biblioteche funzionano e così via).
Alto livello! = Meno efficiente
Tornando a questa domanda:
In caso affermativo, poiché l'hardware migliora, dovremmo aspettarci che linguaggi di livello superiore prendano il controllo dell'industria del gioco?
Per me non si tratta di hardware. Si tratta di ottimizzatori e strumenti. Quando ho iniziato, le persone praticamente scrivevano tutti i giochi per console in assembly, e c'era un vero vantaggio in termini di prestazioni, soprattutto in considerazione della mancanza di compilatori di qualità che generavano 6502.
Quando l'ottimizzazione dei compilatori C è diventata più intelligente nelle loro ottimizzazioni, hanno iniziato a raggiungere un punto in cui il codice di livello superiore scritto in C era in competizione e talvolta superava anche il codice scritto dai migliori esperti di assemblaggio in molte aree (anche se non sempre), e ciò ha reso quindi quindi un gioco da ragazzi adottare C almeno per la maggior parte della codifica per un gioco. E un cambiamento simile è avvenuto gradualmente a un certo punto con il C ++. L'adozione del C ++ è stata più lenta poiché ritengo che l'incremento della produttività nel passaggio dall'assemblaggio al C potrebbe probabilmente raggiungere un accordo unanime da parte di gamingevs che scrivono giochi non banali interamente in ASM invece di passare dal C al C ++.
Ma questi cambiamenti non derivavano dal fatto che l'hardware diventasse più potente tanto quanto gli ottimizzatori per questi linguaggi che rendevano il livello più basso (sebbene non sempre del tutto ci siano alcuni casi oscuri) obsoleto.
Se riesci a immaginare uno scenario ipotetico in cui potremmo scrivere il codice nel codice di livello più alto immaginabile, senza preoccuparti di multithreading o GPU o mancati cache o qualcosa del genere (forse nemmeno strutture di dati specifici) e l'ottimizzatore era come un'intelligenza artificiale intelligente e potrebbe capire i layout di memoria più efficienti riorganizzando e compattando i nostri dati, scoprendo che potrebbe usare qualche GPU qua e là, parallelizzare un po 'di codice qua e là, usare qualche SIMD, magari profilare se stesso e continuare a ottimizzare ulteriormente il suo IR come noi umani rispondendo agli hotspot del profiler, e lo ha fatto in un modo che batte i migliori esperti del mondo, quindi sarebbe un gioco da ragazzi anche per coloro che lavorano nei settori più critici per le prestazioni adottarlo ... e questo è un progresso proveniente da ottimizzatori ridicolmente intelligenti, non hardware più veloce.