AMD werpt een blik in de toekomst

AMD heeft samen met Microsoft een conferentie gehouden in Japan, getiteld AMD & Microsoft Software Developer Conference. Hoewel deze conferentie zich vooral richtte op het ontwikkelen van software voor het Windows 64-bits Extended besturingssysteem, liet AMD ook zien wat er in de toekomst van het bedrijf te verwachten is. Ook lieten HP en IBM hun toekomstplannen met het AMD64-platform zien. Microsoft liet weten dat Windows XP 64-Bit Edition en Windows Server 2003 64-Bit Edition zowel AMD64 als de IA-32e-processors zullen ondersteunen. Een Japanse intermediaire beta-versie zal in juni verschijnen. Een Japanse pre-release beta is voor augustus gepland. De verkoop van beide besturingssystemen zal in het laatste kwartaal van dit jaar van start gaan.

AMD laat weten dat het aftellen voor het 90nm-proces is begonnen. Op een van de getoonde dia's die het presenteerde is dan ook goed te zien dat 2004 het jaar van het 90nm-proces is. De geruchten dat het proces pas in 2005 zou worden gebruikt lijken hiermee dan ook ontkracht. Op diezelfde slide is ook te zien dat AMD van plan is om het 65nm-proces al in 2005 te gaan gebruiken. Waarschijnlijk is dit wel aan het eind van 2005, want eerdere berichten spraken nog over ergens in 2006. AMD bevestig nog maar eens met enkele slides de komst van een dual core-processor. Uit een van deze dia's blijkt dat de dual core-processor uitgerust zal zijn met twee identieke cpu's. Beiden hebben hun eigen L1 en L2-cache geheugen en kunnen via een interne bus met elkaar communiceren. Via deze bus zijn ze ook verbonden met een crossbar-switch waarop de geheugencontroller en de verschillende HyperTransport-bussen zijn aangesloten.

Reacties (32)

[Verwijderd]

Ik vraag me af hoe ze dat doen met de warmte als ze die dual core hebben. Dubbel zoveel transistors, dubbel zoeveel warmte???

[Universal Creations]

dual core is ook dual-oppervlakte! Een groter oppervlak is namelijk makkelijker te koelen, daar zijn ook alle koelblokken op gebasseerd: oppervlakte vergroting.
Natuurlijk zal het beestje wat warmer worden, maar het zal geen probleem vormen voor de huidige koelblokken.

[Cookie]

dual core is ook dual-oppervlakte! Een groter oppervlak is namelijk makkelijker te koelen

Dual core op een kleiner procédé betekent grotere dichtheid aan transistors per vierkante mm, dus meer warmtebronnetjes per vierkante mm en is wellicht lastiger te koelen dan losse CPUs. Zie 90nm Prescott t.o.v. 130nm Northwood, met grotere hoeveelheden transistors per vierkante mm.

[Access]

Vergeet niet dat je in principe minder stroom nodig hebt bij 90nm cpu's dan bij 130nm cpu's. Daardoor zal op dezelfde kloksnelheid de 90nm versie minder warm worden.

Echter is het bij de prescott zo dat deze waarschijnlijk uitgeschakelde features heeft waardoor er veel stroom weglekt. Hierdoor wordt het ding alsnog (te) warm.

[Cookie]

Vergeet niet dat je in principe minder stroom nodig hebt bij 90nm cpu's dan bij 130nm cpu's.

In de praktijk blijkt daar meestal weinig van, omdat ook de prestaties/kloksnelheden worden opgeschroefd.

[Verwijderd]

Vergeet niet dat je in principe minder stroom nodig hebt bij 90nm cpu's dan bij 130nm cpu's. Daardoor zal op dezelfde kloksnelheid de 90nm versie minder warm worden.

Echter is het bij de prescott zo dat deze waarschijnlijk uitgeschakelde features heeft waardoor er veel stroom weglekt. Hierdoor wordt het ding alsnog (te) warm.

Je hebt minder spanning nodig, niet minder stroom. Het lekken van stroom heeft trouwens niks te maken met het uitschakelen van features, dit verminderd de stroom alleen maar. maar met het feit dat de afstand tussen transistoren kleiner wordt, doordat er minder isolerend materiaal is lekt er dus meer stroom. Dit kan je tegenhouden door bv. SOI, maar dit doet intel niet.


P.S. De Prescott wordt een stuk warmer als de northwood bij dezelfde klok.

[silentsnow]

dual core is ook dual-oppervlakte!

Dat is nog maar de vraag. In het bericht staat dat elke CPU (CPU0 en CPU1) eigen L1 en L2 cache krijgt, maar wat gaat er gebeuren met een mogelijke L3 cache, de geheugencontroller en de HyperTransport bussen?

