Ritorna HyperThreading con le cpu Silverthorne

Ritorna HyperThreading con le cpu Silverthorne

Intel anticipa parte delle caratteristiche tecniche di Silverthorne, cpu destinata a sistemi ultra portatili: tra queste il ritorno di HyperThreading

di pubblicata il , alle 11:56 nel canale Processori
Intel
 
I migliori sconti su Amazon oggi
34 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
MaxArt05 Febbraio 2008, 13:18 #21
La CPU VIA è Nehemiah, non Nehalem...

Comunque 1 W è davvero poco, magari con un downclock si può usare sui PDA più grossi...
+Benito+05 Febbraio 2008, 13:20 #22
le cpu via sono con core nehemiah, non nehalem
groot05 Febbraio 2008, 13:22 #23
Intel sembra avere definitivamente stracciato AMD, alternanza piacevole...
K7-50005 Febbraio 2008, 13:59 #24
Con tutto il rispetto ma un P75 non è comparabile a un processore come questo, non si deve solo guardare il consumo. Hanno una complessità di componenti da far paura.

Come dice un altro utente, quando hai un pc in un cubetto te ne freghi se non ci giochi a Crysis...
Dumah Brazorf05 Febbraio 2008, 14:10 #25
Originariamente inviato da: Pier de Notrix
Benefici??? Ma se fu uno scandalo di incapacità tecnologica! Era un'insulsa tecnologia che rallentava incredibilmente quei già buggati processori.
Quando fu abbandonata ricordo ancora i commenti di molti che gridarono: "alleluja!"


Credo che il problema maggiore fosse dovuto ai 31 (trentuno) stadi che raggiunse la pipeline negli esemplari + veloci. Già Willamette ne aveva 20.
L'abbandono di Netburst ha segnato la rinascita di Intel.
groot05 Febbraio 2008, 14:12 #26
i quad si possono sfruttare realmente?

ho sempre avuto l'idea che sia meglio un mono a 4ghz che un bi che gira a 2...

voi che dite?
]DaLcA[05 Febbraio 2008, 14:22 #27
Originariamente inviato da: coschizza
[...]

un processore in-order è costretto a eseguire le istruzioni in ordine e non puo fare salti o utilizzare algoritmi per prevedere ed eseguire istruzioni in anticipo ma questo vale per il singolo thread, se hai pu thread eseguiti n parallelo sullo stesso hardware alla fine sono comunque 2 flussi di istruzioni differenti e indipendenti.


Si possono considerare i salti come sempre fatti o non fatti, questa è una specie di "predizione" delle istruzioni!

Aggiungo che se un thread effettua una richiesta di I/O (che si tratti di dati in cache, con miss o hit, sia di I/O su disco) va in stallo per n cicli, mentre l'altro può proseguire nella pipeline. A questo proposito sarebbe interessante sapere se il multithread hardware è gestito a grana fine o a grana grossa.


Credo che non ci sia da stupirsi per valori di consumo così bassi: nelle cpu non superscalari (cioè quelle che, detta in modo banale, non possono eseguire più operazioni contemporaneamente) l'unità di controllo è molto semplice. Faccio notare che nelle CPU moderne la GRAN parte del consumo è data proprio dall'unità di controllo. Se poi aggiungiamo il fatto di essere a 45nm e lavorare a chissà quali bassi voltaggi, abbiamo qualche motivo in meno per gridare al miracolo
coschizza05 Febbraio 2008, 14:25 #28
Originariamente inviato da: groot
i quad si possono sfruttare realmente?

ho sempre avuto l'idea che sia meglio un mono a 4ghz che un bi che gira a 2...

voi che dite?


dipende sempre dalla situazione, ti faccio un esempio pratico

hai 1 cpu da 3ghz e la utilizzi per renderizzare con il 3dsmax, diciamo che il rendering dura 10 minuti

ora prendi un pc con 2 cpu da 1,5ghz e fai la stessa cosa di prima e vedrai che il tempo di rendering è lo stesso.

ma allora cosa cambia?

nel caso citato vedrai che nel pc con la cpu da 3ghz mentra stai renderizzando il sistema risulta particolarmente appesantito, a tal punto da impedirti di utilizzare altre applicazioni

nel secondo caso il sistema risponderà comunque molto piu prontamente e potrai fare altro (impattando sulle prestazioni ovviamente)
ErPazzo7405 Febbraio 2008, 15:00 #29
Originariamente inviato da: coschizza
è molto piu facile utilizzare tecnologie come l'hyperthreading o il multi thread in cpu in-order rispetto alle nostre cpu x86 classiche out-of-order, quest o perche le cpu hanno una logica estremamente meno complessa e quindi lasciano molto piu spazio a implementazioni differenti, un po come è avvenuto i tutte le cpu per console dove hanno sacrificato tutti i vantaggi del out-of-order per spingere al massimo il numero di thread eseguiti in sequenza.

un processore in-order è costretto a eseguire le istruzioni in ordine e non puo fare salti o utilizzare algoritmi per prevedere ed eseguire istruzioni in anticipo ma questo vale per il singolo thread, se hai pu thread eseguiti n parallelo sullo stesso hardware alla fine sono comunque 2 flussi di istruzioni differenti e indipendenti.


Grazie della risp in effetti leggendo le tue osservazioni mi viene in mente che forse il guadagno prestazionale dato dall'hyperthreading in una cpu in-order possa essere maggiore di una out-of-order..........
che ne dici è così?
coschizza05 Febbraio 2008, 15:12 #30
Originariamente inviato da: ErPazzo74
Grazie della risp in effetti leggendo le tue osservazioni mi viene in mente che forse il guadagno prestazionale dato dall'hyperthreading in una cpu in-order possa essere maggiore di una out-of-order..........
che ne dici è così?


esatto
visto che una cpu in-order utilizza le risorse interne in maniera meno efficiente di una out-of-order allora si presta di piu a eseguire codice parallelo
« 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.
 
^