AMD: i benchmark usati da Intel sono fuorvianti delle reali prestazioni di un sistema

[MaxFabio93]

Originariamente inviato da Bivvoz

La maggior parte della persone compra Intel perchè il commesso del mediaworld gli dice che è meglio, il commesso non sa se è vero ma ci sono più notebook con Intel esposti e quindi probabilmente è così.

Eh...figurati, arriveranno dal commesso con una frase del tipo: "Mio cugino mi ha detto che Intel è l'unico più potente".

Originariamente inviato da tuttodigitale

Ho fatto una rapida ricerca, scrivendo PA - sysmark e ho trovato diversi documenti.
Ne posto uno datato novembre 2013.
https://www.google.it/url?sa=t&rct=j...,d.d24&cad=rja
addirittura ho trovato riferimenti di sysmark nella gazzetta ufficiale. (<- è il benchmark di riferimento della PA)

Le preoccupazioni di AMD a questo punto sono chiare.

Questo per cdimauro, ecco come vengono i dubbi.

[tuttodigitale]

Originariamente inviato da link

the AMD representative admitted that it is likely that all SysMark development so far has been conducted internally at Intel by Intel.

Leggete:
http://www.vanshardware.com/reviews/...hlonXP2600.htm

[Alekx]

Non mi voglio ripetere o riaprire un dibattito vecchio come il cucco, AMD penalizzata nei tempi migliori e purtroppo e' rimasta cosi' per gli anni successivi.

Al di la' dei suoi sbagli ne ha fatti e ne sta facendo tanti a mio parere, INTEL ha venduto CPU molto sovravvalutate rispetto alle loro reali capacita', grazie al fatto di mettere bocca in tutti i rami, giustificandosi comunque che i benck ( a mio avviso in qualche modo "truccati") pesassero a suo favore.

Se poi questi benck vengono presi anche dalla PA come riferimento ecco che mi viene una grassa risata su chi potrebbe spendere la meta' dei soldi per avere le stesse prestazioni in ambito di office Automation. Tanto che Word si apre in 1 secondo o 1 secondo e mezzo non pesno che cambi la vita del dipendente pubblico. Ma le tasche ne avrebbero guadagnato e di molto.

Poi non ci scordiamo che anche microsoft ha fatto la sua avendo ottimizzato XP per anni sui processori intel al contrario degli AMD che dovevano in qualche modo funzionare come "compatibili". E tutti sappiamo che un software ottimizzato e compilato ad-hoc e' di gran lunga piu' performante.

Quindi tirando le somme in tempi buii INTEL con il suo peso e' riuscita sempre in qualche modo a tirare l'acqua al suo mulino con piu' o meno ricatti e rifinanziarsi comunque vendendo CPU farlocche piu' vicino a forni a microonde con prezzi esorbitanti.

[GTKM]

Originariamente inviato da Alekx

Quindi tirando le somme in tempi buii INTEL con il suo peso e' riuscita sempre in qualche modo a tirare l'acqua al suo mulino con piu' o meno ricatti e rifinanziarsi comunque vendendo CPU farlocche piu' vicino a forni a microonde con prezzi esorbitanti.

Invece gli FX...

[cdimauro]

Originariamente inviato da tuttodigitale

Cerco di essere coinciso:

L'importante è non essere circoncisi.

A parte gli scherzi, abbiamo già scritto molto, e mi limiterò anch'io ad alcune cose.

EDIT: rileggendomi, ho fallito...

Bulldozer può eseguire fino a 4 macro-ops per ciclo di clock
Non è affatto vero che l'ipc sia limitato a 2. Un core bulldozer nel singolo thread ha la bellezza di 8 porte di esecuzione, contro le 6 (le ALU/FP sono mutualmente dipendenti) di SB. Ovviamente il tasso medio sarà inferiore a 4 , ed è strettamente dipendente dal codice, visto che le unità integer sono specializzate e non AGLU. il risvolto positivo della medaglia è la riduzione della complessità, che si traduce a parità di condizioni fisiche, in consumi più bassi.

Non possiamo prendere soltanto il numero di porte a disposizione: bisogna vedere cosa consentono di fare.