Het lijkt mij goed mogelijk dat een aantal onderdelen toegankelijk zullen zijn voor beide CPU's. Een gedeelde geheugencontroller heeft niet het nadeel van twee aparte geheugencontrollers, namelijk een soort bus-contention. Een gedeelde L3 is misschien iets te vergezocht, maar het geeft wel aan waar je zoal aan moet denken.

Een groter oppervlak is namelijk makkelijker te koelen, daar zijn ook alle koelblokken op gebasseerd: oppervlakte vergroting.

Een groter oppervlak is inderdaad makkelijker te koelen, maar dat is alleen het geval als het grotere oppervlak niet meer warmte afstoot. De kloksnelheid zal hoger zijn, waarschijnlijk komen er bepaalde extensies bij, en het vergeet het 90nm process niet.

We zitten nu op 130nm, een verkleining naar 90nm heeft tot gevolg dat de chip zelf kleiner wordt. Het oppervlak zal dus krimpen terwijl de hitteproductie niet perse omlaag gaat. Het is zaak dat AMD het process snel onder controle krijgt zodat ze het een en ander kan compenseren met volgates.

Natuurlijk zal het beestje wat warmer worden, maar het zal geen probleem vormen voor de huidige koelblokken.

Op langere termijn zullen de huidige koelblokken niet sterk genoeg zijn om CPU's te koelen. BTX is bijvoorbeeld een soort hulpmiddel van het koelblok, iets wat AMD net zoals Intel in kan zetten als de warmteafstoot van de dual-core processoren tegen blijkt te vallen. Daarnaast zie ik toch steeds meer radiator type koelblokken, dat neem ik als een slecht teken.

[Verwijderd]

Een gedeelde geheugencontroller heeft niet het nadeel van twee aparte geheugencontrollers, namelijk een soort bus-contention.

nadeel van de dual core amd, wat blijkt uit het dual core dataflow plaatje in het tweakers artikel, is het sharen van de memorycontroller; beide cores gebruiken dezelfde memorycontroller wat een bottleneck op kan leveren.

vergelijk een dual processor opteron moederbord. beide processoren hebben een eigen memorycontroller en daardoor kan het NUMA voordeel aangesproken worden: dubbele memory bandwidth.

dual core moet vooral gezien worden als een kostenverlagende ingreep, niet zo zeer een performance verbeterende ingreep als je het vergelijkt met twee losse opteron processoren.

edit:
@silentsnow

is het zo ingewikkeld? het feit dat de dualcore maar 1 memorycontroller heeft spreekt toch boekdelen?

voordeel van de geintegreerde memorycontroller tov xeon was juist het NUMA voordeel. de dualcore opteron lijkt juist veel op een dual xeon qua memoryaccess; er is 1 bottleneck waar beide cores doorheen moeten om bij het geheugen te komen: de single on die memorycontroller.

ik zal het proberen te illustreren met voorbeeldje adhv dual opteron mobo's.

er zijn grofweg twee opteron dual mobo types :

1) beide opteron met eigen DIMM's, dus 2 DIMM banken, dus elke opteron heeft zijn eigen geheugen en beide memorycontrollers worden volledig benut. de effectieve geheugen bandbreedte is 2xDDR400, in NUMA dat wel.

2) 1 opteron met eigen DIMM's, dus 1 DIMM bank, dus beide opterons delen het geheugen en slechts een memorycontroller wordt volledig benut de andere volledig ongebruikt gelaten.

mobo type 1 is duurder maar performance wise beter dan dan de goedkopere mobo 2. de opteron dual core lijkt het meest op mobo 2; beide cores delen een memorycontroller en DIMM geheugenbank.

om deze reden schaar ik de dual core opteron dan ook onder de vergoedkopering noemer van server oplossingen en zie ik niet zo zeer performancevoordelen tov dual opteron systemen.

[silentsnow]

beide cores gebruiken dezelfde memorycontroller wat een bottleneck op kan leveren.

Ik vraag me af hoe dat een bottleneck op kan leveren. Als de geheugencontroller goed in elkaar zit, dan zou het niet uit moeten maken waar de requests vandaan komen zou ik denken. CPU0 en CPU1 zijn weliswaar identiek, maar de geheugencontroller heeft daar verder niets mee te maken. AMD heeft de K8 architectuur immers ontworpen met dual-core (K9?) in het achterhoofd.

vergelijk een dual processor opteron moederbord. beide processoren hebben een eigen memorycontroller

