Link alla notizia: http://news.hwupgrade.it/13437.html

Nuovi dettagli per le prossime versioni di processore Pentium 4. Nel mese di Novembre il debutto del bus Quad Pumped a 1.066 MHz, mentre da metà 2005 si parlerà di Dual Core

Click sul link per visualizzare la notizia.

tutti sti megaherz, tutta sta cache.... ma il calore? i consumi? ma dove arriviamo?

ma clock di 3200 vuol dire che i due core sono clokkati a 1600 e entrambi hanno 1 mega di cache o sbaglio??

Ma la mancata implementazione del HT è dovuta a problemi tecnici causati dai 2 core?

Dual Core e istruzioni a 64Bit: finalmente un passo avanti (almeno teorico) per Intel...

Però penso che fino al Q3/2005 Amd consoliderà ancora di più la sua posizione nel mercato dei single core con A64 0.09 ...
Infondo i prescott sono veramente mal visti almeno dall'utenza esperta....

Io mi tengo il mio bel P4 NW 2.8@3.5 M0 per un bel po'... i Prescott li salto più che volentieri.

Pare che i dual core Intel e AMD li vedremo insieme...
Come si poteva immaginare i dual hanno frequenza più bassa.

Non capisco neppure io come mai non c'è il supporto per l'HT..

Perchè evidentemente serve logica (spazio su die e consumi) per gestirlo e comunque avendo 2 "processori fisici" il suo impatto probabilmente sarebbe stato più limitato.

Concordo con dOnDa. Mi sembra che Intel stia un pò alla frutta. Anche per il prossimo anno continuerà ad investire su un'architettura che già oggi manifesta i suoi limiti. Di certo 2 core Prescott con 1 MB di cache ciascuno saranno davvero un bell'esperimento "termico".

x P-Boss. Non credo proprio. Vista l'architettura a pipeline lunghe (31) del Prescott, per intel sarebbe proprio tagliarsi le gambe da sola. Il Prescott è fatto per scalare bene in frequenza (almeno sulla carta). Già i Prescott 2.8 hanno a volte prestazioni inferiori al Northwood-C (che ha la metà della cache!).

x piffe. Mi vengono in mente solo 2 motivi.
1) Disperato tentativo di Intel di ridurre un pò il numero dei transistor (causa problemi termici) eliminando una tecnologia che in fondo non porta dei vantaggi sensibili, a volte il contrario.

2) Sistemi Operativi. WinXp Pro supporta 2 CPU. 2 CPU con HT verrebbero viste come 4 e questo forse potrebbe dare problemi.

IMHO

Byez

Nei processori dual core l'HT forse non avrà una grande utilità visto che le operazioni in cui fa guadagnare performance sono quelle eseguibili in calcolo parallelo.
Per le frequenze credo che si tratti di due cpu da 2.8, 3, 3.2 GHz ognuna visto che con queste nuove cpu dovrebbero guadagnare in prestazioni rispetto al modello di punta prima del loro ingresso. Quindi P4 3.8 GHz ultimo modello prima dei dual core che sarà formato da due core a 2.8GHz ovvero equivalente ad una cpu da circa 2.8+1.4 GHz = 4.2GHz mediamente, almeno stando alle prime info.

beh c'è solo da sperare che i due core non siano basati sull'architettura prescott... altrimenti ancora una volta l'architettura Amd sarebbe preferibile.

Certo che Intel dopo il Northwood non ha sfornato nulla di decente...

Riprendendo l'amico di cui sopra, anche io mi terrò stretto il North @3.2

Originariamente inviato da ulisss
Certo che Intel dopo il Northwood non ha sfornato nulla di decente...

Beh, non è vero! Ha tirato fuori i Pentium-M che sono una gran cosa; se solo Intel sviluppasse questi anche per i desktop invece di quella ciofeca del Prescott....

Credo che non vi sia il supporto HT per un motivo molto semplice: ht lo hanno inventato per simulare due core logici in un core fisico, il tutto chiaramente con le limitazioni del caso.
Quando hai a disposizione 2 core fisici diciamo che l'HT è spontaneo, difatti il winXPpro li riconosce e li sfrutta. Se metteranno l'HT ci saranno 4 core logici!

Originariamente inviato da JoJo
Beh, non è vero! Ha tirato fuori i Pentium-M che sono una gran cosa; se solo Intel sviluppasse questi anche per i desktop invece di quella ciofeca del Prescott....