Un thread hardware di Bullzoder ha a disposizione 2 ALU, 2 AGU (collegate a un'unità di Load/Store), 2 FPU (in realtà solo SIMD) MMX, e 2 FPU SSE/AVX a 128-bit.

SandyBridge, invece, al singolo thread hardware offre: 3 ALU, 2 AGU (collegate a 2 unità di Load/Store), 3 FPU a 256-bit (di cui solo 2 in grado di eseguire calcoli in virgola mobile a 256-bit). Fra ALU e FPU c'è sovrapposizione, per cui non si possono usare contemporaneamente 3 ALU e 3 FPU, ma è raro che si possa verificare una congestione nel loro uso.

Questa generalizzazione non te la concedo. Gestire due thread implica un costo aggiuntivo per le risorse di primissimo livello, TLB e rename register. C'è un motivo se Intel aveva abbondonato nel mobile Hyperthreading e al momento, nessun SoC ARM adotta il SMT, nonostante il minor peso sui decoder (il primo sarà k12).

IMO bisogna vedere quante porte/unità d'esecuzione sono a disposizione in una particolare micro-architettura.

SMT nasce per cercare di sfruttare meglio le molte porte, che con un solo thread hardware a disposizione rimarrebbero per lo più inutilizzate.

Ciò ha un costo, ma dubito che CMT possa fare di meglio, visto che duplica più risorse (mi riferisco alle due macro-ALU).

Viene da se che avere 2 ALU+ 2 AGU, permetta di offrire un throughput massimo maggiore, e probabilmente con una complessità inferiore a quella che si avrebbe con 3 AGLU.

Intel non usa AGLU: ha ALU e AGU indipendenti.

A priori non ti so dire se sia una scelta vincente (tu se il GURU ), ma mi pare che mediamente un 40% di istruzioni siano load/store (non a caso le AGU di Intel hanno porte di esecuzione non condivise). Ci sono buone possibilità, da ignorante, che il tasso medio sia superiore a quello di una soluzione di un ipotetico soluzione bulldozer con 3 AGLU, stile k10.

un primo di indizio di ciò è che excavator nel ST, offra in cinebench il 90-95% delle prestazioni di Nehalem, superando k10 che ha 3 AGLU.

Premetto che non sono un guru, perché le micro-architetture non sono il mio campo: ho un po' di conoscenze che mi consentono di fare qualche speculazione. Ma la mia specialità è lo studio delle architetture (quindi senza scendere a livello della loro implementazione).

Ho scritto una serie di articoli tempi fa, analizzando un po' di statistiche sulle istruzioni più frequenti per x86 e x64. Nello specifico, il settimo articolo discute della tipologia di argomenti utilizzati, che potrebbe servire allo scopo.

Come puoi vedere, c'è una certa differenza fra x86 e x64, con quest'ultimo che predilige l'uso dei registri, ovviamente perché ha a disposizione il doppio rispetto a x86 (che, dunque, deve utilizzare molto più spesso la memoria per sopperire alla sue carenze).

Focalizzandoci su x64, perché ormai il codice eseguito è per lo più a 64-bit, e limitandoci alle istruzioni "intere", il quadro che ne viene fuori è che le istruzioni che referenziano la memoria sono all'incirca il 47%, mentre le altre il 53%.

Quest'analisi, però, è viziata dal fatto che alcune istruzioni che non referenziano direttamente la memoria (CALL, RET, PUSH, POP, tanto per fare i nomi di quelle più comuni), in realtà lo fanno (e dunque fanno uso di load e/o store).

Altra cosa, molto più importante, è che quella riportata è una visione strettamente statica: non sappiamo se a run-time quante volte quelle tipologie di istruzioni vengano eseguite.

In ultimo, non conosciamo nemmeno i dettagli della microarchitettura. Perché, ad esempio, non mi aspetto che istruzioni che referenziano la memoria usando modalità d'indirizzamento semplici possano richiedere necessariamente l'uso di un'AGU. Tanto per fare un esempio, non credo che la CALL passi per un'AGU.

Dunque è estremamente difficile capire se le porte d'esecuzione risultino effettivamente bilanciate rispetto al carico reale.

Scusami per essermi dilungato, ma credo che valesse la pena riportare queste informazioni.

Ci sarebbe anche da chiedersi perchè in skylake usa nel front-end, il temporal multihtreading, introdotto in ambito x86 da AMD con bulldozer..

Non ho trovato molte informazioni su Skylake. Sembra che sia in grado di decodificare ben 6 istruzioni per ciclo di clock, ma in single thread sono eccessive. Per cui immagino che possa essere stato implementato come 3 decoder per thread hardware.

A parte le battute, il CMT non è un concetto separato dal SMT come si vuole usualmente dipingere. E' un'implementazione MOLTO parziale sulle unità integer (e quindi sono al 90% dei core indipendenti) e quasi totale sulla FPu.

Ma infatti, e per quanto abbiamo discusso finora, lo assimilo all'SMT. Ed è proprio questo il motivo per cui li considero due thread hardware anziché core.

E' stato ampiamente dimostrato che la fase di fetch non rappresenta un problema insommontabile, anche nel caso di 8 thread... Se la cache in questione ha solo un'associatività a 3 vie in steamroller, direi che non è un collo di bottiglia, tantè che con Excavator c'è stato un miglioramento delle prestazioni del 9% nel MT in cinebench, senza che questa abbia subito una modifica apparente.

Certamente, ma non ho avuto nulla da dire sulle prestazioni per sé, in questa discussione. Per me la questione rimane: o 2 core o 2 thread hardware.

La FPu di bulldozer meriterebbe un capitolo a parte, comunque ti ho già detto che sono necessari un intero modulo, per sfruttarla bene. Un raddoppio di questa risorse significherebbe avere un totale di 4 FMAC (! , a cosa serviranno? ).

Beh, serve a macinare più dati. AVX consente di eseguire 8 FMAC a singola precisione per singola istruzione di tipo FMAC, e 4 a doppia precisione. E a partire da Sandybridge se ne possono eseguire 2 per ciclo di clock.

Il trucco usato da AMD, per mantenere snella la FPu è quello di impiegare registri da 128 bit anzichè i 256 visti in SB. (così si spiega imho il costo del CMT stimato del 5% a livello di die e il 12% a livello di modulo...)

E' sostanzialmente la stessa implementazione del P-III, che ha introdotto le SSE: "spezzare" in due operazioni da 64-bit quella a 128-bit.

Un modo ignorante di vedere le cose, che i due thread hanno a disposizione ben 12 unità di esecuzione rispetto alle sole 6 di SB. La pianificazione delle code può effettivamente fare la differenza (ricordo che la FPu ha uno scheduler dedicato), e credo sia questo il motivo per cui la FPu non ha rappresentato un collo di bottiglia per le soluzioni Bulldozer.

Come detto sopra, bisogna vedere cosa facciano queste unità d'esecuzione.

In ZEN sembrerebbe completamente rivista la FPu (4 pipeline con solo un flusso FMAC, ottenuto occupando due pipeline)

Mi sembra simile alle soluzioni Intel.

Stai mescolando un pò di cose. Stai criticando le risorse e quindi le prestazioni del singolo core.
a questo punto perchè non critichi che ARM pubblicizza le soluzioni quad-core A72, tali quando un apple a9, che di core ne ha 2 va uguale? Per non parlare delle soluzioni A53..

Appunto. Se leggessi i miei commenti sugli ARM, troveresti che pongo al top proprio le soluzioni di Apple.

Io prediligo da sempre le prestazioni su singolo core/thread, perché la maggior parte del software, anche comunemente usato, non è multi-thread, o lo è scarsamente.

E' stata comunque una piacevole discussione.

Idem. Soprattutto civile, che è roba rara di questi tempi.

Lode a te

Grazie, ma rappresenta soltanto un mero esercizio finché rimane tutto sulla carta. Anche se particolarmente lungo e complicato, visto che ha richiesto 5 anni di lavoro, e se sono venute fuori 3 ISA (la descrizione su Linked-In è ferma alla seconda).

Originariamente inviato da MaxFabio93

Contenti loro che credono di saperne di più

Sei sicuro di saperne più di loro?

Sinceramente non so più cosa dirti, io ti ho postato tutto il trovabile, di singoli episodi, in più anni, se tu ce ne vedi solo uno pazienza, non devo perdere tempo a fare ricerche per te. Si vede che abbiamo una visione differente della cosa

Per forza di cose, perché i link e i documenti io almeno li leggo, e capisco quello che c'è scritto.

Tu, come già detto, ti limiti a fare qualche ricerchina su google, e riportare i link che dal titolo ti sembra combacino con la tesi che vuoi presentare. Salvo poi che il contenuto la smentisce. Vedi sotto.

Trovo ingiusta la condizione con cui viene trattata sistematicamente ogni volta AMD, qualcuno a prendere le sue "difese" ci vuole, ogni notizia e ogni discussione su AMD è un continuo spalare il fango (non tu), parlando di idiozie e dicerie di ogni tipo.

Limitarsi all'argomento di discussione, e ai fatti, magari aiuterebbe.

I dubbi sono dubbi, non hanno bisogno di un fatto recente o attuale

E dunque permangono anche i miei dubbi sugli italiani: la storia d'Italia insegna. Da qui alla fine dell'universo.

Nel 2008, Violazione dell'antitrust in USA, come sopra, 2009 abuso di posizione dominante sempre in USA, ci sarebbe anche la causa con Dell nel 2010 ma quella riguarda anni precedenti.

Come detto sopra, perché non li leggi i link che posti? Ti ho fatto delle precise richieste, e tu continui a riportarmi date che NON sono compatibili con quanto detto.

Pretese? A chi e cosa starei pretendendo? A te? Ho mai detto che Intel attualmente è una criminale? Che va chiusa? Ma di che parli?

Se leggi bene ho scritto chiaramente che ho riconosciuto anche gli accordi che ha fatto successivamente con AMD e altri per non ricadere nel ridicolo e nell'illegalità.

Hai scritto questo:

"ancora non hai ammesso che è stato commesso un fatto grave, continui a difendere sminuendolo come se non fosse succeso niente"

Quindi, sì: la tua era e rimane una pretesa nei miei confronti.

Pretesa che, come già detto, rimane assurda e illogica.

Originariamente inviato da tuttodigitale

Ho fatto una rapida ricerca, scrivendo PA - sysmark e ho trovato diversi documenti.
Ne posto uno datato novembre 2013.
https://www.google.it/url?sa=t&rct=j...,d.d24&cad=rja
addirittura ho trovato riferimenti di sysmark nella gazzetta ufficiale. (<- è il benchmark di riferimento della PA)

Le preoccupazioni di AMD a questo punto sono chiare.

Quel documento riporta soltanto un dato allegato all'elenco delle caratteristiche del computer. Non dimostra né che sia stato usato SYSMark per la selezione del PC, né che sia un requisito del bando, né tanto meno che ciò avvenga o sia un requisito per tutta la PA.

Originariamente inviato da tuttodigitale

Leggete:
http://www.vanshardware.com/reviews/...hlonXP2600.htm

Riguarda il 2002, quando AMD entrò nel consorzio. AMD ne è uscita nel 2012, dopo ben DIECI anni. E casualmente s'è lamentata di SYSMark soltanto quando se n'è andata. Cos'avrà fatto in 10 anni, non è dato saperlo.

Anzi, sì. Riporto nuovamente quanto è stato detto da un insider di AMD:

"When I read Nigel’s blog and saw the press release from BAPCo it made me sick because our CMO talks about transparency and honesty and it’s all smoke and mirrors. At the end of the day, we actively had internal teams and external organizations hired to promote/discredit SYSmark. Not because it was inaccurate, but because it is accurate. Back in the original Athlon 64 and Opteron days, when we were winning in SYSmark we were heavily promoting it in the public sector, who in turn used it as a benchmark on which they based many of their purchases on. It was us who actually got BAPCo and SYSmark inside several government tenders to win orders measured in tens of thousands of systems. SYSmark was used to show how our K8 processors were beating Intel’s NetBurst."

[tuttodigitale]

Originariamente inviato da cdimauro

Non possiamo prendere soltanto il numero di porte a disposizione: bisogna vedere cosa consentono di fare.

e non mi pare che io abbia preso solo le numero di porte. Ne converrai con me, che avere ben 11-12 unità disponibili invece di 6, per 2 thread, mette in condizione di raggirare i limiti di avere risorse condivise

Originariamente inviato da cdimauro

Un thread hardware di Bullzoder ha a disposizione 2 ALU, 2 AGU (collegate a un'unità di Load/Store), 2 FPU (in realtà solo SIMD) MMX, e 2 FPU SSE/AVX a 128-bit.

SandyBridge, invece, al singolo thread hardware offre: 3 ALU, 2 AGU (collegate a 2 unità di Load/Store), 3 FPU a 256-bit (di cui solo 2 in grado di eseguire calcoli in virgola mobile a 256-bit). Fra ALU e FPU c'è sovrapposizione, per cui non si possono usare contemporaneamente 3 ALU e 3 FPU, ma è raro che si possa verificare una congestione nel loro uso.

La prima tua grave omissione, se mi permetti, che accomuni le 2 FPU MUL e ADD, come due unità FMAC, anche se controbilanciata dalla maggiore ampiezza.

Originariamente inviato da cdimauro

Intel non usa AGLU: ha ALU e AGU indipendenti.

mai detto il contrario, era riferito alla precedente architettura k10. Infatti nel quote successivo parlavo delle AGU di SB:

Originariamente inviato da cdimauro

Non ho trovato molte informazioni su Skylake. Sembra che sia in grado di decodificare ben 6 istruzioni per ciclo di clock, ma in single thread sono eccessive. Per cui immagino che possa essere stato implementato come 3 decoder per thread hardware.

No, esattamente come bulldozer i decoder alimentano i thread in maniera alternativa. Comunque si, è in grado di decodificare fino a 6 istruzioni per cicli di clock.

Originariamente inviato da cdimauro

Ma infatti, e per quanto abbiamo discusso finora, lo assimilo all'SMT. Ed è proprio questo il motivo per cui li considero due thread hardware anziché core.

Vedi io dico che è un'implementazioni molto parziale, perchè saranno solo i primi 3-4 stadi della pipeline dove effettivamente i 2 thread si condivideranno le risorse, ma da quel punto in avanti viaggeranno in parallelo con risorse dedicate. Non è un core al 100%, ma un buon 80-90% si.
Certamente molto molto diverso dal SMT classico dove oltre la fase di fetch e quella di decodifica (nel caso delle prime due implementazioni di bulldozer), viene condivisa lo scheduler, la fase di rename il dispatch, le unità di esecuzione. Viene da se che i due thread per lo più viaggiano su binari separati.

Originariamente inviato da cdimauro

Quel documento riporta soltanto un dato allegato all'elenco delle caratteristiche del computer. Non dimostra né che sia stato usato SYSMark per la selezione del PC, né che sia un requisito del bando, né tanto meno che ciò avvenga o sia un requisito per tutta la PA.

Il passaggio in grassetto è fondamentale e cade a fagiolo sulla questione che cosa deve valutare sysmark. Se come sembra, è un dato che sintetizza le prestazioni di un computer, dovrebbe essere un test a 360 gradi su tutti i componenti della macchina, visto che si presume, che non saranno macchine oggette ad upgrade.

Comunque ho detto che ci sono riferimenti di sysmark nella gazzetta ufficiale , bastava fare la ricerca su google

Originariamente inviato da gazzetta ufficiale

Il CNIPA raccomanda alle amministrazioni pubbliche che intendono
acquisire personal computer di tipo desktop di utilizzare il
benchmark Sysmark 2004 negli appalti per la fornitura di detta
tipologia di apparecchiature.
Per quanto riguarda la determinazione dei valori del benchmark
Sysmark 2004 Overall Rating da porre come soglia per la
partecipazione alle gare, il CNIPA ritiene necessario che questa
avvenga sulla base dei valori misurati su configurazioni di personal
computer presenti sul mercato e rispondenti alle esigenze della
stazione appaltante.

http://www.gazzettaufficiale.it/atto...nza=originario

qui il bando per le ferrovie dello stato, sono i primi risultati che ho trovato (primi 3 nella prima pagina di google)...

https://www.google.it/url?sa=t&rct=j...wC8YHw&cad=rja (potevi anche forzarti di usare un motore di ricerca )

per i più pigri, date un colpo d'occhio in quanti bandi pubblici c'è questo famigerato benchmark
"bando" "sysmark"

[Alekx]

Originariamente inviato da cdimauro

Riguarda il 2002, quando AMD entrò nel consorzio. AMD ne è uscita nel 2012, dopo ben DIECI anni. E casualmente s'è lamentata di SYSMark soltanto quando se n'è andata. Cos'avrà fatto in 10 anni, non è dato saperlo.

Anzi, sì. Riporto nuovamente quanto è stato detto da un insider di AMD:

[i]"When I read Nigel’s blog and saw the press release from BAPCo it made me sick because our CMO talks about transparency and honesty and it’s all smoke and mirrors. At the end of the day, we actively had internal teams and external organizations hired to promote/discredit SYSmark. Not because it was inaccurate, but because it is accurate. Back in the original Athlon 64 and Opteron days, when we were winning in SYSmark we were heavily promoting it in the public sector, who in turn used it as a benchmark on which they based many of their purchases on. It was us who actually got BAPCo and SYSmark inside several government tenders to win orders measured in tens of thousands of systems. SYSmark was used to show how our K8 processors were beating Intel’s NetBurst."

E invece non e' proprio cosi' secondo me, il fare parte di un consorzio era praticamente obbligatorio per AMD altrimenti doveva dare giustificazioni in caso contrario e probabilmente sarebbe stata peggio per lei.

Il fatto che ne sia uscita dopo 10 anni non significa che per 10' anni ha taciuto, questo non lo so ne io ne tu.

il fatto della scelta del procio e' stato per anni e lo e' ancora in mano a gente che non capisce un cactus perche' non valuta attentamente a cosa serve realmente il PC (lo dico per cognizione di causa visto che l'ho vissuto in prima persona) sperperando qualche decina di migliaia di soldi pubblici tanto paga pantalone.

Potrei portarti milioni di esempi con notebook/desktop venduti con processori intel che potevi utilizzarli solo per office automation se dovevi utilizzarli per qualcosa in piu', grafica o altro che andasse a coinvolgere la GPU era meglio lasciar perdere o meglio dovevi acquistare in caso di notebook l'intel affrontando costi del triplo.

Con l'avvento delle APU, gia' dai primi modelli non hai limiti in nulla, le ultime vanno benissimo per una utenza del 70%.

Te lo dimostra il fatto che io anche se esigente in termini di risorse visto che il PC di casa lo utilizzo per giocare principalmente non sento la necessita' di dover cambiare piattaforma perche' se gioco a 90 FPS invece che a 110 FPS con una CPU INTEL di riferimento dell'epoca o piu' moderna sinceramente me ne frego i soldi stanno bene in tasca a me

Poi che tante configurazioni AMD non si trovano dove quel 70% di gente va ad acquistare il pc e' un'altra storia.

[tuttodigitale]

Originariamente inviato da GTKM

Invece gli FX...

considera che allo stesso prezzo di un i3 6320 puoi comprare un FX8350 (un fx 8320E costa 40 euri meno....). Saranno vecchiotti (ed effettivamente hanno quasi 4 anni), ma il prezzo è altamente concorrenziale.
E se uno non si fa tante pippe sul TDP, che non necessariamente si traduce in un maggior rumorosità e temperature, visto che tra IHS e die non c'è la pasta del capitano.

Secondo Tomshw, che usa una sonda termica, la temperatura del package di un FX8370E non supera i 40°C contro i 64 °C dell'i7 6700K e i 48°C di un i5 6600K, con il relativo dissipatore stock. Potenzialmente un sistema con CPU AMD può persino essere più silenzioso, a parità di dissipatore.

Cosa ancora più impressionante nello stress test (solo CPU) abbiamo questi valori:
i5 6600k 73W
i7 6700k 100W
FX8370E 78W

vi rimando ai link delle review.

http://www.tomshw.it/articoli/recens...ienza-61222-p2
https://www.tomshw.it/articoli/recen...rova-69053-p12

Secondo me, attualmente esistono discrepanze enormi tra cpu con la stessa sigla su finfet. D'altra parte i 32nm SOI, sono maturati a tal punto, che è giusto attendersi rendimenti piuttosto costanti e certamente migliori di quelli che abbiamo visto anni fa.

[AceGranger]

Originariamente inviato da Bivvoz

La maggior parte della persone compra Intel perchè il commesso del mediaworld gli dice che è meglio, il commesso non sa se è vero ma ci sono più notebook con Intel esposti e quindi probabilmente è così.

il commesso del Mediawrold non guarda nulla e non vende quello che crede sia meglio...

il commesso vende quello che gli viene detto di vendere di volta in volta perchè Mediaworld, ( come tutte le piattaforme grossiste ) deve vendere un determinato numero di pezzi di una determinata marca per ricevere i bonus annuali dei produttori...

quindi tentano di venderti quello che a loro fa piu comodo.

[cdimauro]

Originariamente inviato da tuttodigitale

e non mi pare che io abbia preso solo le numero di porte. Ne converrai con me, che avere ben 11-12 unità disponibili invece di 6, per 2 thread, mette in condizione di raggirare i limiti di avere risorse condivise

Il problema è puoi avere anche 12 porte, ma se solo 2 sono ALU, hai posto un grosso limite all'esecuzione di codice "intero". Idem per il codice "FP", che è limitato dalle sole due porte per l'FPU.

Qui, al solito, mi riferisco al ST, e non al MT.

La prima tua grave omissione, se mi permetti, che accomuni le 2 FPU MUL e ADD, come due unità FMAC, anche se controbilanciata dalla maggiore ampiezza.

Non mi è chiaro: 2 porte FPU possono eseguire MUL, ADD, o FMAC. A cosa ti riferisci di preciso qui?

No, esattamente come bulldozer i decoder alimentano i thread in maniera alternativa. Comunque si, è in grado di decodificare fino a 6 istruzioni per cicli di clock.

OK. Ma in questo modo mi pare sia simile a SandyBridge e Nehalem.

Però una cosa importante che non abbiamo tenuto in considerazione è il fatto che con SB è stata introdotto il famigerato Loop Stream Detector (LSD), che consente di bypassare i decoder (secondo Intel nell'80% dei casi), accorciando pure la pipeline, con ovvi benefici in termini di condivisione dei decoder, consumi, e prestazioni.

Il passaggio in grassetto è fondamentale e cade a fagiolo sulla questione che cosa deve valutare sysmark. Se come sembra, è un dato che sintetizza le prestazioni di un computer, dovrebbe essere un test a 360 gradi su tutti i componenti della macchina, visto che si presume, che non saranno macchine oggette ad upgrade.

Il secondo documento (in formato Word) chiarisce meglio la questione. Ma ne parlo meglio dopo.

Comunque ho detto che ci sono riferimenti di sysmark nella gazzetta ufficiale , bastava fare la ricerca su google

http://www.gazzettaufficiale.it/atto...nza=originario

qui il bando per le ferrovie dello stato, sono i primi risultati che ho trovato (primi 3 nella prima pagina di google)...

https://www.google.it/url?sa=t&rct=j...wC8YHw&cad=rja (potevi anche forzarti di usare un motore di ricerca )

Lazyness.

Il primo link fornisce una raccomandazione, ma non impone l'uso di quel benchmark. Un ente pubblico, dunque, può benissimo procedere diversamente.

Il secondo documento è molto interessante perché mette in chiaro due cose, anche se relativamente a quello specifico bando.

La prima è che non si richiede un benchmark generico, che testi a 360° la macchina. Poiché il PC sarà usato per compiti da ufficio, è richiesto l'uso di "Mobilemark 2007 Office Productivity".

Secondo, e ancora più importante, c'è il fatto che il requisito prestazionale non riguarda il valore più grande, ma è sufficiente che venga superata una certa soglia (per quello specifico test orientato all'uso da ufficio). Questo lascia margini di manovra a chi dovrà scegliere il PC.

Terzo, all'epoca non mi pare ci fossero le APU.

Originariamente inviato da Alekx

E invece non e' proprio cosi' secondo me, il fare parte di un consorzio era praticamente obbligatorio per AMD altrimenti doveva dare giustificazioni in caso contrario e probabilmente sarebbe stata peggio per lei.

Il fatto che ne sia uscita dopo 10 anni non significa che per 10' anni ha taciuto, questo non lo so ne io ne tu.

Allora riparliamone quando saranno trovate delle lamentele da parte sua.

Al momento rimane il dato che è rimasti lì dentro per 10 anni, contribuendo a definire tutte le suite fino a quella pubblicata poco dopo che è uscita.

il fatto della scelta del procio e' stato per anni e lo e' ancora in mano a gente che non capisce un cactus perche' non valuta attentamente a cosa serve realmente il PC (lo dico per cognizione di causa visto che l'ho vissuto in prima persona) sperperando qualche decina di migliaia di soldi pubblici tanto paga pantalone.