Ik doelde eigenlijk op de gedachte dat de processor (het geheel, dus CPU0 en CPU1 samen) slecht één set geheugenbanken aan kan spreken. In dat geval zou één geheugencontroller logisch zijn, want je hebt slechte één set geheugenbanken.

Twee aparte geheugencontrollers is logisch als elke core dan ook beschikking krijgt over een eigen set geheugenbanken, iets wat waarschijnlijk niet het geval zal zijn. Een tweetal dual-core processoren zouden dan beschikking krijgen over vier sets geheugenbanken.

Als dit dual-core monster slechts over één set geheugenbanken beschikking krijgt, dan zou een opstelling met twee geheugencontroller tot bus-contentie leiden.

[Roflmao]

Wat ik me afvraag is of dual core dus gewoon zonder software gebruik kan maken van zijn power, en niet zoals een dual cpu pas bij applicaties die dual cpu ondersteunen, snel word...

En het stroomverbruik, en hoe heet het ding word... Dat is ook belangrijk.

[Universal Creations]

Dual CPU is ook zonder speciale software sneller. Onder windows is het multitasken een genot. Nooit meer wachten op applicaties omdat die heel je cpu opslurpen, want de tweede cpu doet dan het tweede proces. Ik maak er nu sinds een jaar gebruik van en het werkt fantastisch.

[arjankoole]

Dual CPU is ook zonder speciale software sneller....

je argument klopt niet helemaal, welliswaar klopt het dat jij een serieuse performance winst merkt bij 2 CPU's in je computer, maar dat komt voornamelijk doordat windows met 2 CPU's om kan gaan. De windows kernel is standaard zo gecompileerd, dat hij een tweede CPU detecteerd en daar gebruik van maakt, hetzelfde verhaal gaat op voor HyperThreading. (1 physical cpu, 2 logical cpu's).

Onder de opensource UN*X varianten merk je dat iets beter, als je een tweede CPU in je machine hebt zitten moet je een SMP kernel bouwen en instaleren voor je er echt plezier van hebt. Vroeger was dat zelfs zo met CPU's die HTT capaciteiten haddden, maar ik geloof dat in elk geval Linux en FreeBSD daar standaard al goed mee omgaan inmiddels. (je moet onder BSD alleen een sysctl loslaten, maar da's een ander verhaal)

[_Thanatos_]

Wat arjankoole probeert te zeggen (met veel te moeilijke woorden) is dat 1 single-thread applicatie niet sneller gaat, maar 2 gaan samen wel sneller.

Als je nou ook nog es SMT in beide cores hebt

[stunn0r]

het lijkt me niet.. ik denk dat je het net als met smp een thread door maar 1 cpu tegelijk kan af laten handelen waardoor je meerdere actieve threads nodig hebt om er profijt van te hebben

[Verwijderd]

Vind het wel opvallend dat AMD hier weer beweerd naar 90nm te gaan terwijl vorige week er nog berichten waren dat er nog teveel problemen waren met het proces.

Zijn er eigenlijk al fabrikanten die wel al gebruik maken van 90nm-technologie ?

[Verwijderd]

Vind het wel opvallend dat AMD hier weer beweert naar 90nm te gaan terwijl vorige week er nog berichten waren dat er nog teveel problemen waren met het proces.
.....

Ik denk dat je die berichtgeving met een flinke korrel zout moet nemen. En als ze er al zijn dan zou het voor AMD nog niet heel veel uit maken, aangezien ze het met het huidige procédé nog wel een half jaar uithouden. Ze zijn in ieder geval nog niet zo afhankelijk van het 90 nm procédé als Intel, omdat ze nog wel ruimte hebben voor de introductie van snellere producten. Dit is ook hét grote voordeel van AMD momenteel; ze hebben langer de tijd om het nieuwe procédé te perfectioneren, iets wat Intel klaarblijkelijk niet had. Intel is ook al hard op weg de Prescott te verbeteren, maar de introductie viel eigenlijk te vroeg uit. Ik denk ook dat met de hulp van IBM en hun SOI technieken AMD best een goed product gaat neerzetten (maar dat is koffiedik kijken natuurlijk).

[Verwijderd]

Deze berichten stonden op de site van Mike Magee, intel-medewerker...de site is anti-amd.

Misschien dat het je niet direct opvalt als je de site bezoekt. Bezoek je de site langer dan merk je dat deze intel-site wel erg toevallige foute berichten post e.d.

[RobT]

Yeah right.

Not!

Lees de berichtgeving over bv AMD64 maar na, en reacties daarop, daar zal je in zien waarom Mike Magee en the Inq vaak genoeg verweten worden Intel haters te zijn.

