Due tagli di cache per le cpu Conroe

Due tagli di cache per le cpu Conroe

La prossima evoluzione di cpu Intel per segmento desktop verrà proposta con due differenti dimensioni di cache L2, a seconda del modello

di pubblicata il , alle 08:16 nel canale Processori
Intel
 
I migliori sconti su Amazon oggi

Lenovo, Notebook Portatile, V15 G4 IRU, Display 15,6" Full HD, Intel Core i5-13420H, Ram 16 GB DDR4, 512 GB SSD NVMe, Win 11 Pro, Libre Office, Preconfigurato

419.00€ Compra ora

CHEBIO Aspirapolvere Senza Fili, 45Kpa/550W/70 Mins Scopa Elettrica Senza Fili con Automatische Saugeinstellung e Display LED, Aspirapolvere con Anti-Avvolgimento per Pavimenti/Tappeti/Peli

107.99€ Compra ora
-46%

Echo Dot (Ultimo modello) | Altoparlante intelligente Wi-Fi e Bluetooth, suono più potente e dinamico, con Alexa | Blu notte

64.99 34.99€ Compra ora
59 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
s0r428 Gennaio 2006, 12:14 #11
hanno ricominciato ad allungare la pipeline?
ma non imparano mai?
JohnPetrucci28 Gennaio 2006, 12:20 #12
Aspetto le recensioni future sui Conroe, sono curioso della risposta che Intel ha preparato, anche se prevedo che sarà dura scalzare il vantaggio di Amd.
sirus28 Gennaio 2006, 12:21 #13
hanno aumentato di 2 stadi la lunghezza della pipeline rispetto al Pentium M se non erro, sintomo che queste CPU scaleranno un po' meglio in frequenza anche perché immagino saranno dotate di Quad Pumped BUS a 800 e 1066 (per gli EE)!!!
AMD ha anche posticipato il Socket M2, sinceramente non capisco il motivo, Intel aveva annunciato il suo Conroe per il Q306 e AMD ha ritardato il debutto delle nuove soluzioni per lo stesso periodo avrebbe potuto avere ancora un po' di vantaggio?!
@overclock80 su che cosa ti basi per dire che gli AMD saranno ancora superiori agli Intel?
sirus28 Gennaio 2006, 12:23 #14

@ JohnPetrucci

per le prestazioni...
prendi un Core Duo, gli autmenti le frequenze (tipo dual 2600/2800) e ottini le prestazioni di Conroe (più o meno) anche se Conroe avrà una FPU completamente nuova e non una semplice revisione come è successo per Yonah
-fidel-28 Gennaio 2006, 13:01 #15
Una domanda: una lunga pipeline, pur essendo più complessa da gestire per diversi motivi con l'aumentare della lunghezza, non porta sempre vantaggi prestazionali? Se no, quali sono gli aspetti che possono portare ad avere vantaggio ad usare una pipeline più corta?
quartz28 Gennaio 2006, 13:24 #16
Originariamente inviato da: -fidel-
Una domanda: una lunga pipeline, pur essendo più complessa da gestire per diversi motivi con l'aumentare della lunghezza, non porta sempre vantaggi prestazionali? Se no, quali sono gli aspetti che possono portare ad avere vantaggio ad usare una pipeline più corta?

Le pipeline più corte consentono di avere una maggiore efficienza a parità di clock. Le moderne CPU hanno dei meccanismi di branch prediction (tentano di indovinare quale sarà l'istruzione successiva), che gli consentono di avere sempre tutti gli stadi della pipeline pieni e operativi.
Se questi algoritmi falliscono la previsione, si avrà una cosiddetta "bolla", cioè stadi della pipeline vuoti.
A quel punto sarà necessario cancellare il contenuto dell'intera pipeline, e ciò comporta maggiori sprechi di cicli di clock, maggiore è il numero degli stadi.
Per questo una pipeline più corta è più efficiente di una lunga.
-fidel-28 Gennaio 2006, 13:38 #17
Originariamente inviato da: quartz
Le pipeline più corte consentono di avere una maggiore efficienza a parità di clock. Le moderne CPU hanno dei meccanismi di branch prediction (tentano di indovinare quale sarà l'istruzione successiva), che gli consentono di avere sempre tutti gli stadi della pipeline pieni e operativi.
Se questi algoritmi falliscono la previsione, si avrà una cosiddetta "bolla", cioè stadi della pipeline vuoti.
A quel punto sarà necessario cancellare il contenuto dell'intera pipeline, e ciò comporta maggiori sprechi di cicli di clock, maggiore è il numero degli stadi.
Per questo una pipeline più corta è più efficiente di una lunga.


Molto chiaro. Non ricordavo che in presenza di una 'bolla' si dovesse svuotare l'intera pipeline. Ricordavo erroneamente che questo non fosse necessario. Thx
serpico8428 Gennaio 2006, 14:09 #18
ottimo son contento....questa architettura dovrebbe promettere bene, almeno in partenza
sirus28 Gennaio 2006, 15:34 #19

@ -fidel-

una pipeline lunga è ottima per scalare in frequenza ma ovviamente è molto complessa da gestire e la circuiteria di branch prediction è molto complicata...questo avveniva con i primi Pentium 4 core Northwood (versioni A e B) poi con la versione C (e con solo alcune versioni della B) c'è stata l'introduzione del HT che in pratica divide la pipeline in due parti (creando una sorta di parallelismo) e lo svuotamente e l'eventuale immissione di micro-istruzioni da elaborare poteva essere fatto anche a metà della pipeline
ora si tende ad aumentare l'efficenza come ha detto quartz piuttosto che ha curarsi della forza bruta
-fidel-28 Gennaio 2006, 16:09 #20
Originariamente inviato da: sirus
una pipeline lunga è ottima per scalare in frequenza ma ovviamente è molto complessa da gestire e la circuiteria di branch prediction è molto complicata...questo avveniva con i primi Pentium 4 core Northwood (versioni A e B) poi con la versione C (e con solo alcune versioni della B) c'è stata l'introduzione del HT che in pratica divide la pipeline in due parti (creando una sorta di parallelismo) e lo svuotamente e l'eventuale immissione di micro-istruzioni da elaborare poteva essere fatto anche a metà della pipeline
ora si tende ad aumentare l'efficenza come ha detto quartz piuttosto che ha curarsi della forza bruta


Rigrazie per l'ulteriore approfondimento
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^