Potrei portarti milioni di esempi con notebook/desktop venduti con processori intel che potevi utilizzarli solo per office automation se dovevi utilizzarli per qualcosa in piu', grafica o altro che andasse a coinvolgere la GPU era meglio lasciar perdere o meglio dovevi acquistare in caso di notebook l'intel affrontando costi del triplo.

Con l'avvento delle APU, gia' dai primi modelli non hai limiti in nulla, le ultime vanno benissimo per una utenza del 70%.

Te lo dimostra il fatto che io anche se esigente in termini di risorse visto che il PC di casa lo utilizzo per giocare principalmente non sento la necessita' di dover cambiare piattaforma perche' se gioco a 90 FPS invece che a 110 FPS con una CPU INTEL di riferimento dell'epoca o piu' moderna sinceramente me ne frego i soldi stanno bene in tasca a me

Poi che tante configurazioni AMD non si trovano dove quel 70% di gente va ad acquistare il pc e' un'altra storia.

Ma il punto è che la gente deve comprarla qualcosa, per cui deve avere un metro di valutazione.

Roba che sia più abbordabile di un sito/forum frequentato da nerd.

[cdimauro]

OK, penso d'aver capito cosa intendevi riguardo a questo:

"La prima tua grave omissione, se mi permetti, che accomuni le 2 FPU MUL e ADD, come due unità FMAC, anche se controbilanciata dalla maggiore ampiezza."

