Quanto assembly viene realmente utilizzato nel moderno codice di gioco? [chiuso]

In media, con quale frequenza viene utilizzato assembly nel moderno codice di gioco?

In particolare su piattaforme che dispongono già di buoni compilatori C ++, come x86, PPC o ARM, perché presumo che i giochi su sistemi embedded facciano largo uso dell'assembly.

La risposta dipende un po 'da cosa intendi per "gioco" e da "usato". Presumo che "usato" significhi "scritto nel corso del progetto di gioco specifico".

Nella mia esperienza e dati aneddotici di persone con cui ho parlato:

• nei giochi basati su browser? Nessuna.
• nei tipici giochi per PC? Nessuna. (Ma potresti vederne alcuni nelle librerie di basso livello.)
• nei giochi iOS e Android? Nessuna.
• Giochi per PC e console "AAA"? Forse un po ', forse 0,05% della base di codice. (Con un po 'di più nelle librerie.)

La conoscenza del linguaggio assembly non è prevista per il lavoro nel settore dei giochi, ma a seconda del tipo di giochi creati, potrebbe rivelarsi vantaggiosa.

In passato si sosteneva che il compilatore svolgesse un lavoro migliore nell'ottimizzazione del codice C rispetto a un umano con un assembly scritto a mano. Di solito è vero, a volte è falso. Ma in questi giorni una combinazione di complessità della CPU in costante crescita e la necessità di ridimensionare "out" (cioè per separare i processori) significa che gli sforzi di ottimizzazione vengono solitamente spesi altrove.

Negli ultimi anni l'unica volta in cui ho visto l'assemblaggio nel codice di gioco sono state le __asm int 3dichiarazioni per forzare i punti di interruzione, e il mio unico uso personale dell'assemblaggio era guardare allo smontaggio di una funzione per diagnosticare insoliti bug di crash.

La maggior parte del codice ad alte prestazioni nei moderni giochi per console è scritta usando una sorta di via di mezzo tra assembly e C ++: intrinseci del compilatore . Questi costrutti sembrano e analizzano le funzioni C ++, ma in realtà sono tradotti in istruzioni di una singola macchina . Quindi, ad esempio, la mia funzione "blocca ogni valore del vettore V per essere> = ae <= b" appare come

// for each v.x, ensure v.x >= a.x && v.x <= b.x
inline __m128 ClampSIMD( const __m128 &v, const __m128 & a, const __m128 & b )
{
    return _mm_max_ps( a, _mm_min_ps( v, b ) );
}

In funzioni come queste sto ancora pensando in termini di istruzioni specifiche della macchina , ma ho la comodità di scriverle in C in modo da non dovermi preoccupare della colorazione e della programmazione dei registri e caricare operazioni e altri dettagli noiosi.

Devi ancora essere consapevole delle istruzioni supportate dalla CPU, soprattutto perché i compilatori moderni sono terribili nel vettorializzare il codice, rispetto a quanto un umano intelligente può fare il lavoro. Inoltre, a volte sottili dettagli su come organizzare il codice possono avere enormi implicazioni per le prestazioni che non sono ovvie senza capire cosa sta facendo la macchina.

Anche se non possiamo programmare in assembly, eseguiamo comunque il debug in assembly molto. L'ottimizzazione dei compilatori riorganizza in modo aggressivo il codice in modi in cui i debugger non riescono a tenere il passo, quindi spesso quando si esegue il debug di una "modalità di rilascio", la cosa migliore da fare è aprire il disassemblatore e tracciare il codice in quel modo. Questo discorso del GDC sul "Debug forense" degli arresti anomali illustra molti dei perché e come del debug a quel livello.

I problemi che un tempo richiedevano il montaggio laminato a mano stanno diventando sempre meno numerosi. Ciò che "potresti" ottenere in velocità perdi in leggibilità e capacità di debug. Dovrebbe anche essere eseguito solo come uno degli ultimi passaggi di ottimizzazione su sezioni di codice poiché nella maggior parte dei casi i problemi di velocità non sono qualcosa che non può essere migliorato con l'assemblaggio. In questi giorni le CPU sono diventate molto più veloci mentre le velocità di memoria non lo sono, spesso è più importante controllare il modo in cui i dati scorrono attraverso la CPU di ogni altra cosa.

Con i compilatori moderni trovano anche difficile ottimizzare il codice assembly in quanto devono gestire i registri che hai toccato e di solito non possono riordinare le istruzioni nel codice creato a mano. Per ridurre la necessità di assemblaggio, ora ci sono anche elementi intrinseci che aiutano ad accedere a concetti di basso livello, ma in un modo che è facile da compilare e permettono loro di lavorare con te piuttosto che contro.

Detto questo, la SPU su PS3 è un'area in cui le persone devono ancora utilizzare l'assemblaggio per ottenere il massimo dal processore, con pipeline di istruzioni manuali, ad esempio, come spiegato qui .

Il fatto è che viviamo in un mondo multipiattaforma e parti del nostro codice di gioco devono essere adattate alla piattaforma locale - beh non è necessario, ma ci sono vantaggi se sfruttiamo le cose hardware locali!

Non si tratta di giochi o logica di gioco, si tratta di località hardware per prestazioni ottimali del codice su cui si basa la logica di gioco, possiamo effettivamente avvolgere sezioni di codice, ad esempio utilizzando macro, in modo che esista un codice sorgente, che funziona bene sul piattaforma contro cui è stata costruita.