The Inq doet gewoon aan spraakmakend reporteren met veel roddels ertussen, voor wie goed leest is het altijd duidelijk wat uitgelekte info is en wat nog onzeker/roddel.

[Access]

Intel's Prescott Pentium 4 wordt geproduceerd door middel van het 90nm proces.

[Mannekino]

Persoonlijk vind ik die constante vertraging wel lastig worden. Ik had gehoopt dat de 64-bits versie van Windows Server 2003 in ieder geval aan het einde van die kwartaal beschikbaar zou zijn. Ik heb inmiddels een Opteron server gekocht en draai hier nu de 32-bits versie op van Server 2003, hoewel dit erg goed draait kan ik eigenlijk niet wachten om te kijken hoe de 64-bit versie zal presteren.

Ik heb de beta versie wel geprobeerd, echter hier missen nog teveel zaken in, zoals een simpele ODBC connector waar ik gebruik van maak zit er niet in en die valt ook niet te installeren. Erg jammer, al mijn hardware op de SATA-controller na werd wel netjes herkend en automatisch geïnstalleerd. De SATA drivers kon ik van de Silicon Image site downloaden, die hadden al een non-beta versie uit voor de 3114 RAID-controller.

Nog maar ff wachten dus .

[Verwijderd]

Ik heb inmiddels een Opteron server gekocht en draai hier nu de 32-bits versie op van Server 2003, hoewel dit erg goed draait kan ik eigenlijk niet wachten om te kijken hoe de 64-bit versie zal presteren.

amd geeft zelf aan dat er een prestatiewinst van ongeveer 25% te verwachten is. een linux distributeur (mandrake) geeft dit zelf ook aan in een gemeenschappelijk persbericht met amd :

"The Mandrake Corporate Server 2.1 for the AMD Opteron processor is the result of an intensive one-year collaboration with AMD to deliver a comprehensive, full-featured and powerful Linux operating system for this exciting new platform. Sold with an extended support offering, the Mandrake Corporate Server 2.1 will meet the strong demand for high-availability servers running on this new generation of AMD64 technology,? said Jacques Le Marois, President of MandrakeSoft.

When compared to the same product running on a traditional 32-bit architecture, the Corporate Server 2.1 for AMD Opteron processors can offer an average performance gain of 25% as a result of AMD64 architecture.

http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_ 8933~70027,00.html

64 bits betent dus niet 2x zo snel als 32 bits, maar 25% sneller is toch leuk meegenomen.

[Chello200]

Je vergeet dat AMD heeft gezegd dat de 90nm een nadeel met zich meebrengt. Doordat de 90nm wordt toegepast kan er bij hogere frequentie fouten optreden in de L2. Hierdoor wilt AMD de L2 cache op 50% van de cpu snelheid laten draaien zodat de ghz'en kan toenemen. Wordt een beetje Intel-ish

[Countess]

de cache is meestal het eerste gebied waar problemen optreden bij hoge frequenties welk procidee er ook word gebruikt.

AMD wil zijn cache op 50% van de clock snelheid laten draaien omdat ze dan EN meer werkende cores kunnen maken EN ze makelijker hoger geclockte cores kunnen uitbrengen.

aangezien de athlon64 zijn l2 niet zo hard nodig lijkt te hebben, zou AMD hier nog best wel eens iets heel slims aan het doen kunnen zijn.
maar het verlagen van de l2 clock verhoog je wel ook de latency daarvan, en daar houd hij weer minder van.
ik moet dus nog fff zien hoe het uit pakt, al verwacht ik geen enorme preformance drop hierdoor.

[TGEN]

Hou wel in je achterhoofd dat met de huidige core designs L2 cache op dezelfde snelheid als de core inefficient is. Er wordt meen ik maar zo'n 40% gebruik gemaakt van de aanwezige bandbreedte.

[familyman]

Volgens mij is het simpel, als je naar het plaatje boven kijkt, zie je in het witte deel aan de linkerkant twee ingaande pijlen van de cores. Naar buiten toe zie je vijf lijnen, de HTT en de Geheugeninterface. Deze worden dus gedeeld.

Verder zie je TWEE blokken l2 cache. Het plaatje is onduidelijk, maar er staat volgens mij 1mb bij. Dan zie je twee keer twee l1 cache (data + instructies). Er staat ook een wit lijntje bij, maar dat kan ik niet lezen.