SB non ha FMAC. Dunque FMUL e FADD.

E' Haswell che ha introdotto le unità FMAC.

EDIT. Avevo dimenticato una questione importantissima nella valutazione della tipologia di istruzioni eseguite. La LEA può far uso di modalità di esecuzione complesse per il calcolo dell'indirizzo, ma non referenzia la memoria, e può benissimo essere eseguita da un'ALU e non da un'AGU.

Infatti i processori di Intel hanno un'ALU specializzata che esegue istruzioni LEA. Dunque non passano dall'AGU.

Inoltre si tratta di un'istruzione molto comune in x86 e in x64. In quest'ultimo caso copre quasi l'11% del totale di istruzioni (vedi ottava parte della mia serie).

Fermo restando tutto quello che ho scritto in precedenza, credo sia degno di nota, perché riduce nettamente il numero di load/store dal computo di prima, tutto a favore dell'ALU.

[tuttodigitale]

O cavolo rischiamo di finirla più questa discussione

Originariamente inviato da cdimauro

Il problema è puoi avere anche 12 porte, ma se solo 2 sono ALU, hai posto un grosso limite all'esecuzione di codice "intero". Idem per il codice "FP", che è limitato dalle sole due porte per l'FPU.

Ti ho già detto che i test, non valorizzano la tua ipotesi. Cosa c'è di meglio di una prova su strada?

