Assassin's Creed migliore per intelligenza artificiale su XBox 360?

Il problema del processore Cell non è certamente la difficoltà nell'elaborare applicazioni General Purpose delle sue 7 sotto-unità*, bensì nel modo in cui queste devono essere gestite per ottenere il massimo delle prestazioni.

Laddove i tre core della 360 forniscono a livello logico, similmente alle architetture dei recenti Desktop PC, la possibilità di gestiste sei thread indipedenti in modo del tutto immediato, ben diversa è la filosofia del Cell che, è bene ricordare, è nato dalla IBM come soluzione server/workstation e poi adottato dalla Sony per la sua console. Nonostate le unità sinergistiche sono molte, esse sono strutturate per favorire il coordinamento e la comunicazione tra esse a discapito della indipendenza logica. In teoria le SPU possono svolgere compiti distinti, però, studiando nei dettagli l'architettura, ci si accorge di molte ottimizzazioni e di alcune scelte rivolte a facilitare la comunicazione e l'elaborazione, diciamo tra virgolette, "sincronizzata" tra loro. Si pensi ad esempio al BUS gestito con protocollo derivato dal classico token ring, scelta molto semplicistica ed utile solo se i dati che devono viaggiare hanno alta probabilità di trovare il destinatario tra gli immediati vicini. Anche la facilità con cui una SPU accede allo spazio dati dell'altra è un ulteriore indizio in tal senso.

Gli impressionanti limiti teorici del Cell vengono di fatto raggiunti quando si cerca di portare la comunicazione a diventare una sorta di vera e propria pipeline a livello di macroistruzioni i cui stadi di parallelizzazione vengono svolti dalle SPU stesse. Ed è porprio su questo punto che i programmatori incontrano maggiori difficiltà nell'ottimizzazzione, in quanto, gestire una parallellizzazione dell'esecuzione di una operazione estremamente complessa non è facile, richiede conoscenze perfino della tempistica media delle macroistruzioni stesse.

E' bene ricordare che tutto ciò va incontro proprio ad applicazioni server, macchine predisposte a svolgere computazioni di calcolo estremamente complesse e su enormi quantità di dati, a discapito di applicazioni multitask ed in real-time quali quelle videoludiche. Anche la particolare gestione della cache delle SPU, dove non esplicitamente gestito a livello hardware alcun algoritmo di predizione, da un'ulteriore palese prova di ciò che ho appena detto: in applicazioni SIMD su workstation è solitamente più facile effettuare una predizione delle istruzioni successive, ben diversa è la situzione in gioco dove la banda di utilizzo di caching è molto più influente.

Infine si fa notare che SPU sono coordinate da un'unità centrale PowerPC la cui frequenza a 3.2GHz ed implementazione di una sorta di HyperThreading, è comune a uno solo dei core sulla 360.

Con questo non voglio certo demolire la PS3 le cui potenzialità sono estremamente più alte rispetto alla 360, solo dare un'idea chiara del motivo per cui la 360 riesce a gestire meglio un motore multithread. Questa volta mazzette di Zio Bill credo proprio non ce ne siano, anche perché andrebbe contro gli interessi di una SH multipiattaforma ed in continua ascesa quale la Ubisoft.


[*] Non è vero che ne funzioneranno solo 5 o 6, saranno 7 sulle 8 presenti nel chip ad essere abilitate.

non mi sono spiegato bene scusa

ho detto che funzioneranno solo 5 o 6 per il semplice fatto che 1 spe viene utilizzata al 100% dal SO della ps3 e quindi non è utilizzabile dal motore di un gioco, inoltre quando verrà utilizzato il servizio live della ps3 per gestire chat in tempo reale e comunicazione video viene utilizzata anche un ulteriore spe rendendola di fatto non sfruttabile se non in parte daigli sviluppatori.

questo è almeno quello che si trova negli sdk della ps3, che non ho io ma amici oltreoceano

@Jon_Snow: scusa ma se come dici tu il problema e' semplicemente di branch prediction e salti, non si risolve col vecchissimo metodo del case multicondizione?
(in pratica si effettua un numero molto minore di salti preparando prima un valore corrispondente all'insieme delle condizioni con istruzioni IF a salto minimo (1 istruzione) e poi effettuando un salto piu' grosso guidato da
una "tabella" opportuna).