Dus van MINDER transistor lijkt me duidelijk geen sprake. Eerder HEEL VEEL meer en dan moet je wel naar een kleiner procedé. Iemand met breedband kan dat wel even uitzoeken, maar ik gok dat het ongeveer neer gaat komen op evenveel Si van 130 -> 65 = 2x keer zo klein, bijna twee volledige processoren en wat maatregelen om storing tegen te gaan en die onduidelijke witte lijntjes hebben misschien ook wel een functie

Wat ik nu zo opvallend vind is de opmerking aan de rechterkant, "The dual processor interface exists in the currente K8 core layout". Dat betekent dat misschien dat de AMD nu al prima getweaket zou kunnen worden om dual te draaien?

Me dunkt dat de interface nu precies de essentie is van SMP?

[LaMoS]

Je vergeet dat het over oppervlaktes gaat (2D dus) en simpelweg de lengte van de transistoren, duuuuus:
130^2 = 16900 , 90^2 = 8100 en 65^2 = 4225. Per stap worden de transistoren dus ongeveer 2x zo klein. AMD heeft al eerder laten weten dat ze met dual-core processoren gingen beginnen vanaf het 90 nm proces, dan blijft de die-grootte ongeveer even groot, een verlaagde warmteproductie dankzij SOI en het 90 nm proces. Ze zullen wel een flink stuk warmer worden als de huidige Opterons, maar waarschijnlijk wel minder als simpelweg het dubbele.

Het AMD ontwerp van hun dual processor is een heel simpel dankzij de HyperTransport bussen. Ze zetten gewoon 2 cores naast elkaar, elk met hun eigen L2 cache (veeel simpeler, en zo besparen ze op ontwikkelkosten), die samen aan een HT switch hangen voor onderlinge communicatie en met andere delen van de computer.

[cbmjeeck]

Ik kan het helemaal mis hebben maar is dit iets vergelijkbaars met wat intel een tiental jaar terug probeerde met de 486SX naar 486 DX upgrade?

[Zonique]

Dat was niet echt een Dual core. Op dat moment werd the co-processor, die normaal gesproken op een aparte chip zat in the processor geintegreerd. M.a.w.: de DX kreeg een aantal extra taken, maar had nog steeds geen paralelle cores.

<beetje off-topic>Btw... Het vreemde aan het verhaal was dat de 486SX deze co-processor ook aan boord had, maar dat die uitgeschakeld werd. Het vreemde was dat terwijl het productproces dus eigenlijk duurder was (het ding werd speciaal uitgezet), waren the prijzen van de SX lager. </beetje off-topic>

[Verwijderd]

Volgens mij heeft bij dat SX naar DX gebeuren AMD de meeste garen gesponnnen...Waarschijnlijk was het zelfs de eerste keer dat AMD z'n tanden liet zien in de processor markt.
Ach nee..dat was eerder terug...de 386...zucht!(Geheel offtopic)

[KaMiKaZe]

AMD werpt een blik in de toekomst

toekomst werpt blik weer terug

[Verwijderd]

Ik zit me het e.e.a. af te vragen, ik moet toegeven dat kwa hardware ik nog lang niet alles begrijp. Maar is in combinatie met L3 cache een single mmc niet beter, vooral als de mmc een blitteractige functie heeft om data uit het gewone ram op te halen. (plaatst grote blokken memory in de L3 en evt weer terug) Die L3 hangt aan een hyperthreading-pijp aan de andere chaches dus daar zou geen botleneck moeten mogen zitten. Op dat moment lijkt het me niet echt een nadeel, alleen als de applicaties grote hoeveelheden data verwerken zal single mmc en shared memory een echt nadeel zijn voor de rest zal het prestatieverlies niet al te groot zijn in vergelijking tot een dualmmc. Als voordeel voor de consument komt hierbij dat hij geen dubbel ram hoeft aan te schaffen, ik denk dat dit effect heel belangrijk zal zijn voor de verkoop aan de clueless consumer (op het moment dat de proc afglijdt naar de standard-clone markt). Het kan hem/haar toch een goede 100 euro schelen. Voor high-end gebruik, zal het wellicht een inpunt zijn, maar er zijn al zoveel clustermogelijkheden voor distributed computing met soms tamelijk kleine applicaties diegewoon in de cache draaien dat ook voor deze markt de AMD procs heel interessant kunnen worden.

Dus misschien is het vreemd, maar in de ogen van deze leek, lijkt AMD toch het. e.e.a. te hebben bedacht dat ons flink wat bang-for-the-buck zou kunnen opleveren, maatr tegen te tijd dat het in mijn budget zal komen (hier in portugal is alles stervens duur anyway) zal er meer dan genoeg over geschreven zijn en allang bekend zijn of het een goede keus was van AMD.

[Verwijderd]

Klonk!