Sulla quantià di ALU, bisogna fare dei distinguo. Rispetto a k10 che ha 3 AGLU, effettivamente excavator è in grado di offrire un ipc superiore. Rispetto a SB che è una soluzione 3ALU+2AGU NO. Ma qui c'è da considerare il fatto che SB ha una pipeline lunga solo 14 studi nel 80% del tempo di esecuzione.
Non diamo troppo credito che sia la mancanza della terza ALU, la ragione del basso ipc di BD.

Originariamente inviato da cdimauro

Però una cosa importante che non abbiamo tenuto in considerazione è il fatto che con SB è stata introdotto il famigerato Loop Stream Detector (LSD), che consente di bypassare i decoder (secondo Intel nell'80% dei casi), accorciando pure la pipeline, con ovvi benefici in termini di condivisione dei decoder, consumi, e prestazioni.

stavano parlando solo di unità di esecuzione. E già il brodo è lungo

Originariamente inviato da cdimauro

La prima è che non si richiede un benchmark generico, che testi a 360° la macchina. Poiché il PC sarà usato per compiti da ufficio, è richiesto l'uso di "Mobilemark 2007 Office Productivity".

Secondo, e ancora più importante, c'è il fatto che il requisito prestazionale non riguarda il valore più grande, ma è sufficiente che venga superata una certa soglia (per quello specifico test orientato all'uso da ufficio). Questo lascia margini di manovra a chi dovrà scegliere il PC.

