Willamette met 'variable frequency units'?

JC, bekend van het informatieve JC's News'n'Links, heeft een interessante posting geplaatst in een Slashdot thread over de Intel Northwood (waarvan inmiddels bekend is dat het de codenaam is voor mobile Willamette):

The Willamette is Intel's first new core since the P6 back in the mid 90s, which found itself inside the Pentium Pro, II, III, and Celeron. Rumours and admissions declare the below to be its likely improvements:

A deeper (or smoother, at least) instruction pipeline for stronger frequency ramping

Added execution pipelines and functional units (eg, allowing it to issue more instructions per cycle)

A "trace cache", to optimize the order in which instructions are fed into the pipelines (I admit, I could be screwing up this particular explanation) variable frequency units -- this one's a leap of faith, but tentatively according to some sources, different parts of the cpu will be clocked at different rates. A 2GHz Willamette chip might have a 2GHz integer unit, a 1.7GHz fpu, and a 1.5GHz SSE unit (mind you, this is a speculative example, with numbers picked out of the air)

An improved motherboard bus, capable of 200MT/s (100MHz, double pumped) but also 128-bit, twice the width of the Athlon's EV-6, allowing for twice the peak bandwidth. Also, quadruple pumped (400MT/s) for the later server version, codenamed Foster. On the other hand, it will still be a shared bus, which is supposedly less "clean" than a point to point protocol that the Athlon uses, meaning that high-way SMP may get lots of collisions and degraded performance on Willamette.

Het was al bekend dat Willamette gebruik zou maken van een 'trace cache' en een 128-bit double data rate bus. Dat gedeelte over variabele frequency units is nieuw voor mij, klinkt erg interessant.

Reacties (8)

Dit is natuurlijk een 'dream come true' voor de afdeling marketing van Intel: je kan het verkopen als een 3GHz-processor terwijl er in feite maar een klein stukje op die snelheid loopt, terwijl de rest op de helft of een kwart van die snelheid loopt.

Dat lijkt mij alleen maar mogelijk (FSB verhogen)
als er in de CPU vaste multipliers zijn ingesteld.
Dit omdat een aantal delen op verschillende frequenties lopen.
Wat ook een mogelijkheid is (lijkt me cooler) is dat de verhoudingen tussen die snelheden door de gebruiker (al dan niet door Intel gewenst ) veranderd kunnen worden (bijv vanuit 't Bios)
Het grote voordeel is dat bij te ver clocken alleen je FPU bijv. crashed. kun je (misschien) nog wel gewoon je compu netjes afsluiten , of de waarden weer t'rug zetten.

Maar als op 't MB ineens met deze Wil. cpu verschillende busfreq's krijgen moet de bijbehorende chipset ineens een heeeeeel stuk complexer worden, om te voorkomen dat transacties "een clock-cycle missen" (gaat 'ie bijv 1 MHz hoger, wordt 'ie ineens 20% langzamer)

Maar opzich een interessante CPU (vooral het 2GHz gedeelte)

Da's niet lekker overklokken dus

Dan zou je nl. de snelheden van die verschillende delen (in je BIOS?) moeten kunnen instellen...

volgens mij kan je nog steed gewoon de FSB verhogen en dan gaan alle proc snelheden mee.. klinkt mij wel logisch... niet?

Waarom zouden ze dat eigenlijk doen? Is dat om de yield zo hoog mogelijk te krijgen? Of is het energiebesparend voor de notebookjes?

Iemand mag het mij proberen uit te leggen, want ik zie de logica er niet van in...

Als reactie op "TheWizard":

Het FPU-gedeelte bijv. is een stuk gecompliceerder dan het Integer-schuif-werk.
Als alles op dezelfde freq. loopt, kan het zijn dat bijv. het integer gedeelte nog niet op z'n max. loopt, terwijl het FPU-gedeelte (wat vaker tussenresultaten in registers moet opslaan) 't al niet meer trekt.

Dus waarsch is de CPU al dusdanig getweaked, dat 'ie niet heel veel meer overclocked kan worden.

TD-er :
Maar nu lopen de verschillende onderdelen ook al op dezelfde snelheid en nu hebben ze er ook geen problemen mee (nou ja, de Athlon in ieder geval niet, maar die is ook totaal vernieuwd).

Het FPU gedeelte is een stuk gecompliceerder dan het Integer gedeelte, dus moet het FPU gedeelte sneller gaan lopen om gelijk te gaan lopen met het Integer gedeelte, dus als de FPU op 1,6 wordt geklokt, wordt de Integer altijd lager geklokt. Dus je werkt altijd ondergeklokt... hmmm, mooi is dat
Ik denk (weet haast wel zeker) dat Intel zijn chipset zo instelt dat het tweaken van de onderlinge onderdelen onmogelijk wordt...

Als het aan Inteelt lag viel er helemaal nix over te clocken....maar het is aan ons tweakers om daar weer wayzz-around te vinden
En trouwens, krijg je met dit systeem dus niet gewoon wachtrijen in je sjip? Datapakketje is klaar voor volgende process maar dat is nog bezig met het vorige pakketje e.d.??
Dan moeten ze dat dus weer naar het geheugen leiden ofzo....huh, vaag verhaal hoor, ik kan me niet voorstellen dat dit de performance ten goede komt....