Hai ragione i core Banjas e Dothan sono ottimi, ma io intendevo cpu disponibili per desktop.
Sarebbe una soluzione vincente un dual con i core dei P-Mob.

Scusate... ma l'HT non c'è anche negli Itanium multicore presentat di recente?

Per me è stato disabilitat per ragioni di marketing (potranno far uscire in futuro CPU dualcore con HT abilitato) o per ragioni di stabilità...

Anche perchè L'HT come è noto con pipeline lunghe aumenta significativamente le prestazioni con il software che lo permette

IMHO :D

Mi è sorto un dubbio a proposito dell'overclock.. un aumento di 200 mhz per ciascuno dei core porta ad un aumento di 300mhz(o 400?) del dual core? se così fosse sarebbe possibile ottenere discreti boost di frequenza senza eccessiva produzione di calore(sempre che non raggiunga temperature di ebollizione già in idle ma io non credo). Rimango perplesso su molti aspetti di questa nuova tecnologia dal punto di vista del calore.. e i miei dubbi trovano conferma nel recente brevetto di celle di peltier integrate nei dual core by AMD.

Sarà già un mezzo miracolo veder sfruttati tra 8 mesi i dual core (visto che di applicazioni pensate per dual cpu/HT ce ne sono pochissime), non chiedete la luna per avere anche l'HT :D

Originariamente inviato da LASCO
Nei processori dual core l'HT forse non avrà una grande utilità visto che le operazioni in cui fa guadagnare performance sono quelle eseguibili in calcolo parallelo.


perchè secondo te il dual core darebbe vantaggi negli applicativi che non sono ottimizzati per il calcolo in parallelo? la verità è che da qui ad un anno assisteremo ad uno sviluppo del software che sfrutta la possibilità di parallelizzazione...e come se ne avvantaggeranno i processori dual core allo stesso modo (anche se ovviamente in misura minore) se ne avvantaggeranno i processori con HT.
Il fatto che sia AMD che Intel spingano sulla moltiplicazione progressiva dei core cioè avrà effetti nello sviluppo del software...e di questo sviluppo (ormai inevitabile: saranno entreambi i competitor a spingere in questa direzione e non più solo Intel) si avvantaggeranno anche i vecchi p4 HT.

Piuttosto credo che l'Ht sarà implementato in futuro, giusto per dare la possibilità ad Intel di frazionare le novità e ricavarne il massimo profitto.

ma io da quello che ho notato in giro ho visto che gli AMD sono buoni solo sui bench dei giochi... per il resto, quasi tutto il resto sono preferibili i P4 Northwood o Prescott che siano, specie (cosa banale ma fastidiosissima se lenta) in multitasking in ambiente winzozz i P4 sono assolutamente superiori agli AMD grazie all'ht

Intende dire che avendo già un dual core, non ci sarebbe quel salto di prestazioni che si ha sul single core, pur potendo sfruttare in teoria quattro thread invece di due. Il che è ragionevole. La ragione più importante, secondo me, è che la logica HT occupa spazio, e magari in un dual core, a causa dei controlli di coerenza dei dati, sarebbe anche maggiore della somma delle parti. Indi, un die più grande _> maggiori costi che forse non valgono la candela.

Originariamente inviato da Lestat.me
ma io da quello che ho notato in giro ho visto che gli AMD sono buoni solo sui bench dei giochi... per il resto, quasi tutto il resto sono preferibili i P4 Northwood o Prescott che siano, specie (cosa banale ma fastidiosissima se lenta) in multitasking in ambiente winzozz i P4 sono assolutamente superiori agli AMD grazie all'ht


Scusa ma che bench guardi tu per pura curiosità.....sai, mi sembra che nn siano così "assolutamente superiori" anzi...

Originariamente inviato da Lestat.me
ma io da quello che ho notato in giro ho visto che gli AMD sono buoni solo sui bench dei giochi... per il resto, quasi tutto il resto sono preferibili i P4 Northwood o Prescott che siano, specie (cosa banale ma fastidiosissima se lenta) in multitasking in ambiente winzozz i P4 sono assolutamente superiori agli AMD grazie all'ht

eh? :D

rendici di grazia partecipi dei benchmark che hai visto tu...



P.S.: AMD intesi come K8...?