Nel momento in cui esegui i programmi che sono nell'elenco, il benchmark in questione dovrebeb usare, secondo me, tutte le feature, magari dando più peso alle più recenti (che poi sono queste a determinare l'acquisto di nuovo software e HW, di solito). Se queste usano la GPU, non si può non usarla, perchè questo benchmark viene usato per valutare le prestazioni su quei determinati applicativi, di un sistema e non di un singolo componente.

Viene da se che se viene scelto un valore minimo di un Pentium skylake, vengono scartati tutte le CPU/APU AMD. Non sottostimiamo l'importanza di quel numerino

Originariamente inviato da cdimauro

Terzo, all'epoca non mi pare ci fossero le APU.

ci sono n-mila gare pubbliche ancora attive (basta cercare)

Originariamente inviato da cdimauro

Ma il punto è che la gente deve comprarla qualcosa, per cui deve avere un metro di valutazione.

il più possibile che non sia imparziale e oggettivamente valido, per il momento ho forti dubbi che lo sia.

[tuttodigitale]

Originariamente inviato da cdimauro

EDIT. Avevo dimenticato una questione importantissima nella valutazione della tipologia di istruzioni eseguite. La LEA può far uso di modalità di esecuzione complesse per il calcolo dell'indirizzo, ma non referenzia la memoria, e può benissimo essere eseguita da un'ALU e non da un'AGU.

