[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[digieffe]

Originariamente inviato da shellx

Non so che cavolo ho toccato nel bios nelle voci, ma mi regge da un ora e mezzo i 4,5ghz a 1,39v (nb def, ram def) sotto stress con cpuburn e vari bench phoronix.

tiro ad indovinare load line calibration al max, oppure qualche impostazione che te lo overvolta "auto"maticamente in determinate situazioni

[shellx]

Originariamente inviato da digieffe

Non so se sia una divisione corretta... potrebbero le fonderie ex intel produrre (in maniera corretta) anche per AMD?
ed il supporto dei compilatori diventerebbe senza trucchi?

Ma secondo me si produce solo per se stessa, per avere un maggiore controllo dei chip e cpu che sforna per i vari mercati: desktop, mobile, embedded (router, tablet, smartphone). Vedi gli ultimi atom che saranno montati anche sui prossimi router. Secondo me è una divisione piu proiettata ad una politica dimaggiore precisione di gestione.
Ma dubito fortemente che diventa una fonderia APERTA a tutti. Specialmente ad AMD. Sarebbe come se il gatto fornisce il formaggio al topo.

[digieffe]

Originariamente inviato da shellx

Ma secondo me si produce solo per se stessa, per avere un maggiore controllo dei chip e cpu che sforna per i vari mercati: desktop, mobile, embedded (router, tablet, smartphone). Vedi gli ultimi atom che saranno montati anche sui prossimi router. Secondo me è una divisione piu proiettata ad una politica dimaggiore precisione di gestione.
Ma dubito fortemente che diventa una fonderia APERTA a tutti. Specialmente ad AMD. Sarebbe come se il gatto fornisce il formaggio al topo.

Se la smembrano, almeno formalmente le fonderie devono essere aperte a tutti, che poi le condizioni di produzione possano essere insostenibili per non ex intel...

stesso discorso compilatori, non è detto che dopo lo smembramento diventino imparziali.


Ps: normalmente, lo smembramento serve per eliminare la situazione di monopolio... (secondo me andrebbe ripensato la logica dello smembramento)

[shellx]

Originariamente inviato da paolo.oliva2

Non ti meravigliare, a me con il Vcore def, 1,385V da bios, tiene i 4,6GHz, ma non l'ho mai postato perchè.... mi sembrava di fare la figura del fanboy AMD.

Piuttosto... ho una sensazione... troppo fantascientifica forse..
Non è che la nuova tecnologia di gestione dei clock porti si guadagni, ma anche delle perdite? Oppure il silicio ha un comportamento molto differente.

Cioè... da 1,385V fino a 1,425, con solo +0,04V di overvolt, sto C0 permette all'8320 di overcloccare di 1GHz e all'8350 di +600MHz, e all'8350 di salire oltre i 5GHz con Vcore 1,5-1,525V.
Però... mentre l'8150 digeriva bene anche 1,6V, l'8350 a me sembra che lo puoi overvoltare sopra 1,525V SOLAMENTE con temp procio basse, forse anche sotto lo zero.
Non ho fatto molte prove perchè, purtroppo, mi serve internet e non posso fare sessioni di OC con i vari crash ed altro...

tiro ad indovinare load line calibration al max, oppure qualche impostazione che te lo overvolta "auto"maticamente in determinate situazioni

No, è auto la llc, quella la conosco e non la alzo per principio. Sto cercando di capire, sto bios a n.mila voci non ci capisco piu niente. Comunque stavo smanettando dentro la schermata relativa alle voci di tensione della cpu, ram e affini nel bios di msi sono su aree indipendenti. Ma non ricordo, le sto toccando tutte e ora non so che ho toccato, si è bloccato all'avvio ho dovuto fare il clear cmos e ricaricare il profilo oc di prima, perchèio ho poca memoria e non mi ricordo mai le cose e le voci che ho toccato prima. Vabbe comunque me ne frego, lo lascio tutta la notte a 4,5ghz e 1,39v se non mi crasha domani abbasso di qualche step il vcore e rifaccio i test, se mi tiene a 1,38x sono super contento, non mi interessano nemmeno i 4,6ghz. Comunque in tutto questo: temp sotto stress 52/54°

Se la smembrano, almeno formalmente le fonderie devono essere aperte a tutti, che poi le condizioni di produzione possano essere insostenibili per non ex intel...

stesso discorso compilatori, non è detto che dopo lo smembramento diventino imparziali.


Ps: normalmente, lo smembramento serve per eliminare la situazione di monopolio... (secondo me andrebbe ripensato la logica dello smembramento)

Non lo so Fabio, so solo che non ci sto capendo piu niente con ste aziende. Secondo me stiamo vivendo degli anni di transazione. Io so tuttavia che non si tratta mica dello smembramento (antitrust) ancora amd è viva e vegeta. Non lo mica capita sta cosa.

[carlottoIIx6]

Originariamente inviato da Wolfhang

qui l'efficienza e i consumi li hanno quantificati...
http://www.tomshw.it/cont/articolo/r.../40519/18.html

i test di efficenza di tom's mi convingono zero.

[paolo.oliva2]

Ho beccato questa analisi... non mi sembra male.

Il discorso è complesso, perchè in realtà il Sistema operativo continua a muovere dei Task in background mentre il gioco gira in primo piano. Per questo un FX-8xxx gira più forte di un 4 core FX-4xxx, anche se il gioco più di 3 o 4 core non impiega.
Ero curioso di capire come mai un AMD fosse inferiore ad un Intel, anche a frequenze di Clock molto superiori, quindi la mia natura di tecnico mi ha fatto analizzare l'architettura dei due tipi di processore.
In sostanza, spiegato a mia nonna cioè senza entrare esageratamente nel tecnico, l'architettura AMD è molto più aggressiva e poco prudente, mentre Intel è più convenzionale e "cauta".
A partire dal Pentium PRO è entrato nell'architettura X86 il concetto di Pipeline. Mentre prima i vecchi Pentium, MMX o lisci, eseguivano (detto molto semplicisticamente) una singola istruzione per ogni singolo ciclo di clock, quindi, grossomodo, ad una frequenza di 166 Mhz corrispondevano 166 operazioni x86, anzi, in realtà molto meno perchè ci sono istruzioni CPU x86 long che impiegano diversi cicli di clock per essere eseguite, cmq figuratevi una cosa del genere.
Quindi all'aumentare delle frequenze si scalavano linearmente le prestazioni del processore. Però questa tecnologia aveva forti limiti, perchè le frequenze non si possono aumentare indefinitivamente ed ogni breve lasso di tempo tempo (tecnologia della riduzione dello spessore del DIE). Quindi ecco il concetto di Pipeline.
Sempre semplificando estremamente possiamo immaginarci come una scatola verticale molto stretta e sviluppata in altezza dove vengono buttate dentro e dall'alto delle scatolette contenenti le istruzioni x86.
Ebbene le istruzioni NON vengono eseguite finchè la pipeline, la scatolona verticale, non è completamente piena, satura. Quindi diversi cicli di clock, molti, vengono impiegati per impilare le istruzioni dentro la pipeline, ed in questi cicli nessuna istruzione di output è presente in uscita, tempo morto che chiamiamo latenza di Pipeline.
Una volta piena la Pipeline ecco che inizia la parte computazionale della CPU, con l'esecuzione delle istruzioni sui dati.
Attraverso una serie di particolari tecniche di esecuzione, a Pipeline piena, le istruzioni che vengono eseguite per singolo colpo di clock diventano molte; 4, 5 e anche 6 istruzioni per ciclo di clock, aumentando ENORMEMENTE le capacità computazionali della CPU, e riprendendosi con gli interessi, il tempo di latenza trascorso in attesa che si riempisse la Pipeline.
Ora, una di queste tecniche, che si sono evolute nel tempo, per velocizzare le istruzioni per singolo ciclo, è la Branch Prediction.
Il Branch Prediction, come lascia indovinare il nome, è un Modulo previsore di una possibile sequenza di istruzioni, in maniera da preparare già in anticipo e riempire la Pipeline con la previsione dei dati, istruzioni e risultati.
Dopo un salto condizionato c'è sempre una diramazione in due direzioni del flusso operazioni e l'unità di BP cerca di indovinare quali saranno le istruzioni successive, preparando dati, operazioni su di essi e risultato finale. Ottimo, bene...
...bene finchè la previsione viene eseguita (ovvero HIT, colpita) e questo accade nel 95-98% dei casi.
Ma cosa accade quando la previsione non viene "colpita"? Un dramma! Un dramma temporale perchè quando un'istruzione non viene predetta o un dato non viene trovato, avviene un "cachè missing" ed in questo caso la Pipeline viene COMPLETAMENTE svuotata e riempita di nuovo con una sequenza di dati corretta, perchè quelli buttati dentro i cicli prima non servono a nulla, e tutto deve essere azzerato.
Questo comporta la perdita di diversi, numerosi cicli di clock in operazioni "nullafacenti" e nasce un tempo di latenza dove la CPU lavora per il nulla mischiato al niente.
Viene da se comprendere che una Pipeline molto lunga è molto più efficiente (una volta che è piena e parte) di una più corta, ma è anche molto penalizzante nel caso di un cache missing e successivo completo svuotamento.
Tornando all'architettura AMD, questa ha scelto di utilizzare Pipeling molto molto lunghe, confidando in una unità di BP molto efficiente e con una percentuale di HIT superiore all'unità disponibile dentro gli INTEL. Però... un previsore rimane un oggetto che esegue una stima, una valutazione, una previsione appunto, che non sempre è conforme a quello che accade nella realtà. Ecco che inevitabilmente, alla faccia della migliore efficienza, tutto viene vanificato da una mancata previsione.
Questo spiega perchè alcuni software che sono "prevedibili" nel loro output (pernsiamo ad un rendering o ad una modifica su un'immagine statica) hanno buoni risultati, mentre altri, come i giochi, fortemente dinamici e mutevoli, hanno una minore efficienza, proprio perchè statisticamente maggiormente soggetti a produrre cachè missing.
Ecco spiegato l'arcano della minore efficienza degli AMD in alcune situazioni.
E' vero che il software può essere, in una qualche misura, ottimizzato per evitare i cache missing, con un flusso il più regolare e lineare possibile, ma il concetto stesso di programma che ha un'interazione con servizzi esterni (tra cui anche l'operatore) per sua stessa natura non può essere contenuto in rigide regole statiche e lineari.

[shellx]

Originariamente inviato da paolo.oliva2

cut...

Non esiste spiegazione piu chiara e completa ! Caspita. Ma non ho capito l'hai letta o l'hai stesa tu ? Se l'hai letta che sito è ?

[Randa71]

Originariamente inviato da paolo.oliva2

Ho beccato questa analisi... non mi sembra male.

Il discorso è complesso, perchè in realtà il Sistema operativo continua a muovere dei Task in background mentre il gioco gira in primo piano. Per questo un FX-8xxx gira più forte di un 4 core FX-4xxx, anche se il gioco più di 3 o 4 core non impiega.
Ero curioso di capire come mai un AMD fosse inferiore ad un Intel, anche a frequenze di Clock molto superiori, quindi la mia natura di tecnico mi ha fatto analizzare l'architettura dei due tipi di processore.
In sostanza, spiegato a mia nonna cioè senza entrare esageratamente nel tecnico, l'architettura AMD è molto più aggressiva e poco prudente, mentre Intel è più convenzionale e "cauta".
A partire dal Pentium PRO è entrato nell'architettura X86 il concetto di Pipeline. Mentre prima i vecchi Pentium, MMX o lisci, eseguivano (detto molto semplicisticamente) una singola istruzione per ogni singolo ciclo di clock, quindi, grossomodo, ad una frequenza di 166 Mhz corrispondevano 166 operazioni x86, anzi, in realtà molto meno perchè ci sono istruzioni CPU x86 long che impiegano diversi cicli di clock per essere eseguite, cmq figuratevi una cosa del genere.
Quindi all'aumentare delle frequenze si scalavano linearmente le prestazioni del processore. Però questa tecnologia aveva forti limiti, perchè le frequenze non si possono aumentare indefinitivamente ed ogni breve lasso di tempo tempo (tecnologia della riduzione dello spessore del DIE). Quindi ecco il concetto di Pipeline.
Sempre semplificando estremamente possiamo immaginarci come una scatola verticale molto stretta e sviluppata in altezza dove vengono buttate dentro e dall'alto delle scatolette contenenti le istruzioni x86.
Ebbene le istruzioni NON vengono eseguite finchè la pipeline, la scatolona verticale, non è completamente piena, satura. Quindi diversi cicli di clock, molti, vengono impiegati per impilare le istruzioni dentro la pipeline, ed in questi cicli nessuna istruzione di output è presente in uscita, tempo morto che chiamiamo latenza di Pipeline.
Una volta piena la Pipeline ecco che inizia la parte computazionale della CPU, con l'esecuzione delle istruzioni sui dati.
Attraverso una serie di particolari tecniche di esecuzione, a Pipeline piena, le istruzioni che vengono eseguite per singolo colpo di clock diventano molte; 4, 5 e anche 6 istruzioni per ciclo di clock, aumentando ENORMEMENTE le capacità computazionali della CPU, e riprendendosi con gli interessi, il tempo di latenza trascorso in attesa che si riempisse la Pipeline.
Ora, una di queste tecniche, che si sono evolute nel tempo, per velocizzare le istruzioni per singolo ciclo, è la Branch Prediction.
Il Branch Prediction, come lascia indovinare il nome, è un Modulo previsore di una possibile sequenza di istruzioni, in maniera da preparare già in anticipo e riempire la Pipeline con la previsione dei dati, istruzioni e risultati.
Dopo un salto condizionato c'è sempre una diramazione in due direzioni del flusso operazioni e l'unità di BP cerca di indovinare quali saranno le istruzioni successive, preparando dati, operazioni su di essi e risultato finale. Ottimo, bene...
...bene finchè la previsione viene eseguita (ovvero HIT, colpita) e questo accade nel 95-98% dei casi.
Ma cosa accade quando la previsione non viene "colpita"? Un dramma! Un dramma temporale perchè quando un'istruzione non viene predetta o un dato non viene trovato, avviene un "cachè missing" ed in questo caso la Pipeline viene COMPLETAMENTE svuotata e riempita di nuovo con una sequenza di dati corretta, perchè quelli buttati dentro i cicli prima non servono a nulla, e tutto deve essere azzerato.
Questo comporta la perdita di diversi, numerosi cicli di clock in operazioni "nullafacenti" e nasce un tempo di latenza dove la CPU lavora per il nulla mischiato al niente.
Viene da se comprendere che una Pipeline molto lunga è molto più efficiente (una volta che è piena e parte) di una più corta, ma è anche molto penalizzante nel caso di un cache missing e successivo completo svuotamento.
Tornando all'architettura AMD, questa ha scelto di utilizzare Pipeling molto molto lunghe, confidando in una unità di BP molto efficiente e con una percentuale di HIT superiore all'unità disponibile dentro gli INTEL. Però... un previsore rimane un oggetto che esegue una stima, una valutazione, una previsione appunto, che non sempre è conforme a quello che accade nella realtà. Ecco che inevitabilmente, alla faccia della migliore efficienza, tutto viene vanificato da una mancata previsione.
Questo spiega perchè alcuni software che sono "prevedibili" nel loro output (pernsiamo ad un rendering o ad una modifica su un'immagine statica) hanno buoni risultati, mentre altri, come i giochi, fortemente dinamici e mutevoli, hanno una minore efficienza, proprio perchè statisticamente maggiormente soggetti a produrre cachè missing.
Ecco spiegato l'arcano della minore efficienza degli AMD in alcune situazioni.
E' vero che il software può essere, in una qualche misura, ottimizzato per evitare i cache missing, con un flusso il più regolare e lineare possibile, ma il concetto stesso di programma che ha un'interazione con servizzi esterni (tra cui anche l'operatore) per sua stessa natura non può essere contenuto in rigide regole statiche e lineari.

Ciao Paolo, non ho capito in cosa AMD è più aggressiva rispetto a Intel?....nei processori superscalari (come quelli che hai citato tu) creare pipeline (mi piace il paragone della pipeline con la catena di montaggio) lunghe lunghe non è sempre una buona scelta soprattutto se non disponi di un BP al top e anche se ne disponi cmq il rischio di una errata previsione esiste come esiste la conseguente necessità di svuotare e di ricaricare tutta la pipeline....inoltre lo svuotamento delle pipeline c'entra solo in parte con il cache missing.... il problema dello svuotamento della pipeline non sta SOLO nel dove reperire le istruzioni ma sta nel riempirla tutta ex-novo...perchè per arrivare alla fase finale di RETIRE di un istruzione, tutti gli stadi precedenti della pipeline devono essere riempiti e questo COSTA cicli di clock...ovviamente più la pipeline è lunga più ha stadi e più impiega cicli a riempirsi...a prescindere dal dove si trovano le istruzioni (lo dico xchè anche se tutto fosse in cache e non ci fosse il cache missing....cmq lo svuotamento di una pipeline lunga è cmq una 'tragedia' in termini di performance).... rivelandosi errata la previsione, la pipeline deve essere svuotata e riempita poi con le ISTRUZIONI giuste....me se è lunga lunga impiega un sacco di tempo, cicli, a riempirsi a prescindere dal fatto che le istruzioni e/o i dati siano presenti nella cache (certo se non sono in cache aggiungi ai cicli di riempimento della pipeline anche i cicli dovuti a reperire le istruzioni o i dati da usare)...l'esperienza insegna che pipeline lunghe permettono clock alti...ma come ben sappiamo clock alti introducono latenze alte, ad esempio nelle cache; cache che vanno a 4,5 ghz avranno latenze molto più alte di cache che devono andare solo a 3ghz,..oltre al fatto che la pipeline di bulldozer è si lunga ma non così lunga.....il problema, secondo me, risiede proprio nelle unità di esecuzione che per non sforare con il transistor count le hanno semplificate troppo...vedi FPU AMD con la divisione e l'implementazione in SR..oltre al fatto che da quanto sapevo io l'unità migliore di BP non è di AMD..anzi....se non ricordo male anche in PD l'hanno migliorata...perchè non è proprio quella che si definisce un fulmine di guerra ..
Inoltre da quanto mi ricordo nei miei studi, HIT (come lo chiami) dovrebbe essere il cache HIT e non la previsione azzeccata... l'HIT si riferisce alla presenza o meno del dato/istruzione nella cache :'Quando il processore vuole leggere o scrivere in una data collocazione in memoria principale, inizialmente controlla se il contenuto di questa posizione è caricato in cache. Questa operazione viene effettuata confrontando l'indirizzo della posizione di memoria con tutte le etichette nella cache che potrebbero contenere quell'indirizzo. Se il processore trova che la posizione di memoria è in cache, si parla di cache hit (accesso avvenuto con successo), altrimenti di cache miss (fallimento d'accesso). Nel caso di un cache hit, il processore legge o scrive immediatamente il dato sulla linea di cache. Il rapporto tra cache hit e accessi totali è chiamato anche hit rate ed è una misura dell'efficacia della cache stessa."
la previsione non sta nel fatto di aver previsto che verranno eseguite quelle istruzioni e quindi riempio la cache, ma nel fatto che si sta riempiendo la pipeline di quelle istruzioni che si prevedono verranno eseguite alla presenza di un jump condizionato, in base a quanto è successo fino ad adesso (tenendo traccia dei jump e dei risultati in una tabella all'interno della CPU il BTB Branch Target Buffer se non ricordo male ...per cui si prevede che se 9 volte su 10 QUEL jump condizionale ha portato all'esecuzione di quelle istruzioni io intanto comincio a caricarmi la pipeline...se poi ho ragione, allora ho già le istruzioni pronte, ma se ho torto tutto il lavoro fatto in precedenza non serve a nulla..
ti consiglio questo libro interessantissimo che mi sono letto(e si parla anche di BD - 180 pagine interessantissime):
http://www.google.it/url?sa=t&rct=j&...1GXsYZcRij1K8w
e un'altra caratteristica che fa la differenza è la fusion micro op....anche lì si sta spingendo molto con i decoder cisc-risc
Ciao

[theProix87]

Sto caricando un Video sul mio canale di youtube cosi vi faccio vedere il problema del processore... non ne esco fuori, dal bios ho disabilitato tutti i parametri della gestione dei consumi e via dicendo...

Voi dite che non è il processore, ma il 1100T funzionava alla grande in OC, era sempre stabile, a dimostrazione che la mobo dovrebbe essere sana, invece questo 8350 non risponde proprio ai comandi che gli do... da bios l'OC proprio non va perchè frequenza e voltaggio che assegno non sono visualizzati su windows, poi ci si aggiunge che ha temperature davvero sballate, UFF....

Come posto il video vi prego di darmi una "Zampa"

Aggiungo che quando zoppica come poi vedrete... è impossibile giocarci e editare video.... dato che è come se andasse a scatti...

[paolo.oliva2]

Originariamente inviato da shellx

Non esiste spiegazione piu chiara e completa ! Caspita. Ma non ho capito l'hai letta o l'hai stesa tu ? Se l'hai letta che sito è ?

Non l'ho scritta io, è su tom's nel forum, al quesito 8350 vs 3770K.

Originariamente inviato da Randa71

Ciao Paolo, non ho capito in cosa AMD è più aggressiva rispetto a Intel?....nei processori superscalari (come quelli che hai citato tu) creare pipeline (mi piace il paragone della pipeline con la catena di montaggio) lunghe lunghe non è sempre una buona scelta soprattutto se non disponi di un BP al top e anche se ne disponi cmq il rischio di una errata previsione esiste come esiste la conseguente necessità di svuotare e di ricaricare tutta la pipeline....inoltre lo svuotamento delle pipeline c'entra solo in parte con il cache missing.... il problema dello svuotamento della pipeline non sta SOLO nel dove reperire le istruzioni ma sta nel riempirla tutta ex-novo...perchè per arrivare alla fase finale di RETIRE di un istruzione, tutti gli stadi precedenti della pipeline devono essere riempiti e questo COSTA cicli di clock...ovviamente più la pipeline è lunga più ha stadi e più impiega cicli a riempirsi...a prescindere dal dove si trovano le istruzioni (lo dico xchè anche se tutto fosse in cache e non ci fosse il cache missing....cmq lo svuotamento di una pipeline lunga è cmq una 'tragedia' in termini di performance).... rivelandosi errata la previsione, la pipeline deve essere svuotata e riempita poi con le ISTRUZIONI giuste....me se è lunga lunga impiega un sacco di tempo, cicli, a riempirsi a prescindere dal fatto che le istruzioni e/o i dati siano presenti nella cache (certo se non sono in cache aggiungi ai cicli di riempimento della pipeline anche i cicli dovuti a reperire le istruzioni o i dati da usare)...l'esperienza insegna che pipeline lunghe permettono clock alti...ma come ben sappiamo clock alti introducono latenze alte, ad esempio nelle cache; cache che vanno a 4,5 ghz avranno latenze molto più alte di cache che devono andare solo a 3ghz,..oltre al fatto che la pipeline di bulldozer è si lunga ma non così lunga.....il problema, secondo me, risiede proprio nelle unità di esecuzione che per non sforare con il transistor count le hanno semplificate troppo...vedi FPU AMD con la divisione e l'implementazione in SR..oltre al fatto che da quanto sapevo io l'unità migliore di BP non è di AMD..anzi....se non ricordo male anche in PD l'hanno migliorata...perchè non è proprio quella che si definisce un fulmine di guerra ..
Inoltre da quanto mi ricordo nei miei studi, HIT o il cache HIT non c'entra nulla con la previsione azzeccata ma si riferisce alla presenza o meno del dato/istruzione nella cache :'Quando il processore vuole leggere o scrivere in una data collocazione in memoria principale, inizialmente controlla se il contenuto di questa posizione è caricato in cache. Questa operazione viene effettuata confrontando l'indirizzo della posizione di memoria con tutte le etichette nella cache che potrebbero contenere quell'indirizzo. Se il processore trova che la posizione di memoria è in cache, si parla di cache hit (accesso avvenuto con successo), altrimenti di cache miss (fallimento d'accesso). Nel caso di un cache hit, il processore legge o scrive immediatamente il dato sulla linea di cache. Il rapporto tra cache hit e accessi totali è chiamato anche hit rate ed è una misura dell'efficacia della cache stessa."
la previsione non sta nel fatto di aver previsto che verranno eseguite quelle istruzioni e quindi riempio la cache, ma nel fatto che si sta riempiendo la pipeline di quelle istruzioni che si prevedono verranno eseguite alla presenza di un jump condizionato, in base a quanto è successo fino ad adesso (tenendo traccia dei jump in una tabella all'interno della CPU...per cui si prevede che se 9 volte su 10 QUELLO SPECIFICO jump condizionale ha portato all'esecuzione di quelle istruzioni io intanto comincio a caricarmi la pipeline...se poi ho ragione, allora ho già le istruzioni pronte, ma se ho torto tutto il lavoro fatto in precedenza non serve a nulla..
Ciao

Anche io su alcune cose non sono d'accordo... tipo pipeline lunghe lunghe.
Il discorso aggressività, penso sia riferito che BD è aggressivo come architettura... meno aggressivo di un PIV, ma più di un i7, e come le cose aggressive, introducono un fattore rischio più alto, e l'esempio l'abbiamo in Zambesi. Cioè... mettici un po' tutto... rischio di una predizione molto efficente per le pipeline lunghe, rischio perchè si deve avere un ottimo PP di silicio, rischio perchè AMD ha fatto un cambiamento radicale... mettici tutto...

----

Poi nella discussione parlavano, giustamente, che nel discorso giochi la soluzione AMD 8350 non è affatto inferiore al 3770K... perchè la spesa inferiore nel procio può concedere l'acquisto di una VGA superiore.
Però, secondo me non è vero del tutto, perchè a risoluzioni idonee ai monitor attuali, conta praticamente solo la VGA, perchè credo che non si raggiunga mai la situiazione CPU-limit. Se invece si ha CPU-limit, una VGA più potente non conta una mazza e lì o 3770K, o 2600K o comunque una soluzione Intel.
Cioè, dai, a parte (forse, perchè non l'ho provato) una maggiore fluidità, l'8350 sta dietro al 3770K quasi dovunque... in alcuni casi poco, in altri di più. Chiaro che se costassero uguale... Ma in ogni caso, siamo ben distanti da una situazione 1 modulo = 1 core Intel + HT, e questo è il dazio del rischio fatto dall'aggressività, intesa il passo più lungo della gamba.

[Randa71]

Originariamente inviato da paolo.oliva2

Non l'ho scritta io, è su tom's nel forum, al quesito 8350 vs 3770K.



Anche io su alcune cose non sono d'accordo... tipo pipeline lunghe lunghe.
Il discorso aggressività, penso sia riferito che BD è aggressivo come architettura... meno aggressivo di un PIV, ma più di un i7, e come le cose aggressive, introducono un fattore rischio più alto, e l'esempio l'abbiamo in Zambesi. Cioè... mettici un po' tutto... rischio di una predizione molto efficente per le pipeline lunghe, rischio perchè si deve avere un ottimo PP di silicio, rischio perchè AMD ha fatto un cambiamento radicale... mettici tutto...

----

Poi nella discussione parlavano, giustamente, che nel discorso giochi la soluzione AMD 8350 non è affatto inferiore al 3770K... perchè la spesa inferiore nel procio può concedere l'acquisto di una VGA superiore.
Però, secondo me non è vero del tutto, perchè a risoluzioni idonee ai monitor attuali, conta praticamente solo la VGA, perchè credo che non si raggiunga mai la situiazione CPU-limit. Se invece si ha CPU-limit, una VGA più potente non conta una mazza e lì o 3770K, o 2600K o comunque una soluzione Intel.
Cioè, dai, a parte (forse, perchè non l'ho provato) una maggiore fluidità, l'8350 sta dietro al 3770K quasi dovunque... in alcuni casi poco, in altri di più. Chiaro che se costassero uguale... Ma in ogni caso, siamo ben distanti da una situazione 1 modulo = 1 core Intel + HT.

d'accordo...sono d'accordo che il 8350 sia una bella CPU per quello che costa ed è un acquisto consigliatissimo....il mio era solo un discorso di più alto respiro ...non ero sul discordo valore economico CPU...dove 8350 è sicuramente una bella CPU....se fosse uscita al posto 8150..sarebbe stata una gran bella cosa ...l'architettura è cmq valida anche se nuova, come del resto si è sempre sostenuto...se consideriamo che anche 8350 è castrato dal PP perchè sono 200MHZ in + per singolo modulo mi sembrano pochini pochini....mi sarei aspettato almeno un 4400

[shellx]

OT:
ragazzi ma la sapevate questa cosa ?
http://boardreader.com/thread/Thread...3qnX1fj4n.html

Top contributing authors:
paolo.oliva in testa ed io secondo in classifica
vabbe basta chiudo l'ot la verità è che non mi viene sonno stanotte e sfantasio con internet..notte a tutti
FINE OT

[BodyKnight]

Originariamente inviato da gridracedriver

95%???...ora mi spiego i centri commerciali saturi di oem e mobile intel

Ma ti sei mai fatto un giro al centro commerciale di turno a contare quanti computer farlocchi con l'e-350/450 c'erano? Dico farlocchi perchè assemblano un formato notebook, con dentro un e-350.

[isomen]

Originariamente inviato da theProix87

Sto caricando un Video sul mio canale di youtube cosi vi faccio vedere il problema del processore... non ne esco fuori, dal bios ho disabilitato tutti i parametri della gestione dei consumi e via dicendo...

Voi dite che non è il processore, ma il 1100T funzionava alla grande in OC, era sempre stabile, a dimostrazione che la mobo dovrebbe essere sana, invece questo 8350 non risponde proprio ai comandi che gli do... da bios l'OC proprio non va perchè frequenza e voltaggio che assegno non sono visualizzati su windows, poi ci si aggiunge che ha temperature davvero sballate, UFF....

Come posto il video vi prego di darmi una "Zampa"

Aggiungo che quando zoppica come poi vedrete... è impossibile giocarci e editare video.... dato che è come se andasse a scatti...

Se a default va bene la cpu é a posto, il problema potrebbe essere il bios... cmq prova a fare un clearcmos e a reimpostare tutto (in questo modo a volte si risolvono cose impensabili.

CIAUZ)

[paolo.oliva2]

Originariamente inviato da isomen

Se a default va bene la cpu é a posto, il problema potrebbe essere il bios... cmq prova a fare un clearcmos e a reimpostare tutto (in questo modo a volte si risolvono cose impensabili.

CIAUZ)

Tu sei riuscito a disabilitare 1 core a modulo?
Non riesco a capire... con l'8150 i bios lo prevedevano ed ora con l'8350 sembra che l'abbiano tolto tutti i bios.

[PeteRParkeR]

Originariamente inviato da shellx

Non so che cavolo ho toccato nel bios nelle voci, ma mi regge da un ora e mezzo i 4,5ghz a 1,39v (nb def, ram def) sotto stress con cpuburn e vari bench phoronix.

Tanto per sapere... Shellx ma con 1,39v ad aria ( mi pare di ricordare...) con che dissipatore stai ?? così magari mi faccio un idea per l'upgrade dissipativo... (sotto ottimi consigli di paolo@Forse il test che mi dicevi di fare...difficilmente riesco a farlo...qui da me 5-10 gradi di temp esterna è difficile che li raggiungo!!! ahahaha )

Per quanto riguarda la LLC se la lasci "auto" si prende da sola valori a seconda delle richieste della cpu...non è disattivata con auto...( lo è se metti regular che equivale 0% di LLC!! la mobo dovrebbe restituire il comportamento di base senza correzioni sul circuito.)

Cmq attualmente ho trovato un compromesso con limiti sui 60° sui 4236Mhz 1,3312v cpu/nb= 1,15v (è stabile a 2222MHz sia nb che ht !! e mi fa scaldare meno...) da bios (201bios@201,68 x21 su win le asus devono metterci sempre lo zampino!!) cpu llc = high cpu/nb = high ; cpu e cpu/n capability = 130% power phase control = optimized asus ; power duty control = T.probe ( in relaz alle temp anche se credo sarebbe meglio extreme per avere erogazione corrente in modo ultra-stabile ).
Cmq a mio parere una componente negativa sono le benedette ram ( ho a disposiz le vengeance black c8 1600 8gb , ma non ci stanno a cas 8 stabilità a 1600 per ora solo a cas 9 forse dovrei alzare voltaggio ddr magari a 1,6 ?? ma dovrebbero essere certificate 1,5v a 1600 c8...mah??)

[PeteRParkeR]

Originariamente inviato da TheBestFix

ad occhio e croce punterei sul dissi......se vuoi puoi fare una prova smontalo puliscilo e controlla la superficie di contatto della base in rame, di sicuro non e' stata rifinita a dovere sara' concava o convessa, in tal caso una lappatura a specchio potrebbe giovare alle temperature
ancora piu' semplice con la cpu sotto stress tocca la base del dissi (se riesci) se e' calda e' ok se e' appena tiepida e' come penso io...

Pardon...mi ero dimenticato di rispondere....(grazie della tua risposta!! )
Si è un'operazione che ho fatto di smontare e rimontare e tastare con mano...per ovviare a difetti di questo genere...( la superficie cmq sembra aderire perfettamente all' HIS della cpu! Ed è caldo sufficientemente da poter fugare dubbi...la qualità costruttiva della cooler master mi sembra adeguata...) C'è pure da dire che se fosse questo il problema come insegna la "trasmissione del calore" anche a carichi bassi ci sarebbero temperature elevate rispetto alla norma...invece in idle la cpu è molto fresca ( ora per esempio è fermo da 10 min e sta sui 13-14° sui core e 34-35 sulla cpu da hwmonitor con una temp ext di 19-20° ) probabilmente come messo in evidenza dai test e come suggerito qui sul forum il dissipatore hyper612s soffre a dissipare i watt generati da una cpu 8core... non ci vedo altre motivazioni altrimenti...

[TheBestFix]

Originariamente inviato da PeteRParkeR

Pardon...mi ero dimenticato di rispondere....(grazie della tua risposta!! )
Si è un'operazione che ho fatto di smontare e rimontare e tastare con mano...per ovviare a difetti di questo genere...( la superficie cmq sembra aderire perfettamente all' HIS della cpu! Ed è caldo sufficientemente da poter fugare dubbi...la qualità costruttiva della cooler master mi sembra adeguata...) C'è pure da dire che se fosse questo il problema come insegna la "trasmissione del calore" anche a carichi bassi ci sarebbero temperature elevate rispetto alla norma...invece in idle la cpu è molto fresca ( ora per esempio è fermo da 10 min e sta sui 13-14° sui core e 34-35 sulla cpu da hwmonitor con una temp ext di 19-20° ) probabilmente come messo in evidenza dai test e come suggerito qui sul forum il dissipatore hyper612s soffre a dissipare i watt generati da una cpu 8core... non ci vedo altre motivazioni altrimenti...

....

[winebar]

Riguardo al megapost che paolo ha copiato da tommy (senza che abbia controllato, infatti avevo risposto a quella discussione), faccio un paio di precisazioni.

1 - La BP dei processori basati su architettura Bulldozer è superaggressva. Si penalizzano tutti i processi che fanno troppe MISS in tutti e tre i livelli della cache. Questo è dovuto, in parte, anche alla poca velocità che garantisce il MC dei processori AMD rispetto al massimo teorico dei banchi di ram (ad esempio il MC di Intel supera i 22GB/s, ma i banchi arrivano, in dual channel, appena sopra i 17/18). Quindi AMD tenta di ridurre al minimo gli eventi di lettura dalla RAM che potrebbero non avvenire.
Sempre riguardo la branch prediction, quella di AMD non è la più efficente. Esattamente come non lo è quella di Intel. Proprio sulla BP esistono studi universitari quasi 30nnali (se non più vecchi).

2 - Riguardo le pipeline lunghe, non sono le migliori (generalmente le pipeline più sono corte meglio è), però una pipeline lunga permette di salire tantissimo in frequenza. Prendiamo Intel. Usa pipeline molto corte. Il risultato è una maggiore velocità nei calcoli ST. Però quando si porta il processore ad alte frequenze non riesce a reggere. Tant'è che i 5,5 Ghz ad azoto con un 3770k sono quasi da record mondiale.

Insomma, ancora una volta AMD dimostra un approccio differente da quello di Intel. Da una parte vuole una branch prediction più efficente (e qui la colpa si divide in due, in parte è colpa degli sviluppatori del software e in parte degli sviluppatori dei compilatori) mentre dall'altra usa delle pipeline lunghe che sono meno efficenti ma che permettono ad AMD di aumentare la potenza generale in modo molto più efficente.

[Nforce Ultra]

Originariamente inviato da PeteRParkeR

Pardon...mi ero dimenticato di rispondere....(grazie della tua risposta!! )
Si è un'operazione che ho fatto di smontare e rimontare e tastare con mano...per ovviare a difetti di questo genere...( la superficie cmq sembra aderire perfettamente all' HIS della cpu! Ed è caldo sufficientemente da poter fugare dubbi...la qualità costruttiva della cooler master mi sembra adeguata...) C'è pure da dire che se fosse questo il problema come insegna la "trasmissione del calore" anche a carichi bassi ci sarebbero temperature elevate rispetto alla norma...invece in idle la cpu è molto fresca ( ora per esempio è fermo da 10 min e sta sui 13-14° sui core e 34-35 sulla cpu da hwmonitor con una temp ext di 19-20° ) probabilmente come messo in evidenza dai test e come suggerito qui sul forum il dissipatore hyper612s soffre a dissipare i watt generati da una cpu 8core... non ci vedo altre motivazioni altrimenti...

Secondo me il problema del tuo dissipatore è la ventola guarda qui:
http://www.coolingtechnique.com/img/...s-fan-data.png

La pressione statica di questa ventola è troppo bassa per un dissipatore, cambiala con una migliore