Almeno questo era il metodo che si usava in tempi antichi.(la
tabellizzazione di seni e coseni e' stata alla base del 3D....)

Quanto al problema della sincronizzazione delle SPU, non mi pare un grosso
problema: perche' si dovrebbe usare del tempo-macchina per eseguire esclusivamente l'AI quando la si puo'
eseguire in background dedicandole esclusivamente 1-2 SPU e "mescolando"
il codice general purpose in vari punti dentro il ciclo per la generazione di ogni
frame? ( portando cosi' i problemi di sincronismo a zero o quasi, visto che
si "dilata" l'esecuzione nel tempo quasi come se fosse un processo in
background lanciato su una CPU secondaria).

O e' una cosa troppo difficile/complicata per i programmatori della
Ubisoft? Avendo 7 spu da usare (ok, meno una per il sistema
operativo...) potrebbero anche decidere di sfruttarle
tenendone 1-2 riservate all'AI, o no?
Farei notare che quelli della Bethesda che hanno portato il RadiantAI
su PS3 (perche' Oblivion sara' disponibile da novembre) non hanno
annunciato niente di simile, e dubito che l'AI di Assassin Creed possa
essere cosi' tanto piu' avanzata del RadiantAI (attualmente la migliore AI
mai messa in un videogioco) da costituire caso a parte...

@DevilsAdvocate: no stando a ciò che dice Jon_Snow le risorse condivise dalle SPU sono talmente sincronizzate che se non implementi il tutto in stile pipeline hai un degrado quasi totale delle performance. stando cosi le cose ti serta solo il core mutipurpose per implementare l'AI, anche perche non credo tu possa materialmente combinare una serie di if in un salto solo, gia con (esempio) 8 sei a 2^8 salti, senza contare che alcuni salti futuri potrebbero essere condizionati da computazioni su salti precedenti (molto propabile inquanto trattasi di un contesto di AI) il che manda a pu77ane tutto il discorso, metti il caso che gli if da aggregare siano 10 invece di 8... la manutenibilità del codice e soprattutto i tempi fisici per implementare questo disastro salgono esponenzialmente (e non a caso!) e con loro i costi

Non credo che l'uso della semplice chat possa occupare una intera SPE,
(ne usera' si e no il 5%), mentre ritengo ovvio che se abiliti la
comunicazione video (webcam di tutti i partecipanti al gioco) una certa
potenza la devi prendere da qualche parte..... (e' gia' molto carino che
basti una singola SPE per gestire tutti i dati dei flussi video di una decina
di giocatori! Non credo che su Xbox360 sara' possibile niente di
paragonabile...). Comunque entrambi i casi chat/videochat valgono solo
per i titoli multiplayer, non e' questo il caso.... hanno 6 SPE a
disposizione per Assassin Creed.

Questo e' in contraddizione con quanto detto da Coschizza: come
potrebbero allora dedicare 1 SPE esclusivamente al sistema operativo
ed una al sistema di videochat? Allora le prestazioni sarebbero sempre e
comunque "degradate" dalla SPE che controlla il so,e tutto il discorso
non avrebbe senso perche' implementare l'AI in questo modo non
degraderebbe alcunche'....

quanto ai 2^8 salti (256), una tabella con 256 indirizzi di memoria non
mi pare questo incredibile sforzo, quanto occupera' mai, 1-2Kb?
Se gli IF da aggregare sono 10 ne tieni 2 normali e ne aggreghi 8,
passi comunque da 10 salti "lontani" a 3, una velocizzazione non da
poco. (10/3 *100% = 333,3% cioe' il 233,3% piu' veloce sui salti...)

non è la dimensione della tabella che mi preoccupa, ma il codice che DEVI riscrivere per ogni combinazione di condizioni, che nel caso peggiore è distinto da ogni altra situazione per delle inezie (piccole porzioni che con una struttra a if classica sarebbro probabilmente più manutenibili), ma a parte questo resta il problema, ben più grosso, delle computazioni basate su salti precedenti, che volendo sempre guardare il caso peggiore, potrebbero essere ad ogni brench.

con le ADSL che troviamo in giro penso che neanche la ps3 potrà gestire tutti i dati dei flussi video di una decina di giocatori, e gia tanto se i giochi non avranno troppi lag

per quello che riguarda la gestione delle chat e dell'audio non ho sottomano dati per la ps3 ma ho quelli della xbox 360 che come saprai non ha un processore audio inclusa (come la ps3 delresto) e quindi la MS ha stimato in 20-25% l'occupazione massima di 1 delle cpu (piu precisamente 1 dei 2 thread hadware disponibili per cpu), questo per gestire via software il mixer audio.

quindi non so se gli sviluppatori vorranno sovvracaricare la spe utilizzata per l'audio con altri componenti del motore. Questo visto che anche sulla 360 cercano di non metterci codice fondamentale o che deve aver a disposizione tutta la potenza.

non mi pare ci sia cosi' tanto codice in piu', invece di (semplifico, in
realta' nel caso 2 sara' 1 case invece di molti if)
[code]
if (condizione a) then (jump(1))
if (condizione b) then (jump(2))
1 if (condizione c) then (jump(...))
if (condizione d) then (jump(...))
2 if(condizione e) then (jump(...))
......
[/code]
si usa:
[code]
if (condizione a) then (salto.var=1)
if (condizione b) then (salto.var=2)
if (condizione c) then (salto.var=3)
if (condizione d) then (salto.var=4)
.......
/*fine degli if*/
jump.derived (salto.var)
[/code]
facendo attenzione a conoscere dove son mappate in memoria le "label"
a cui saltare (ovviamente la tabella non si costruisce a mano ma
attraverso scripting/programmino dedicato, come il case of puo' essere
scritto "aiutandosi" con varie utility, addirittura si puo' pensare a crearsi
un tool che legge il codice sorgente del caso 1 e lo trasforma automaticamente in quello del caso 2)

Mi pare strano che con tutte queste grandi capacità di calcolo delle nuove console ci sia comunque così tanta differenza, non sono un grande esperto ma così a primo impatto pare più una questione di ottimizzazione dell'IA più che una migliore gestione da parte di una console rispetto un'altra...