Infatti i processori di Intel hanno un'ALU specializzata che esegue istruzioni LEA. Dunque non passano dall'AGU.

Inoltre si tratta di un'istruzione molto comune in x86 e in x64. In quest'ultimo caso copre quasi l'11% del totale di istruzioni (vedi ottava parte della mia serie).

Ti stai dando la zappa sui piedi. Nel momento in cui viene eseguita un istruzione LEA, non è possibile eseguire le "classiche" operazioni aritmetiche logiche in quella determinata porta di esecuzione.

Poi l'ALU, non è tanto specializzata, visto che le stesse unità che eseguono una LEA sono in grado di eseguire una MUL o uno shifter. probabilmente ti confondi con Haswell/skylake.

VEdi alla fine del tour, il numero delle ALU, non sembra essere il problema di BD, e non possono neppure essere le AGU (2 per un thread credo che siano più che sufficienti).

[Alekx]

Originariamente inviato da GTKM

Invece gli FX...

Infatti, all'epoca del prescott l'Atlhon era molto meglio ma come gia' detto sopra la politica di INTEL l'ha favorita.

Poi che AMD a distanza di anni abbia fatto gli FX che consumano ok come gia'0 detto e condannato da me AMD ha fatto gli stessi sbagli ma avendo meno "popolarita'" in diversi ambiti ci ha rimesso l'osso del collo.

[Alekx]

Originariamente inviato da tuttodigitale

considera che allo stesso prezzo di un i3 6320 puoi comprare un FX8350 (un fx 8320E costa 40 euri meno....). Saranno vecchiotti (ed effettivamente hanno quasi 4 anni), ma il prezzo è altamente concorrenziale.
E se uno non si fa tante pippe sul TDP, che non necessariamente si traduce in un maggior rumorosità e temperature, visto che tra IHS e die non c'è la pasta del capitano.

Secondo Tomshw, che usa una sonda termica, la temperatura del package di un FX8370E non supera i 40°C contro i 64 °C dell'i7 6700K e i 48°C di un i5 6600K, con il relativo dissipatore stock. Potenzialmente un sistema con CPU AMD può persino essere più silenzioso, a parità di dissipatore.

Cosa ancora più impressionante nello stress test (solo CPU) abbiamo questi valori:
i5 6600k 73W
i7 6700k 100W
FX8370E 78W

vi rimando ai link delle review.

http://www.tomshw.it/articoli/recens...ienza-61222-p2
https://www.tomshw.it/articoli/recen...rova-69053-p12

Secondo me, attualmente esistono discrepanze enormi tra cpu con la stessa sigla su finfet. D'altra parte i 32nm SOI, sono maturati a tal punto, che è giusto attendersi rendimenti piuttosto costanti e certamente migliori di quelli che abbiamo visto anni fa.

Quoto ed aggiungo dicendo, quanti utenti scandalizzati da sti caxxo di TDP hanno usufruito del risparmio in bolletta per poter andare in vacanza ?

Poi magari guardi al PC e a casa non hai messo tutte le lampadine a LED !!

Ora che si possa ottimizzare ok sono d'accordo me se uno consuma 10 e l'altro 17 sticaxxi cioe' ti voglio dire se basi la scelta su questo per me tutto il resto e' aria fritta.

[Alekx]

Originariamente inviato da cdimauro

Allora riparliamone quando saranno trovate delle lamentele da parte sua.

Al momento rimane il dato che è rimasti lì dentro per 10 anni, contribuendo a definire tutte le suite fino a quella pubblicata poco dopo che è uscita.

Ma il punto è che la gente deve comprarla qualcosa, per cui deve avere un metro di valutazione.

Roba che sia più abbordabile di un sito/forum frequentato da nerd.

PArli come se sapessi, al contrario di me che invece non sapendo posso immaginare.

Condanni AMD di essere rimasta li nel consoorzio e ad aver avallato di tutto e di piu', ma NON vuoi prendere in considerazione il fatto che INTEL possa aver pilotato tutto, non mi pare obiettivo.


In un TEAM di persone ci deve essere sempre il piu' debole per far fare bella figura a chi invece e' "normale" mentre chi e' piu' scaltro viene di solito accantonato o fatto fuori.

E' la (in)logica AMERICANA, vedi apple, microsoft etc.

[cdimauro]

Originariamente inviato da tuttodigitale

O cavolo rischiamo di finirla più questa discussione

Lasciamo perdere i discorsi sulle architetture. Ma debbo fare una precisazione sull'ultimo commento.

Nel momento in cui esegui i programmi che sono nell'elenco, il benchmark in questione dovrebeb usare, secondo me, tutte le feature, magari dando più peso alle più recenti (che poi sono queste a determinare l'acquisto di nuovo software e HW, di solito). Se queste usano la GPU, non si può non usarla, perchè questo benchmark viene usato per valutare le prestazioni su quei determinati applicativi, di un sistema e non di un singolo componente.

