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

Esattamente quello che penso io, un'elaborazione dati attorno al 5% del
tempo di una SPE, visto che qui i salti sono circa zero.
(ricordiamoci che un Cell con 8 SPE gestisce 48 flussi mpeg2 risoluzione
DVD,cioe' 8 per ogni SPE, mentre una cpu general purpose senza
accelerazione della scheda grafica, occupava ben piu' del 30% del
tempo macchina su cpu a 2 ghz. (8 flussi = 240% del tempo macchina),
oggi non lo vediamo piu' perche' su PC e' tutto fatto sfruttando le
accelerazioni delle schede video).

Una info per chi giudica l X360 nuna macchinetta:

Non so se avete visto la presentazione in tempo reale di Alan Wake gestita solamente da un PC Quad Core...
L'uragano e la tempesta hanno sfuttato i quad core e come stesso ha detto il programmatore del gioco Alan Wake non potrebbe girare con questo tipo di effeti su di un PC double core...
Ovvero i super effetti (comunque anche i normali sono meravigliosi) gireranno alla grande sul X360 che è 6 !!!! core...

Cio che abbiamo visto da un anno fino ad ora è veramente un assaggio anche se è difficile da credere perchè chiunque habbia giocato KAMEO (e soffrmatosi a vedere tutto il mondo circostante) è rimasto allibito da cosa è riuscita a fare la RARE... ovvero cio che sognavo anni fa.. gioche stile CGI in tempo reale...

Byexx...

@devilsavvocate

probabilmente non hai capito, ci riprovo:

