Fino a 20 core x86 per le prossime CPU FX ed Opteron (2016-17)

[george_p]

NVIDIA sta cercando di risolvere la questione IPC tornando ad una architettura In-Order con Project Denver. Sembra un paradosso, in un'epoca dove anche Atom è passato da all'IO all'OoO, ma se il software è ben scritto sarà molto efficiente. NVIDIA, quindi, cercherà porre un maggiore accento all'ottimizzazione del software che a quella dell'hardware, soprattutto grazie a CUDA. Sarà una scommessa, però sono curioso di vedere dove porterà.

Nvidia sta facendo un eccellente lavoro con cuda a livello di diffusione ma odio i formati chiusi soprattutto quando si è costretti a comprare un hardware specifico per far funzionare un software con tutti i limiti e paletti che comportano.

[Grizlod]

Le simulazioni generalmente godono di un'ambiente multithreading, ma questo non significa affatto che il lavoro possa essere suddiviso equamente fra tutti i core disponibili. Ovviamente se riesci a gestire il tutto con task di complessità abbastanza ridotta è più semplice bilanciare il tutto, sempre che l'hardware lo permetta senza peggiorare le cose (e un 20 a moduli bulldozer peggiorerebbe le cose per esempio). Quasi mai tuttavia anche il software che trae giovamento da un'ambiente parallelo si riesce a "spezzettare" con task di durata breve e paragonabile, pertanto anche in quei software alla fine il una buona parte del tempo trascorso vede un thread unico fare il grosso del lavoro e gli altri rimanere in attesa, facendo girare i pollici al grosso della CPU. Il trucco nelle simulazioni sta nel ridurre il minimo possibile questo tempo e quello sprecato a sincronizzare le task.

In ogni caso, cmq la fisica (a meno di giochi ottimizzati per PhisX di Ageia/nVidia) sta sul groppone del processore; evidentemente se il gioco supporta multicores, essa è suddivisa fra quelli disponibili ( vedi 3DMark bench).

A tal proposito...volevo chiederti, data la tua esperienza informatica:
In merito al post di loneninja di questo thread: http://www.tomshardware.co.uk/forum/278 ... ideo-games
quali operazioni sarebbe possibile parallelizzare su più cores (a parte ciò che fa Windows in background)?

P.S. non voglio dimostrare che 20 cores sarebbero utili in ambito desktop (neppure a me sarebbero graditi)...

[Alessio89]

PhysX è programmato col culo, punto. Nacque per i co-processori di Age,a NVIDIA l'acquisto e lo tradusse coi piedi per le sue GPU (l'impatto prestazionale è notevole), e per anni ha lasciato l'implementazione software di ageia che era basata sulla FPU (istruzioni x87). La fantomatica nuova versione "ottimizzata per SIMD e multicore" sinceramente non l'ho vista in azione o se l'ho vista non ho notato differenze.
Altri motori fisici che fanno le stesse cose, come bullet ed havox per citare i più famosi, hanno un impatto nettamente inferiore.

Per quanto riguarda il parallelismo (e quindi una possibile implementazione multithreading), il divide et impera e la programmazione dinamica spesso sono ottimi candidati per il parallelismo. Tuttavia spesso la soluzione di un problema è semplicemente seriale, c'è poco poco da fare. Una soluzione è prendere i problemi seriali indipendenti fra loro e trattarli come "task" da far eseguire su thread diversi, la cosa funziona se questi hanno una complessità ed un tempo di esecuzione il più simile possibile e se sono tra loro indipendenti (compreso per l'accesso ad eventuali dati in memoria).

Le GPU sono ottimi esempi di computazione parallela, piccolo esempio: eseguire operazioni sui vertici o sui raster/pixel, in quanto sono in linea di massima indipendenti tra loro anche se appartenenti allo stesso buffer, dato che ad ogni vertice e pixel applichi un determinato algoritmo. Infine le GPU, pur essendo de facto dei grossi array di SIMD, sono sempre più simili alle MIMD, pertanto il problemi non si pongono purché siano di veloce esecuzione e bassissima complessità.

Per i videogiochi gli RTS sono anch'essi ottimi candidati nel trarre giovamento da ambienti multicore, Lì il problema principale sta poi nella sincronizzazione e nella lettura e scrittura dei dati comuni, problemi che non vengono ancora aiutati ad essere risolti dall'hardware attuale e dove il collo di bottiglia è la memoria principale sia come prestazioni (latenza e banda passante) sia come modalità di lavoro.

Questa era la situazione di Rome 2 Total War appena uscito: http://forums.totalwar.com/showthread.p ... fterburner

Ormai dopo quasi una ventina di patch (contando i mini fix) la situazione è nettamente migliorata (purtroppo non ho trovato benchmark al riguardo e non ho una CPU adatta per farlo), tuttavia puoi immaginarti un carico ridotto almeno di un terzo sul primo core (se non della metà) e spalmato nettamente meglio sugli altri.

Tieni conto che Rome 2, oltre ad essere uscito 6 mesi prima del dovuto, è pure basato su un motore "vecchio", il Warscape, che se lo tirano dietro da Empire, privo di supporto per i 64-bit.