Ma le ultime incarnazioni usano la GPU.

Viene da se che se viene scelto un valore minimo di un Pentium skylake, vengono scartati tutte le CPU/APU AMD. Non sottostimiamo l'importanza di quel numerino

Assolutamente, è uno scenario possibile, ma la lista della spesa di un ente pubblico non la compila certo un dipendente Intel, quanto un funzionario/impiegato. Potrebbe anche essere uno che si aggiorna e segua l'evoluzione dell'IT, ma dubito fortemente che possa essere un caso generalizzato.

ci sono n-mila gare pubbliche ancora attive (basta cercare)

Mai negato questo. Ma non penso che alla maggior parte interessi un PC che vada bene su Photoshop o Premier, dove la GPU sarebbe utilizzata.

In ambito puramente "office", bastano i benchmark focalizzati su questa tipologia di applicazioni.

il più possibile che non sia imparziale e oggettivamente valido, per il momento ho forti dubbi che lo sia.

Il problema è che le esigenze variano molto. Vedi anche il discorso della PA di cui sopra.

Poi chi dovrebbe creare questo benchmark universale?

Originariamente inviato da tuttodigitale

Ti stai dando la zappa sui piedi. Nel momento in cui viene eseguita un istruzione LEA, non è possibile eseguire le "classiche" operazioni aritmetiche logiche in quella determinata porta di esecuzione.

Poi l'ALU, non è tanto specializzata, visto che le stesse unità che eseguono una LEA sono in grado di eseguire una MUL o uno shifter. probabilmente ti confondi con Haswell/skylake.

VEdi alla fine del tour, il numero delle ALU, non sembra essere il problema di BD, e non possono neppure essere le AGU (2 per un thread credo che siano più che sufficienti).

Un appunto, come dicevo prima. Un'AGU serve a calcolare l'indirizzo della locazione di memoria che sarà successivamente utilizzata da un'istruzione.

Questo non significa che sia un'unità in grado di elaborare un'istruzione come la LEA.

Non ho trovato informazioni sul fatto che le AGU di Bulldozer & successori siano in grado di processare una LEA. Questo significa che o la LEA è a carico di un'ALU (o magari di tutte e due), oppure che è suddivisa in due micro-op: una che va all'AGU, e l'altra, concatenata alla prima, che sfrutta il suo valore per memorizzare il risultato nel registro. Io propendo per la prima ipotesi, ovviamente: è la più "naturale" e più performante.

Nel caso di Intel, invece, tutto ciò è esplicito.

/OT

[cdimauro]

Originariamente inviato da Alekx

PArli come se sapessi, al contrario di me che invece non sapendo posso immaginare.

Io non so nient'altro che le informazioni riportate qui.

Hai trovato altro a riguardo? Perfino tuttodigitale ha riportato roba del 2002 e 2001, sull'argomento, che sono ovviamente il frutto di ricerche a caccia di fonti.

Condanni AMD di essere rimasta li nel consoorzio e ad aver avallato di tutto e di piu', ma NON vuoi prendere in considerazione il fatto che INTEL possa aver pilotato tutto, non mi pare obiettivo.

Come faccio a prenderlo in considerazione se in 10 anni che è stata lì dentro, AMD non ha denunciato nulla del genere. E dovrei farlo io, da esterno?

In un TEAM di persone ci deve essere sempre il piu' debole per far fare bella figura a chi invece e' "normale" mentre chi e' piu' scaltro viene di solito accantonato o fatto fuori.

E' la (in)logica AMERICANA, vedi apple, microsoft etc.

E quindi AMD ha fatto la figura dell'utile idiota, per dirla all'italiana? 10 anni che è lì dentro, e s'è accorta soltanto alla fine che era tutto pilotato?

[Alekx]

Originariamente inviato da cdimauro

Io non so nient'altro che le informazioni riportate qui.Hai trovato altro a riguardo? Perfino tuttodigitale ha riportato roba del 2002 e 2001, sull'argomento, che sono ovviamente il frutto di ricerche a caccia di fonti.

Dopo tutta la merda permettimi di avere qualche dubbio su tutte le info riportate.

Scusami ma anche oggi volendomi basare su quello scritto e non scritto all'epoca chiaramente con tutto quello che sappiamo, cambia per me un po' il modo di vedere le cose, e pure di molto.

Come faccio a prenderlo in considerazione se in 10 anni che è stata lì dentro, AMD non ha denunciato nulla del genere. E dovrei farlo io, da esterno?

Ti ho semplicemente detto di "considerare che....." e non che dovessi prenderti carico di una crociata, solo per essere piu' obiettivo.

E quindi AMD ha fatto la figura dell'utile idiota, per dirla all'italiana? 10 anni che è lì dentro, e s'è accorta soltanto alla fine che era tutto pilotato?

Il fatto e' che anche da "cenerentola" non starci forse sarebbe stato peggio non credi ?

Indipendentemente dal fatto che magari intel sarebbe stata piu' performante ma sicuramente non "dominante"

[AceGranger]

Originariamente inviato da tuttodigitale

Cosa ancora più impressionante nello stress test (solo CPU) abbiamo questi valori:
i5 6600k 73W
i7 6700k 100W
FX8370E 78W

vi rimando ai link delle review.

http://www.tomshw.it/articoli/recens...ienza-61222-p2
https://www.tomshw.it/articoli/recen...rova-69053-p12

"Creiamo il massimo carico possibile sulla CPU, includendo i suoi core x86, l'FPU, la cache e l'IGP"
viene scritto anche subito sotto il titolo del grafico, "Graphics if exists".





lo stress test del 6600K e 6700K comprende anche lo stress GPU; la sola parte CPU credo sia abbastanza sotto risepetto a quei valori.