Originariamente inviato da leoneazzurro
Intende dire che avendo già un dual core, non ci sarebbe quel salto di prestazioni che si ha sul single core, pur potendo sfruttare in teoria quattro thread invece di due. Il che è ragionevole. La ragione più importante, secondo me, è che la logica HT occupa spazio, e magari in un dual core, a causa dei controlli di coerenza dei dati, sarebbe anche maggiore della somma delle parti. Indi, un die più grande _> maggiori costi che forse non valgono la candela. Esatto, non l'ho esplicitato. E' chiaro che avere l'HT è sempre qualcosa in più, ma con il dual core bisogna vedere se il gioco vale la candela

Originariamente inviato da Spectrum7glr
perchè secondo te il dual core darebbe vantaggi negli applicativi che non sono ottimizzati per il calcolo in parallelo? la verità è che da qui ad un anno assisteremo ad uno sviluppo del software che sfrutta la possibilità di parallelizzazione...e come se ne avvantaggeranno i processori dual core allo stesso modo (anche se ovviamente in misura minore) se ne avvantaggeranno i processori con HT.
Il fatto che sia AMD che Intel spingano sulla moltiplicazione progressiva dei core cioè avrà effetti nello sviluppo del software...e di questo sviluppo (ormai inevitabile: saranno entreambi i competitor a spingere in questa direzione e non più solo Intel) si avvantaggeranno anche i vecchi p4 HT.

Piuttosto credo che l'Ht sarà implementato in futuro, giusto per dare la possibilità ad Intel di frazionare le novità e ricavarne il massimo profitto.

Mah io sn un pò scettico sullo sviluppo di sw in questo senso...

Non è così semplice progettare/riprogettare applicazioni ad hoc che sfruttino questo tipo di architetture ( ne sn una prova le estremizzazioni dei concetti espressi con l'EPIC)...

E' vero che sw e hw si trainano a vicenda ma è anche vero che poi le aziende debbano valutare autonomamente se i costi di certe operazioni giustifichino un incremento di prestazioni che nel caso del Dual Core ( da Single Core) non è banalmente un "raddoppio".

Mi permetto di fare qualche supposizione...

Il clock inferiore di Smithfield è pienamente giustificato dall'esigenza di limitare il calore dissipato...

Due Prescott a 3.2 Ghz consumano circa 84 Watt di TDP...84x2 sono un po' troppi...quindi, visto che la necessità di salire in frequenza non è più primaria, suppongo che ritorneranno all'architettura del Northwood, 20 stadi di pipeline...per risparmiare ancora un po' sul calore prodotto...direi circa 20 Watt...
Aggiungeteci un utilizzo della cache simile a quello del Banias...il che toglie ancora qualche watt...5 Watt in meno...

Siamo a 60 Watt per ogni core...

Hanno tolto anche l'HyperThreading per risparmiare sul calore prodotto...a calcoli fatti aggiungeva un 10-15% di calore fra attivato e disattivato...

Quindi escludendo questo 10-15% si va a 52-57 Watt...

Consumo accettabile...che riporta a 105-115 Watt di TDP per l'intera CPU ;)

Qusi sicuramente l'HT c'è ma è disabilitato visto che c'è il supporto per EM64T, non credo che intel si sia messa a rivare il layout di un core che già funziona per metterlo in dual core...

Sarebbe da scommeterci che dopo 6 mesi usciranno processori dualcore con HT abilitato ;)

Oltretutto se avessero 4 CPU totale (2 core + 2 logiche) la licenza di XP sarebbe ancora valida? Sarebbero supportate o ci vuole una patch per fargli vedere le 2 CPU in più?

è da suicidio comprare una cpu intel fino il 2006.

Originariamente inviato da cionci
Mi permetto di fare qualche supposizione...

Il clock inferiore di Smithfield è pienamente giustificato dall'esigenza di limitare il calore dissipato...

Due Prescott a 3.2 Ghz consumano circa 84 Watt di TDP...84x2 sono un po' troppi...quindi, visto che la necessità di salire in frequenza non è più primaria, suppongo che ritorneranno all'architettura del Northwood, 20 stadi di pipeline...per risparmiare ancora un po' sul calore prodotto...direi circa 20 Watt...
Aggiungeteci un utilizzo della cache simile a quello del Banias...il che toglie ancora qualche watt...5 Watt in meno...

Siamo a 60 Watt per ogni core...

Hanno tolto anche l'HyperThreading per risparmiare sul calore prodotto...a calcoli fatti aggiungeva un 10-15% di calore fra attivato e disattivato...