(Nota: dal forum si vede meglio)
[PHP]
if (A) {
istruzioneA
if (B) {
istruzioneB
}
else {
istruzioneC
}
}
else {
istruzioneD
if (C) {
istruzioneE
}
else {
istruzioneF
}
[/PHP]
diventa
[PHP]
if (A&B) {
istruzioneA
istruzioneB
}
if (A&!B) {
istruzioneA
istruzioneC
}
if (!A&C) {
istruzioneD
istruzioneE
}
if (!A&!C) {
istruzioneD
istruzioneF
}
[/PHP]

ora ti chiedo di fare l'enorme sforzo di immaginazione di aggiungere altri livelli di if al primo caso e immaginarti quante volte devi replicare le istruzioni nel secondo caso per farlo venire analogo (nota che è pseudocodice, con "!A&!C" intendo il tuo indice che corrisponde alla sitazione in cui è falso il salto associato ad a e c, ad esempio)

ora, è VERISSIMO che puoi scriverti un codice che faccia queste trasformazioni quando è possibile ossia tutte le codnizioni sono GIA VALUTABILI prima del primo if, e NON È SEMPRE COSÌ, ma a questo putno lo vedi che è più costoso il secondo approccio? hai addirittura bisogno di sviluppare un tool per scriverti gli if... non è per niente una bella cosa, e poi chi lo mantiene? quando fai una modifica ad esempio all'istruzioneA la devi cambiare intutti i blocchi altrimenti hai bug a cascata.

considera inoltre che nel primo caso arrivi al blocco di istruzioni da eseguire con un albero, nel secondo caso invece è come scorrersi una lista, è svantaggioso in tutti i sensi a meno che non sia possibile indicizzarei l salto al posto giusto con un calcolo in tempo costante, ma non sembra questo il caso

spero di essere stato chiaro questa volta.

Ok avevo capito male, sorry!



Prima di risponderti vorrei precisare che i miei sono stati esempi per dare l'idea su un'architettura [u]realmente[/u] innovativa, il processore Cell è una grande opera ingegneristica che gode di tutta la mia ammirazione è stato un piacere poterla studiare.
Tornato alla tua domanda, hai intuito bene l'idea della IBM che tra le altre cose si era già vista parecchi anni fa ed è stata ripresa oggi con i tempi e dimensioni di cache più maturi.

Per qualsiasi CPU, la banda di cache utilizzata è fortemente legata a come è scritto il programma sia logicamente e sia a livello di linguaggio macchina. Esistono molte tecniche che aiutano nel predirre l'istruzione successiva o comunque a limitare i casi di stallo. Ottimizzazioni del genere solitamente sono effettuate già dal compilatore e dai kit di sviluppo stessi che ovviamente prima di raggiungere una certa maturità necessitano di molto tempo.

Nel caso delle SPU tutto ciò è reso ancora più estremo spostando ulteriormente il punto focale a livello software dovendo gestire "a mano" (ovviamente con l'aiuto dei compilatori) la caching stessa senza il supporto di unità elettroniche. Una scelta del genere non è da folli perché la linea di principio e simile all'idea dei RISC PowerPC: snellirre la complessità hardware per diminuire i ritardi dovuti ad un numero eccessivo di porte logiche necessarie per gestire algortimi complessi. In altre parole la cache è più veloce di quelle tipiche per PC. Ovviamente la complessità di progettazione del software aument, certamente ciò che dici potrebbe essere una delle tante vie. Il problema è che tutto è legato all'applicazione stessa e nei giochi, dove il real-time è un fattore cruciale, il modo con cui si limita l'accesso diretto in RAM diventa di cruciale importanza.

Anche se a parole potrebbe sembrare facile, in realtà non lo è affatto, è sicuramente un'aggiunta in più ai programmatori. Daltro canto i margini di miglioramento sono molto elevati e legati soprattutto allo sviluppo dell'SDK da parte di Sony. Il fatto che li abbia presentati con enorme ritardo alle case terze la dice lunga su quanto difficile e su quanto importanti siano.



Il problema è che le SPU per come sono pensate non sono paragonabili a core indipendenti, forzandole a tale funzionamento si perdono molte delle vere potenzialità del Cell. Assegnare compiti del tutto indipendenti non si sfruttano le possibilità di comunicazione tra le unità, e si potrebbero intercorrere a colli di bottiglia imprevisti. Ad esempio il BUS EIB tra i coprocessori è pensato per favorire passaggi di dati tra SPU molto vicine, tanto è vero che gli ingegneri hanno bloccato la possibilità di spedire byte ad un'unità troppo "distanti".

Assegnando alle varie SPU codice GP senza un determinato criterio si rischia di generare una eccessiva mole di dati. In realtà la strada da seguire è quella che hai intuito tu: cercare di "mescolare" le varie operazioni tra i coprocessori piuttosto che assegnare compiti specifici ad ognuno di essi. Sembra facile? Non lo è affatto. Il parallismo per essere sfruttato al meglio rischiede molta esperienza. Il rischio è quello di sbilanciare il carico tra le SPU ed è bene precisare che tutto ciò è a livello [u]macchina[/u] e non applicativo.

No, non è facile per niente. Ovviamente la Ubisoft ha tutti i mezzi per poterlo fare, ma un conto è la teoria, altro è la pratica con costi e tempi ristretti.

Scusate, apparte i tecnicismi e le considerazioni sulla convenienza o meno per UBISOFT di "studiare" il CELL, ma se non erro Assanins Creed era nato come esclusiva PS3, quindi in teoria se dovevano metere più impegno da una parte avrebbe dovuto essere proprio la parte Sony. Invece hanno completamente ribaltato la frittata. Questo è forse indice di una "estrema" sconvenienza nel cercare ottimizzazione per il CELL?
Che ne pensate?

bhe ovviamente non sta a me decidere se ad Ubisoft conveniva o meno puntare sulla PS3, se hanno fatto questa scelta hanno avuto i loro motivi.

La tua considerazione in realtà è più che esatta e ti quoterei in pieno se non fosse per un particolare, che già versione vista all'E3 girava su X360 anche se presentata allo stand Sony! Lo so, sembra assurdo, ma tempo fa avevo letto un articolo a riguardo, passato in sordina a quanto pare, e non ho letto di smentite in giro per la rete.

la X360 non è a 6 core...ha tre core fisici capaci ciascuno di 2 thread

e chi sarebbè?

se non erro è la ragazza (produttore del gioco per l'ubisoft) che ha mostrato la demo all' x6 della scorsa settimana.

'usti...che bella presenza