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

[george_p]

Mamma mia che informazioni

Manca solo la conferma che i 20 core derivino dai kabini/puma/etc...
Attendiamo le fonti di Fottemberg.

Se danno quello che promettono come prestazioni ben vengano i kabini/puma

[gridracedriver]

Mamma mia che informazioni

Manca solo la conferma che i 20 core derivino dai kabini/puma/etc...
Attendiamo le fonti di Fottemberg.

Se danno quello che promettono come prestazioni ben vengano i kabini/puma

io aggiungo: speriamo derivino da puma
e poi appunto derivino vuol dire tutto e niente... magari avranno il 50% di Puma, il resto ex-novo... si può ancora dire che sono derivati cosi?...non credo... alla fine una cpu x86, bene o male sempre un certo schema deve avere, e a seguire questa logica sono tutti "derivati" allora... l'importante è che sia efficiente e con un IPC doppio o quasi a BD_Zambezi e da viaggiare sui 3 ghz, il resto è noia...

[Sasha]

e allora non sono derivati di Jaguar/Puma, con quelle prestazioni (IPC doppio (parecchio migliore anche di Haswell) e frequenza a 3,0 GHz)

[dobermann77]

IPC doppio (parecchio migliore anche di Haswell)

ROTFL vabbè...
Esce tra n anni, la prima versione sarà troppo nuova quindi dovremo aspettare la seconda, poi i programmi non saranno ottimizzati per 20 (!) core... etc... solito disco...

[Sasha]

già, difficilmente avrà senso in ambito consumer, anche nel 2016... già un LGA2011 con otto core/16 thread ha senso in pochissimi ambiti... figurati un 20 core, sicuramente con IPC più basso del mainstream Intel di quel periodo (Skylake?)...

[Alessio89]

Questa storia dell'ottimizzazione per n-core se permettete ha rotto le palle.
Certe task non verranno mai parallelizzate per un semplice motivo: non ha senso.
Il grosso delle task delle applicazioni comune si svolge in maniera seriale, non solo perché sono state scritte e pensate così ma perché è il modo migliore per farlo in termini prestazionali.
Al di là delle simulazioni (e i giochi sono simulazioni) o delle attività di codifica e decodifica di stream, il software difficilmente riuscirà mai ad ottenere vantaggi tangibili dall'essere "spalmato" su n-core, al di là delle task di background (cosa che avviene già), stessa cosa per i sistemi operativi dove il grosso del possibile ormai viene già effettuato.

Quel che importa invece è che con l'aumentare dei core virtuali in una CPU diminuiscano le latenze di sincronizzazione di accesso a cache e memoria e che l'IPC aumenti, altrimenti è praticamente tutto inutile. E non mi riferisco solo ad AMD. E in ogni caso se AMD non porrà un drastico rimedio ad IPC, latenze cache/memoria primaria e memory conroller, i 20 core se li metteranno nel sedere perché c''è il forte rischio che un dual core con hyper threading vada meglio pure per sistema software progettato da 0 pensato esclusivamente a quei dannati 20 core. Se poi invece ci riusciranno, e credo che tutti tranne il CDA della intel lo speri, allora tanto di cappello e finalmente avremo un po' di innovazione a livello hardware senza dover ricorrere ad istruzioni particolari per attività particolari. Non parliamo poi dei bus fra la CPU e il resto del mondo in cui vive visto che per ora l'unica soluzione proposta è una cosa a dir poco demenziale da NVIDIA (il cui unico risultato sarebbe cambiare tutto il sistema ad ogni aggiornamento di GPU o della MB o della CPU, altro che i cambi socket di intel).

Per il GPGPU il discorso è lo stesso, anzi ancora più restrittivo vista la natura delle ALU delle GPU.

Che poi dal lato software vi siano degli esempi lampanti di quel che letteralmente si potrebbe definire come "codice scritto con lo sterco" è ovvio, come un certo middlware di simulazione fisica fantozziana (ogni riferimento non è casuale se associato al colore verde e ad un isola asiatica non riconosciuta da nessuno sulla terra come nazione), ma non potete pensare che tutto il software, compresi i giochi, di oggi vadano male su n-core perché non sono pensati per n-core, certe cose si fanno meglio e prima in maniera seriale, mentre altre sono semplicemente scritte col deretano.

[dobermann77]

Questa storia dell'ottimizzazione per n-core se permettete ha rotto le palle.
Certe task non verranno mai parallelizzate per un semplice motivo: non ha senso.

Concordo.

[Grizlod]

@ Alessio89: Concordo sostanzialmente con quanto hai scritto, tuttavia qualcosa si sta muovendo in campo videoludico, quindi, quaslcosa si puo fare; tant'è vero che i requisiti hardware (raccomandati) per 'Project Cars' non sono per nulla scarsi (diciamo così...). Sia l'i7 37xx, che l'FX 8350, supportano 8 threads...

http://www.pcgamer.com/2014/07/28/proje ... -the-test/

L'uscita del gioco è prevista per Novembre ed a giudicare da immagini e filmati, la grafica sembra veramente accattivante:
http://multiplayer.it/giochi/cars_a-per-pc.html

[george_p]

Che poi dal lato software vi siano degli esempi lampanti di quel che letteralmente si potrebbe definire come "codice scritto con lo sterco" è ovvio, come un certo middlware di simulazione fisica fantozziana (ogni riferimento non è casuale se associato al colore verde e ad un isola asiatica non riconosciuta da nessuno sulla terra come nazione), ma non potete pensare che tutto il software, compresi i giochi, di oggi vadano male su n-core perché non sono pensati per n-core, certe cose si fanno meglio e prima in maniera seriale, mentre altre sono semplicemente scritte col deretano.

Non riesco a fare l'associazione, se non a due aziende diverse, una per il colore l'altra per l'isola asiatica (credo)

[Alessio89]

Che poi dal lato software vi siano degli esempi lampanti di quel che letteralmente si potrebbe definire come "codice scritto con lo sterco" è ovvio, come un certo middlware di simulazione fisica fantozziana (ogni riferimento non è casuale se associato al colore verde e ad un isola asiatica non riconosciuta da nessuno sulla terra come nazione), ma non potete pensare che tutto il software, compresi i giochi, di oggi vadano male su n-core perché non sono pensati per n-core, certe cose si fanno meglio e prima in maniera seriale, mentre altre sono semplicemente scritte col deretano.

Non riesco a fare l'associazione, se non a due aziende diverse, una per il colore l'altra per l'isola asiatica (credo)

Credi veramente che a Santa Clara ci sia qualcos'altro oltre a dei colletti bianchi obesi? Il grosso dell'r&d viene fatti alla sede di Taipei, sono un'azienda californiana solo sulla carta..

@ Alessio89: Concordo sostanzialmente con quanto hai scritto, tuttavia qualcosa si sta muovendo in campo videoludico, quindi, quaslcosa si puo fare; tant'è vero che i requisiti hardware (raccomandati) per 'Project Cars' non sono per nulla scarsi (diciamo così...). Sia l'i7 37xx, che l'FX 8350, supportano 8 threads...

http://www.pcgamer.com/2014/07/28/proje ... -the-test/

L'uscita del gioco è prevista per Novembre ed a giudicare da immagini e filmati, la grafica sembra veramente accattivante:
http://multiplayer.it/giochi/cars_a-per-pc.html

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.