Quindi escludendo questo 10-15% si va a 52-57 Watt...

Consumo accettabile...che riporta a 105-115 Watt di TDP per l'intera CPU ;)

Attenzione che la cache sarà unificata qui.. devi metterla a parte nell'equazione :)

Nono...non è unificata...richiederebbe un ridisegno molto forte di tutta l'architettura...
Se vedi c'è scritto anche nella news: L2 2x1Mb ;)

[QUOTE]Originariamente inviato da Duncan
Qusi sicuramente l'HT c'è ma è disabilitato visto che c'è il supporto per EM64T, non credo che intel si sia messa a rivare il layout di un core che già funziona per metterlo in dual core...

EMT 64 = HT? direi di no.

Originariamente inviato da cionci
Nono...non è unificata...richiederebbe un ridisegno molto forte di tutta l'architettura...
Se vedi c'è scritto anche nella news: L2 2x1Mb ;)


Hmm.. eppure da qualche parte avevo letto che lo sarebbe stata.. vabbè, my fault. Certo che è una esagerazione mica male (si arriverà presto a 4 Mega di cache su un solo die? )

Originariamente inviato da leoneazzurro
EMT 64 = HT? direi di no.


No, però può dare indicazione sul core utilizzato che dovrebbe essere il medesimo del Prescot

Anche se leggendo i calcoli di cioci il dubbio me lo ha fatto venire ;)

Immagino che dovranno rivedere molte cose nel core ;)
Non potranno certo fare 1+1 = 2, ci dovranno essere controlli di coerenza dei dati, e via dicendo

a me queste cpu non sembrano tanto male tutto sta nel vederle al operra contro le daul core amd.

avevo letto un articolo qui su hwupgrade dove si erà discusso di dual core e molti propendevano per la chache unificata.
effettivamente avendo due cache l2 si è costretti a creare due zone apposite che potrebbero renderne più difficile la realizazzione, poi potrebbe servire un ulteriore controller per verificare la comparabilita dei dati nelle due chache e magari attuare un interscambio.
di contro se i due core dovranno lavorare su treahd di dati diversi in chache con una cache condivisa potrebbero nascere delle interferenze.

Xcionci 2,8 ghz e 1mb di cheche ht disabilitato potrebbe davvero avere le pipeline a 20 stadi anzi che a 32!!speriamo!

lavoreranno sul attuale socket come gli amd? oppure alla intel tireranno fuori un nuovo socket?

credo che comunque le uniche difficoltà che presenteranno lo sviluppo di questi dual-core saranno essenzialmente la potenza dissipata e relativa alle dimensioni delle circuiterie interne,per il resto su per giù c'è già l'esperienza smp che sicuramente aiuterà sia amd che intel nello sviluppo dei dual core.

Per la questione dell' HT, io sono daccordo con chi dice che e' + per assicurare la conpatibilita' con windows XP.
Lo Xeon secondo me' l'avra', molto probabilmente verra' indicato che necessita windows server 2003, poi con il longhorn tornera' anche sui desktop.

Originariamente inviato da Spectrum7glr
Piuttosto credo che l'Ht sarà implementato in futuro, giusto per dare la possibilità ad Intel di frazionare le novità e ricavarne il massimo profitto.
Non credo. Il futuro è nei Centrino/Pentium-M, e con queste architetture c'è poco da guadagnare integrando la tecnologia HT, vista l'IPC molto più elevato (e quindi l'efficienza d'utilizzo delle risorse).

Originariamente inviato da P-Boss
ma clock di 3200 vuol dire che i due core sono clokkati a 1600 e entrambi hanno 1 mega di cache o sbaglio??

mah... che io sappia, se c' è una grandezza non ambigua in campo HW, è proprio il clock espresso in hertz (cicli/secondo) : proprio trattandosi di una grandezza fisica, non di un "indice" buttato là dal marketing... :rolleyes:

Originariamente inviato da piffe
Ma la mancata implementazione del HT è dovuta a problemi tecnici causati dai 2 core?

a me pare una scelta abbastanza comprensibile ... il sistema hyperthreading, costituito da un set sdoppiato di registri di stato e program counter, e alcune flag di identificazione del thread a livello di stadi esecutivi in pipeline, e un' ottimizzazione dei context switch, originariamente era nato come "surrogato" di soluzioni sperimentate in altri ambiti già prima del cambio di millennio, ma improponibili in ambito desktop e low level server ...
appunto il multicore , che se non erro fu Alpha a tentare per primo, insieme al controller RAM integrato (per memorie rambus in quel caso)

