[cdimauro]

Originariamente inviato da GTKM

Comunque, credo sia la settantesima volta che viene affrontata questa stessa discussione.

Visto che siamo nel 2016, non è che magari si potrebbero portare prove di pratiche scorrette di Intel IN TEMPI RECENTI?
Oppure ogni volta dobbiamo continuare a parlare "di quella volta in cui..."?

Ora faccio incazzare un po' tutti: a me, ad esempio, già sembra uno schifo il fatto che Intel debba dare licenze x86 sulla base di pressioni esterne. Si tratta di una architettura che hanno tirato fuori loro, con soldi loro, quindi, secondo me, dovrebbero poterci fare il cazzo che vogliono. Così come la storia di Microsoft e i browser, insomma.

Quoto tutto, parola per parola.

Originariamente inviato da tuttodigitale

il problema è se quella applicazione, crea discrepanze di tale entità nel risultato finale, rende il tutto fuorviante e sbagliato, tanto da rendere inspiegabili i numeri. Su questo credo che tu sia d'accordo con me. Purtroppo non c'è molto da aggiungere, mancano dati su cui si può discutere.

Assolutamente. Ed è un peccato, perché sono curioso di capire cos'è che succede.

Fermo restando che oggi la Creative suite usa per le funzioni più complesse anche la GPU. In effetti già qui dovrebbe cadere il mito che è il numero a determinare l'importanza della GPU, quando volenti o non sono proprie le nuove funzioni quelle a determinare un aumentata richiesta di calcolo, che possono essere effettivamente inutilizzabili con la sola CPU.

Detto questo, quando le redazioni testano la CPU lo fanno per lo più con la stessa GPU (e se è di fascia alta spesso, la CPU è determinante per le prestazioni della stessa), tanto più che FX spesso non ha un chipset con una integrata.
I risultati sono un poco diversi, pur testando grossomodo le stesse applicazioni. Da qui nascono le mie perplessità.

Ma fanno lo stesso anche i processori che hanno la GPU integrata? La disabilitano e mettono la stessa GPU discreta?

Lo scaling, è giusto tenerlo a mente, per capire cosa possa offrire al massimo un raddoppio delle risorse condivise. E parlo di raddoppio non a caso. Il CMT è una strategia che permette di dedicare più risorse al singolo core, aumentando di fatto le prestazioni nel ST. un uso più razionale delle stesse porterebbe ad una riduzione dell'ipc del singolo core.
Un esempio:
la D-L1 anzichè essere grande 96KB e condivisa tra i due core, poteva essere una 64KBx2. Le risorse dedicate di solito, sono anche difficilmente sfruttabili nella loro interezza.

Invece IMO il collo di bottiglia del CMT sta proprio nel fatto che ha delle risorse dedicate (e quindi non condivise), le quali, in genere, non sono sufficienti da sfruttare in scenari prettamente ST.

Sì, non v'è dubbio che sulla carta una cache dati L1 separata dovrebbe portare indubbi vantaggi, potendo le due cache sfamare parallelamente le due macro-ALU, ma c'è un grossissimo ma, che è rappresentato dal numero di unità di esecuzione di cui sono dotate le due macro-ALU: appena due per ognuna!

In ST (e tralasciando al momento l'FPU) è facile che vengano usate più unità intere, a tutto beneficio dell'IPC finale. Ma con la soluzione di AMD il massimo che puoi raggiungere è IPC = 2, anche se fosse possibile eseguirne ben più di 2.

Confrontalo coi core di Intel, che possono arrivare a un IPC = 4, potendo sfamare il thread più avido di unità intere, e si capisce bene dove stanno tutti i problemi della soluzione CMT di AMD.

Non credo ci sia da scomodare la teoria delle code per capire le implicazioni di queste scelte molto diverse: è meglio avere 4 unità liberamente (qui lasciami generalizzare) utilizzabili da due thread hardware (e quindi con la possibilità di essere sfruttate tutte dallo stesso thread, lasciando affamato l'altro, a seconda del carico di quel momento), che 2 vincolate a ogni specifico thread. Scenario, quest'ultimo, che è tranquillamente "emulabile" da quello molto più libero.

Non a caso si è passati dalle soluzioni pixel e vertex shader separati alle attuali architetture con shader unificati.

Appunto. Questo dimostra che la separazione di quelle unità di calcolo era decisamente non ottimale, perché un'unità poteva rimanere a girarsi i pollici mentre un'altra era stracarica di lavoro.

Uno shader generico può, invece, farsi carico di tutti gli scenari, impegnando al meglio le unità a disposizione.

Lo stesso dicasi per i decoder, condivisi in bulldozer/Pilediver. Siamo passati da una soluzione a 4 decoder condivisi tra 2 core, ad una 4x2 in Steamroller/excavator, inutile dire quanto siano sfruttate male le risorse in eccesso.

Appunto: perché hai le mani legate con quella configurazione.

In Carrizo/steamroller condividono solo la fase di fetch, già la decodifica viaggia su due piani separati. Da li in poi la parte int sono indipendenti, a spanne solo il 15% dell'intera pipeline è condivisa. A me pare tanto. Sarà questioni di punti di vista. Ma i numeri sono chiari, dedicando le risorse della fase di fetch e la FPU le prestazioni possono salire del 7%...

Beh, se dovessimo guardare i numeri e giudicare la bontà di questa soluzione, dovremmo parimenti chiederci come mai AMD stia abbandonando il CMT per l'SMT di Intel.

A parte questo, è vero che con le ultime incarnazioni c'è una minor condivisione di risorse, ma rimane ancora una parte della pipeline condivisa, inclusa la preziosa cache codice L1, e l'FPU: roba non da poco, e IMO che non giustifica l'etichetta di core per ogni thread hardware.

Questa è la mia visione, come tu giustamente hai la tua. Vediamo cosa deciderà il giudice nella causa in corso.