ora, avere direttamente due processori fisici, nè più nè meno che avere due xeon, (magari un po' di più, se - ipotizzo- si stanno prendendo del tempo per aggiungere e testare delle ottimizzazioni inter - core) sposta il secondo program counter e il secondo set di registri di stato, a un livello superiore...

sui socket utilizzati si sa nulla? cmq sull'ht io credo che sia presente ma disabilitato.. giusto x reintrodurlo dopo dividendo le novità...

Originariamente inviato da mackillers
avevo letto un articolo qui su hwupgrade dove si erà discusso di dual core e molti propendevano per la chache unificata.
effettivamente avendo due cache l2 si è costretti a creare due zone apposite che potrebbero renderne più difficile la realizazzione, poi potrebbe servire un ulteriore controller per verificare la comparabilita dei dati nelle due chache e magari attuare un interscambio.
di contro se i due core dovranno lavorare su treahd di dati diversi in chache con una cache condivisa potrebbero nascere delle interferenze.
Sicuramente dal punto di vista delle prestazioni la cache L2 unificata sarebbe un discreto vantaggio...
Del resto integrare le due cache separate potrebbe portare a semplificare il design...lasciando invariati i protocolli di comunicazione che esistono già nel dual processor per fare la cache inspection...

Commento # 10 di : ulisss pubblicato il 29 Oct 2004, 11:07
beh c'è solo da sperare che i due core non siano basati sull'architettura prescott... altrimenti ancora una volta l'architettura Amd sarebbe preferibile.

Certo che Intel dopo il Northwood non ha sfornato nulla di decente...

Riprendendo l'amico di cui sopra, anche io mi terrò stretto il North @3.2


se lo dici te , io vado fiero del mio prescott 2.8@3,8
che è + prestazionale dell'altro mio 2.8 northwood @3,7

ma appunto. sarà un 64bit nativo o teorico?

Originariamente inviato da Apple80
ma appunto. sarà un 64bit nativo o teorico?

Ti riferisci a EM64T, giusto? Sarà nativo, come AMD64 (sono due nomi per la stessa cosa: x86-64). Se così non fosse, sarebbe un suicidio: le cpu Intel risulterebbero troppo lente rispetto agli A64/FX/Opteron.;)

Ciao

ho trovato questa notizia...che ne pensate?

Intel sta battendo in maniera serrata la strada delle CPU Dual Core e a tal proposito ha parlato con i suoi partners anche circa possibili limitazioni dell'implementazione di tale architettura della concorrente AMD, limitazioni che, stando alle parole del gigante dei semiconduttori, potrebbero dare un grosso vantaggio alla stessa Intel.

Paul Otellini, il presidente di Intel, non ha esposto i dettagli dell'implementazione di Intel ma ha affermato che la società sta terminando l'ottimizzazione del progetto.

I problemi rilevati da Intel circa l'approccio di AMD, continua Otellini, stanno nell'uso del controller di memoria integrato che non permetterebbe di condividere le cache fra i due core, richiedendo per forza la presenza di memorie cache separate.

La CPU Dual Core di Intel, a quanto pare, userà una architettura a memoria cache condivisa che offre prestazioni migliori e non legano Intel ad una sola generazione di memorie. Insomma, a Intel non va proprio giù il dover cambiare la CPU ogni volta che arriva un nuovo standard di memoria.

il link è questo : http://www.dinoxpc.com/News/news.asp?ID_News=8165&What=news

Francamente proprio l'uso di cache separate dovrebbe migliorare le prestazioni, perché i due core possono accedere in maniera indipendente alla loro cache. Una cache condivisa, invece, se non dotata di accesso a porte multiple, può creare un rallentamento delle prestazioni.
Un miglioramento nell'uso della cache unificata, poi, si può avere solamente nel caso in cui le due CPU stanno lavorando a due thread dello stesso processo e che, quindi, condividono parte del codice.
Infine, il fatto che il controller sia integrato può essere un problema tanto quanto il continuo cambio di socket e/o di chipset, che alla fine costringe comunque a buttare la vecchia piastra madre.

In ogni caso un cache unica se ben studiata porta enormi vantaggi nel multithreading...

Secondo me la cache unificata o separata portano benefici o svantaggi a seconda del SO e programmi utilizzati, ad esempio avere la cache unificata e un sistema operatico come DragonFlyBSD che utilizza un sistema di gestione dell'SMP che potrebbe trarre vantaggio dall'avere la cache unificata, mentre in altri SO dove i core sono considerate risorse completamente distinte avere una cache separata forse è una soluzione migliore.

Concordo. D'altra parte, una cache unica per un sistema multithread deve pur sempre fare i conti con l'accesso, che è condiviso, e sul fatto che quasi sempre i dati sono separati per ogni thread, per cui in un sistema con cache separata andrebbero a finire comunque ognuno nella rispettiva cache (e con i vantaggi di un accesso esclusivo per ogni cpu).

Purtroppo la sincronizzazione tra thread va sempre fatta...e nel modello a thread le strutture di sincronizzazione e di scambio dei dati sono condivise...

Infatti, prendendo ad esempio ancora DragonFlyBSD, per evitare di dover svuotare la cache cerca sempre di riassegrare i thread al medesimo core.

Giusto per informazione DragonFlyBSD come progetto è nato propio, tra le altre cose, per sperimentare questo approccio alla gestione del SMP

Originariamente inviato da cionci
Purtroppo la sincronizzazione tra thread va sempre fatta...e nel modello a thread le strutture di sincronizzazione e di scambio dei dati sono condivise...
Bisogna anche vedere quanto dura questa fase di sincronizzazione. Ad esempio, se decido di renderizzare un filmato, l'unica cosa che m'interessa è assegnare metà dei fotogrammi al primo thread e l'altra metà al secondo, dopodiché i due thread lavorano ognuno per i fatti suoi, senza curarsi l'uno dell'altro; soltanto alla fine chi finisce per primo deve "aspettare" l'altro per mostrare il prodotto finito.
Questo modello è abbastanza diffuso, e d'altra parte se non fosse così i vantaggi delle soluzioni SMP andrebbero a farsi benedire: i thread non possono passare troppo a tempo a sincronizzarsi.

Dipende dal modello... Metti che ci sia un programma che non è realizzabile come dici tu...ma potrebbe essere modellizzabile con 4 thread che si sincronizzano fra loro...
Ad esempio:
- il thread B non può partire prima del thread A e sfrutta i dati prodotti dal thread A...
- il thread C non può partire prima del thread A e sfrutta i dati prodotti dal thread A...
- il thread D non può partire prima del thread B e sfrutta i dati prodotti dai thread A, B...
- il thread A, a parte la prima volta, deve aspettare che i thread B e D abbiano prelevato i dati da lui prodottinel ciclo precedente...

Questa situazione può essere anche comune...ovviamente è solo un esempio...situazioni più complesse possono essere anche modellizzate aumentando ancora il numero dei thread...
Mi sembra che ci fosse proprio un software di rendering che realizzava una situazione simili... In pratica l'efficienza su un dual processor aumentava solo con 4 thread...

Una possibile esecuzione sui due processori sarebbe di questo tipo:

P1 P2
A--X
B--C
A--D
B--C
A--D

La sincronizzazione in questo caso è molto forte...eppure non solo si traggono i benefici del dua processori, ma si fa un uso massivo della memoria comune...

Originariamente inviato da cionci
La sincronizzazione in questo caso è molto forte...eppure non solo si traggono i benefici del dua processori, ma si fa un uso massivo della memoria comune...
Se l'ordine è questo:
A--X
B--C
D--A
C--B
A--D
...
D si trova già pronti i dati e la sincronizzazione delle cache è necessaria solo quando C deve leggere i dati di A ;)
Comunque i problemi di sincronizzazione sono gli stessi dei SMP, quindi credo che AMD abbia mantenuto la stessa politica di aggiornamento delle cache.
In genere nelle applicazioni multithread si cerca di ridurre al minimo le fasi di sincronizzazione, perchè ogni volta che un thread aspetta l'altro si sprecano cicli di clock. Adesso non ho idea di che tipo di elaborazione richieda un software di rendering che lavora a 4 fasi con i passi che hai elencato, ma se possibile i programmatori cercheranno di portare la sincronizzazione a livello di blocchi di pixel o di passata di rendering, e quindi percentualmente inciderà molto meno.

Esatto. Comunque è chiaro che tutto dipende dal tipo di algoritmo che si vuole implementare.