Uitleg en details over AMD's dual-coreprocessorontwerp

In een presentatie heeft AMD wat meer informatie gegeven over de aankomende dual-coreprocessors. Een aantal dingen in de presentatie waren al bekend. Zoals het gegeven dat twee AMD64-cores met behulp van een System Request Interface (SRI) met de geheugencontroller en drie HyperTransport-bussen worden verbonden. Wat er echter niet bekend was, is dat de aansluiting voor de tweede Opteron-core al aanwezig is op de SRI van de huidige Opteron-processors.

Sockets en cores

De dual-coreprocessor zal compatibel zijn met de huidige sockets voor AMD64-processors. Dit brengt echter een probleem met zich mee. Hoe weet de software over hoeveel processors deze beschikking heeft. AMD heeft hier uiteraard een oplossing voor bedacht die met zowel bestaande als toekomstige software werkt. Toekomstige software kan via een nieuwe CPUID-functie opvragen of er een dual-coreprocessor of een single-coreprocessor in het socket zit. Reeds bestaande software weet echter niet van het bestaan van deze nieuwe functie af. Deze kan alleen onderscheid maken tussen single-processor (single-core), SMP en SMT (HyperThreading). De oplossing hiervoor is dan ook eenvoudig. Als de software aan de dual-coreprocessor vraagt, via een CPUID-functie, of deze SMT ondersteunt, dan antwoordt deze gewoon met ja. AMD heeft dit al in de praktijk getest en geen grote problemen gevonden.

Instructieset

AMD heeft dertien nieuwe SSE-instructies aan de AMD64-core toegevoegd waardoor deze compatibel is met SSE3. Verder is er een aantal verbeteringen in de huidige instructieset aangebracht. Hierbij gaat het vooral om IA32-instructies die enkele verbeteringen hebben meegekregen zodat deze ook in 64-bit mode gebruikt kunnen worden. Daarnaast zijn er ook nog enkele nieuwe instructies toegevoegd. Details over deze verbeteringen en uitbreidingen zijn uiteraard terug te vinden in de presentatie van AMD.

Reacties (54)

[nwagenaar]

Ik moet zeggen dat AMD best wel open en vooruitstrevend is op gebied van hun verdere ontwikkelingen aan CPU R&D (ok, eigenlijk is het al ontwikkeling maar je begrijpt wat ik bedoel).

Ik zet alleen wat vraagtekens bij de volgende tekst:

De dual-coreprocessor zal compatibel zijn met de huidige sockets voor AMD64-processors. Dit brengt echter een probleem met zich mee.

Dan komt mijn eerste vraag, zal AMD hun dual-core CPU's ook uitbrengen voor het S754 platform of blijft dit behouden voor het S939 platform? Het logisch dat AMD zal kiezen voor alleen een S939 platform aangezien zij hebben aangegeven dat dit het platform zal worden voor eventuele verdere ontwikkelingen binnen het AMD64 gebeuren. Maar uit de tekst kan ik niet opmerken of dit inderdaad het geval is.

Verder, uit deze tekst kan ik lezen dat er gebruik gemaakt gaat worden van SMT wanneer een programma hierom vraagt (in geval het programma niet het dual-core principe ondersteund). In deze vorm van HyperThreading "emulatie" kun je volgens mij niet de volledige instructieset gebruiken van de dual-core, mits de mensen van AMD dit kunnen oplossen door optimalisaties binnen de core. Ik ben benieuwd in hoeverre dit de prestaties beinvloedt van het dual-core principe (want dual-core != SMT).

In ieder geval ben ik blij met de toevoeging van SSE3 zodat specifieke software producten betere prestaties zouden kunnen laten zien. Voornamelijk encoding pakketten schijnen hier gebruik van te maken (en Intel is nog steeds heer en meester op gebied van encoding) waardoor AMD ook op dit gebied marktaandeel zou kunnen verkrijgen.

AMD, keep up the good work!

@ThaMind

Zoals jij het verwoord bedoelde ik het eigenlijk ook alleen ik verwoorde het dus brak. Ik bedoelde inderdaad dat wanneer een programma gebruik wil maken van het dual-core principe en het ondersteund de AMD dual-core technologie niet (met andere woorden, het programma is nog niet voorzien van deze optimalisaties) dan zal de CPU aangeven dat het SMT ondersteund. Maar zoals jij het ook al zegt. Door keuzes tijdens de implementatie van HyperThreading kan een programma nooit volledig gebruik maken van het dual-core principe en de dual-core instructieset. Daarom ben ik ook benieuwd hoe AMD dit gaat oplossen. Want het zou toch mooi zijn dat AMD's HyperThreading "emulatie" beter presteerd dan de Intel's originele HyperThreading implementatie (zeker nu omdat AMD heeft aangegeven dat de concurrent voor de AMD64 gelijk is aan de huidige en toekomstige Pentium4 CPU's. Bron : DealerInfo)?

[silentsnow]

Dan komt mijn eerste vraag, zal AMD hun dual-core CPU's ook uitbrengen voor het S754 platform of blijft dit behouden voor het S939 platform?

De beperkingen van Socket 754 wegen te zwaar om Dual Core Socket 754 processoren te maken en verkopen. Een Socket 754 heeft per definitie slechts single channel geheugenkanalen, en de HyperTransport (HT) link werkt op 800MHz. Socket 939, daarentegen, kan gebruik maken van dual channel geheugenkanalen, en een 1000MHz HyperTransport link. Ik kan mij goed voorstellen dat een Dual Core processor meer eisen stelt aan de hardware (qua bandbreedte) waardoor Socket 754 eigenlijk geen optie is voor Dual Core.

Daarnaast geeft RuL0R hierboven al aan dat Dual Core een implementatie is welke alleen in bepaalde segmenten gebruikt zal worden. In de AMD Roadmap is te zien dat voorlopig (de komende 18 maanden) Dual Core tot de mid/high segmenten zal toebehoren. Waarschijnlijk is de Sempron serie de laatste die je op de Socket 754 moederbordje kwijt kan, al is het mogelijk dat toekomstige Sempron processoren een ietswat verbeterde architectuur krijgen (verbeterde Cool & Quiet bijvoorbeeld).

In ieder geval ben ik blij met de toevoeging van SSE3 zodat specifieke software producten betere prestaties zouden kunnen laten zien.

SSE3, aka Prescott New Instructions, is een collectie van 13 instructies, waarvan 2 betrekking hebben op HyperThreading. Je zal dan ook 11 van de 13 SSE3 instructies terug zien in deze nieuwe Athlon's, omdat de overige 2 totaal geen functie hebben in de K8 architectuur, gezien de absentie van HyperThreading Technologie(HTT).

Monitor en Mwait hebben betrekking op de verschillende threads in het HyperThreading model. Deze twee instructies zijn van belang omdat in Intel's HyperThreading processoren, de twee virtuele cores beschikking hebben over slechts één collectie van execution units. In AMD's Dual Core model is dat anders, aangezien elke processor beschikking heeft over eigen hardware. De noodzaak van Monitor en Mwait vervalt, omdat deze twee instructies betrekking hebben tot het delen van hardware componenten tussen de lopende threads.

Ik bedoelde inderdaad dat wanneer een programma gebruik wil maken van het dual-core principe en het ondersteund de AMD dual-core technologie niet (met andere woorden, het programma is nog niet voorzien van deze optimalisaties) dan zal de CPU aangeven dat het SMT ondersteund.

De optimalizatie voor AMD's Dual Core (bepaalde multi-core regels) en HyperThreading zijn niet hetzelfde. Om gebruik te maken van beide cores in AMD's Dual Core model, is het noodzakelijk dat de software ondersteuning heeft over ten minste HyperThreading. Als de software hier bovenop over de specifieke optimalizaties voor AMD's Dual Core beschikt, dan kan de software middels de opgewaardeerde CPUID Feature bit specifieke gegevens achterhalen van de processor, en zo een veel beter rendement behalen in vergelijking tot enkel HyperThreading.

[Verwijderd]

Een Socket 754 heeft per definitie slechts single channel geheugenkanalen, en de HyperTransport (HT) link werkt op 800MHz. Socket 939, daarentegen, kan gebruik maken van dual channel geheugenkanalen, en een 1000MHz HyperTransport link. Ik kan mij goed voorstellen dat een Dual Core processor meer eisen stelt aan de hardware (qua bandbreedte) waardoor Socket 754 eigenlijk geen optie is voor Dual Core.

Een S754 Athlon64 en een S939 Athlon64FX met dezelfde clock presteren ongeveer even goed (slechts een paar procent verschil)
Hieruit zou je kunnen concluderen dan single channel genoeg is voor 1 core (hoewel dual toch net iets sneller is), maar voor 2 cores heb je inderdaad dual channel nodig.

mbt. SSE3/PNI:
SSE3 zijn 11 instructies, SSE3 + 2 HTT instructies = PNI. Ik snap het niet helemaal dat daarom in dit artikel over 13 instructies wordt gesproken.

[Ralph Smeets]

Verder, uit deze tekst kan ik lezen dat er gebruik gemaakt gaat worden van SMT wanneer een programma hierom vraagt (in geval het programma niet het dual-core principe ondersteund). In deze vorm van HyperThreading "emulatie" kun je volgens mij niet de volledige instructieset gebruiken van de dual-core, mits de mensen van AMD dit kunnen oplossen door optimalisaties binnen de core. Ik ben benieuwd in hoeverre dit de prestaties beinvloedt van het dual-core principe (want dual-core != SMT).

Dat klopt helemaal wat je daar zegt en dat geeft AMD dan ook in zijn presentatie al aan. Je moet het dan ook zien als een mogelijkheid om toch die tweede core te benutten als er met oude software wordt gewerkt die wel met HyperThreading overweg kan. Zo ziet AMD het tenminste. Software moet je hier trouwens zien als in besturingssysteem die de verschillende threads over twee logische cpu's moet verdelen. Hierbij houdt de scheduler van het OS rekening met het feit dat een logische cpu niet alle instructies kan uitvoeren omdat er executionunits en registers moeten worden gedeeld.

[Onno]

Hierbij houdt de scheduler van het OS rekening met het feit dat een logische cpu niet alle instructies kan uitvoeren omdat er executionunits en registers moeten worden gedeeld.

De scheduler van je OS heeft geen flauw idee wat voor instructies je threads gebruiken. De enige manier om daarachter te komen is instructie voor instructie bekijken, en dat levert een groter performance verlies dan winst op.

Waar een scheduler bijvoorbeeld wel rekening mee kan houden is dat het gunstiger is om een thread op een fysiek andere processor te schedulen dan op eentje waarop al een thread loopt. Maar dat heeft op zich weinig meer te maken met het feit dat niet alle instructies parrallel uitgevoerd kunnen worden, ook bij 'HTT' waarbij dat wel zo zou zijn zou het gebruiken van een andere processor waarschijnlijk gunstiger zijn vanwege de grotere geheugenbandbreedte. (alhoewel je caching minder efficient wordt als je threads van hetzelfde programma over meerdere cpu's uitsmeert, maar dat risico moet je als scheduler dan maar nemen, totdat je een betere tactiek leert )

[Onno]

Dat hoeft natuurlijk maar een keer tijdens het laden te gebeuren, dus dat zou op zicht niet zo'n probleem zijn.

Als jij van tevoren de exacte loop van het programma kunt voorspellen..

[Olaf van der Spek]

De enige manier om daarachter te komen is instructie voor instructie bekijken, en dat levert een groter performance verlies dan winst op.

Dat hoeft natuurlijk maar een keer tijdens het laden te gebeuren, dus dat zou op zicht niet zo'n probleem zijn.

[Verwijderd]

Tijdens het laden is niet te voorspellen welke threads het vaakst zullen worden uitgevoerd, welke threads de meeste rekentijd kosten, en welke threads afhankelijk zijn van de resultaten van andere threads.

Da's dus wel een probleem.

[Niles]

uit deze tekst kan ik lezen dat er gebruik gemaakt gaat worden van SMT wanneer een programma hierom vraagt (in geval het programma niet het dual-core principe ondersteund). In deze vorm van HyperThreading "emulatie" kun je volgens mij niet de volledige instructieset gebruiken van de dual-core, mits de mensen van AMD dit kunnen oplossen door optimalisaties binnen de core.

Dit staat niet in de tekst, wat in de tekst staat is dat de software moet regelen of het beide cores gaat gebruiken ja of nee, en aangezien je dat in zowat alle gevallen wel wilt, zal dus de software aangepast moeten worden. Aangezien AMD inziet dat dat veel tijd gaat kosten (net als het nu veel tijd kost eerdat alles 64bit is) hebben ze een oplossing: Als het programma SMT ondersteund (waar al wel een hoop software voor is dankzij Intel's Hyperthreading) dan wordt automatisch de 2e core ingeschakeld, waardoor dat wat normaal door de visuele core gedaan wordt, nu door een fisieke core gedaan wordt.

Echter ik herinner met iets dat die visuele core van Intel lang niet alle instructies ed ondersteund, das dan toch weer wel een probleem, want dan wordt de 2e core dus niet volledig gebruikt. En daarbij: De HT software is gebaseerd op Intel's processor, op geen enkele manier is met AMD rekening gehouden...

Er zitten denk ik nog wel wat haken en ogen aan, ben benieuwd of ze het perfect krijgen.

[Onno]

Echter ik herinner met iets dat die visuele core van Intel lang niet alle instructies ed ondersteund, das dan toch weer wel een probleem, want dan wordt de 2e core dus niet volledig gebruikt.

Naar de software toe lijk je bij HT gewoon twee cpu's te hebben, en alle instructies kunnen dan ook gewoon uitgevoerd worden. Alleen zal de ene virtuele cpu vaak moeten wachten totdat de andere klaar is met een bepaalde instructie, omdat het niet echt twee cpu's zijn. Maar daar merk je als software verder niets van, en je hoeft er ook geen rekening mee te houden. (al kan het snelheidswinst opleveren als je dat wel doet)

[Verwijderd]

waardoor dat wat normaal door de visuele core gedaan wordt, nu door een fisieke core gedaan wordt.

virtueel, niet visueel, tenzij je de heatspreader en het bovenste laagje keramisch spul van de core verwijderd, dan is'ie visueel.

edit: typo

[Verwijderd]

Hee onno, jij hier? Lang niet gezien

cpu A zal alleen wachten (maakt ff niet uit welke A is) als cpu B de specifieke instructieunit in gebruik heeft die A nodig heeft. Dit gebeurt alleen bij geoptimaliseerde software aangezien de rest geen rekening houdt met hoe de P4 zijn instructies afhandelt.

Gevolg is dat met name niet-geoptimaliseerde software sneller zal gaan, omdat deze instructies met afhankelijkheden en dergelijke heeft.

Bij geoptimaliseerde software zullen allebei de threads bijna volledige aanspraak doen op de rekenunits en zullen ze dus allebei op ongeveer de helft van de snelheid draaien. Hier hou je dan nog 5-10% snelheidswinst over omdat sommige afhankelijkheden niet er uit te halen zjin, en de ene processor een jump af zal handelen terwijl de ander een rekenproces doet.

Ter vergelijking, de P4 heeft 4 instructiepaden, 1 voor geheugenbenaderingsinstructies, 1 voor complexe instructies (zoals MMX,SSE en zo voorts) en twee ALU's voor wiskundige en logische instructies. Hiervan is 1 niet helemaal volledig (ik geloof dat MUL en DIV e.d. ontbraken) zodat je voor de meeste instructies 1 pad hebt.

Beide ALU's werken wel op dubbele snelheid, zodat ze twee instructies per cycle aankunnen (en daarmee kun je op een 4GHZ processor dus 16 miljard rekenkundige instructies per seconde aan, in theorie). Dat deze 16-miljard instructies echt bijna nooit gehaald worden blijkt wel uit de benchmarks.

Resultaat is dat er nog genoeg overblijft voor de andere processor

[Niles]

@#&$@*#$_*(@#$ damn, nu je het zegt ja, het was al laat

[Verwijderd]

Dan komt mijn eerste vraag, zal AMD hun dual-core CPU's ook uitbrengen voor het S754 platform of blijft dit behouden voor het S939 platform? Het logisch dat AMD zal kiezen voor alleen een S939 platform aangezien zij hebben aangegeven dat dit het platform zal worden voor eventuele verdere ontwikkelingen binnen het AMD64 gebeuren. Maar uit de tekst kan ik niet opmerken of dit inderdaad het geval is.

S754 gaat ook nog wel een hele tijd mee, maar alleen als budget - midend systemen, en dual core lijkt me nou niet echt budget, ik denk dat ze het bij S939 en 940 houden aangezien dat zoiezo de servers/workstations/mid-highend desktops worden.

[PCSoldaat]

Hoe weet de software over hoeveel processors deze beschikking heeft.

Is het noodzakelijk dat de software dit 'weet'? Kunnen ze de cpu niet 'slim' genoeg maken om zelf zijn taken te verdelen?

[Genghis Khan]

Is het noodzakelijk dat de software dit 'weet'?

Ja, je wilt natuurlijk wel dat je software multithreaded gaat werken. Anders heb je er nog niks aan.

[Verwijderd]

Dan heb je er nog steeds iets aan omdat je OS het als het goed is wel weet en de threads van verschillende programma's verdeeld over de 2 cores.

[Zer0]

Je OS is ook niet veel meer dan een (verzameling van) programma('s) en moet dus ook meerdere CPU's kunnen herkennen. Neem bijvoorbeeld Windows 98, al stop je 10 cpu's in je pc, er zal er maar 1 gebruikt worden.

[Genghis Khan]

Dan heb je er nog steeds iets aan omdat je OS het als het goed is wel weet en de threads van verschillende programma's verdeeld over de 2 cores.

Dat klopt ja, maar het grootste voordeel van multithreading is nog steeds dat je bij erg zware applicaties (zoals renderen of video-editing) beide processors in kunt zetten voor dezelfde taak. Dit zou dus niet mogelijk zijn, als de software zich niet bewust is van de aanwezigheid van meerdere processors/cores en dus gewoon met één thread tegelijk gaat werken.

De situatie die jij omschrijft is gewoon het loadbalancen van alle applicaties over de beschikbare CPU's. Dit wordt inderdaad door de kernel uitgevoerd.

[lvh]

In princiepe hoeft de software niet "bewust" te zijn van de processors. De software moet gewoon multithreaded geschreven zijn. Dit is inderdaad met SMP (meerdere processors) in het achterhoofd, maar multithreading werkt gewoon op een processor en op meerdere. Het princiepe is dat je meerdere process threads maakt -- ofwel verdeelt de kernel die onder meerdere processors, ofwel geeft de kernel gewoon meerdere threads aan een processor (afhankelijk of je een of meerdere processors hebt, natuurlijk).

Maw, multithreading apps zijn geschreven "voor SMP", maar at run time is het programma zich er meestal niet van bewust of z'n threads door een of meerdere processors worden afgehandeld.

[Verwijderd]

Beter is software zich wel bewust van de kans meer dan 1 processor tegen te komen. Slordige multi-thread-programmering kan erg onaangenaam uitpakken op een MP systeem. Zo doen een aantal spellen van Westwood het niet op een MP systeem tenzij je als de weerlicht de affinity op 1 processor zet.

[Astennu]

K denk dat ze dan te veel ruimte nodig hebben om dat te doen en mischien ook latency met zig mee brengt ? lijkt me idd wel makkelijker maar nu regeld de software dat idd allemaal.

[Verwijderd]

Nee, dat kan de processor niet zelf doen. De processor weet niets van taken af, en al helemaal niet hoe die optimaal te verdelen. Dit doet het besturingssysteem. Dit zorgt er ook voor dat het makkelijk is die algorithmen te verbeteren en te testen

[Verwijderd]

In principe moet dat kunnen ja. De vraag is alleen : wat kost dat?

[PuzzleSolver]

In principe moet dat kunnen ja

Geef dan ook aan hoe dit zou kunnen, want in de huidige situatie heeft de processor er niets over te zeggen welke code hij krijgt om uit te voeren. Ook heeft hij geen beschikking over de thread administratie.

Een manier waarop een processor dit zelf zou kunnen bepalen zou zijn door de kernel code (of eigenlijk alleen het thread gedeelte ervan) van het OS te intergreren in de processor. Dit zou een behoorlijke verandering voor zich mee brengen wat betreft het OS wat erop draait. De kosten zijn voor de processor fabrikant niet eens zo veel meer, maar of de markt hier op zit te wachten? Een andere methode zou zijn die kernel te verwerken in de processor driver. Of dit soort ideen interresant zijn? mischien in de toekomst als er nog meer cores op de processor komen en deze ook nog verschillende functies krijgen, maar op dit moment is het gewoon het OS wat alles bepaald en zijn er niet echt veel voordelen om dit soort dingen naar de processor te verplaatsen.

[Astennu]

K vraag me af of dit ooit voor de normale thuis gebruikers gebruikt gaat worden of dat dit alleen bij servers zal blijven.

[J0J0]

Vergelijk het met de formule 1...wat er daar aan techniek gebruikt wordt vindt meestal zijn weg naar de auto industrien na een paar jaar.

Lijkt me zeer aannemelijk dat wij dit ook in een gewone pc voor de consument zullen terugvinden.

Intel is ook bezig met multicore CPU's.
Vrijwel alle modellen zullen multicore worden.
Staat dus wel vast dat wij dit ook zullen kunnen aanschaffen.

[Memendo]

Multicore-cpu is IMHO niet meer dan een mogelijkheid die ontstaan is door de schaalverkleining en productieprocessen van de afgelopen jaren. We kunnen nu meerdere cores zetten op de zelfde socket(oppervlak) Ipv het aantal Ghz te verhogen, waar Jan modaal zich op blind staart realiseren de chipbakkers zich dat hier ook een plafond berijkt zal worden met de huidige technieken. Daarom zal meer rekenkracht uit de breedte moeten komen cq meeerder cores/ multi treading enz.


Even totaal off-topic, maar wat hebben wij in de laatste 10-jaar precies van F1 geleerd?

We hebben nu schakelsysteem met flippers achter het stuur, maar dat is meestal meer een onzinnige optie dan iets waar je echt iets aan hebt (afgezien van een aantal sportwagens)

F1 is echt aan het vervreemden van de normale auto-techniek. De motoren draaien tegen de 19 000 rpm, dat wil je echt niet in een personenauto. Actieve vering mag niet meer, allerlij software/maatregelen om het de coureur makkelijk te maken zijn sinds kort weer verboden. Aerodinamica zoals die in F1 word toegepast ben je op een personenauto niet nodig.

[Verwijderd]

Auto's en computers vergelijken gaat bijna altijd fout.
Er zijn altijd mensen met vergelijkingen als: fiat panda vs bmw M5, F1 vs. personenautos, vrachtwagen vs. ferrari, enz enz...

En ff wat meer on-topic:

Dual (en multi) core is idd een vrij logisch gevolg van de grens waar we vrij snel tegenaan gaan lopen: het kan niet veel kleiner meer.
Voordat de quantumcomputer er is zal er meer nodig zijn dan die-shrinks (denk aan strained-Si, SOI, enzo).
Zoals ik en iemand anders al hebben gezegd hier: Dual core 90nm is minder grote als single core 130nm,en dus een vrij logische en redelijk simpele manier om de performance flink omhoog te schroeven, want ik zie nog geen 6-7 ghz P4's of 5 ghz Athlon64's het komende jaar.

Hoewel de dual core in het begin voornamelijk voor de servers etc. gebruikt zullen worden denk ik dat ze in H1-2006 toch wel al in high-end desktops zitten.

* 786562 RuL0R

[Verwijderd]

Tegenwoordig is de F1 hiervoor een nogal slecht voorbeeld. Veel techniek van een F1 auto heeft meer overeenkomsten met een vliegtuig dan met gewone wegauto's. Daarnaast worden dingen die voor personenauto's interessant kunnen zijn (ABS, ESP tractie controlle enz) bij de F1 steeds meer verboden.
Het resultaat is dan ook dat er vrijwel geen techniek meer van de F1 naar gewone auto's stroomt.

[boner]

Definieer 'nomaal'. Zijn tweakerts normaal?
Als je kijkt naar wat we als een normaal systeem berschouwen, en dat vergelijkt met een supercompu van 10 jaar terug.... Dit had echt niemand kunnen voorspellen.

En dan nog steeds mopperen over kl****te traag...

[Digistorm]

dat komt omdat de software ook elke keer "trager" wordt gemaakt

[mxcreep]

Doel je ergens specifiek op ??

[Noel]

Wat er echter niet bekend was, is dat de aansluiting voor de tweede Opteron-core al aanwezig is op de SRI van de huidige Opteron-processors.

De dual-coreprocessor zal compatibel zijn met de huidige sockets voor AMD64-processors.

Dat zijn toch wel 2 zeer sterke troeven. Waaruit nogmaals blijkt dat de voorbije 2-3 jaar AMD bezig was met een groots plan. Eerst een oerdegelijke processor bouwen, tegelijkertijd al rekening houdend met de toekomst, en vanaf die mooie single core basis kunnen ze nu dus met een zeer mooie (en niet al te dure, lijkt me) dual core architectuur komen.

AMD gaat lekker.

[Verwijderd]

hij heet niet voor niks sledgehammer

Maar ff serieus, inderdaad een hele goede zet van AMD, die SRI neemt niet zo heel veel Si van de wafer in beslag, en in ruil daarvoor kan je met een hele kleine aanpassing al dual core cpu's gaan bakken.
De opteron en Athlon64 zijn nu al zeer goede cpu's, vaak sneller als een P4, en nu er steeds meer software voor intel's HTT wordt geoptimaliseerd (terwijl HTT niet zo heel erg veel winst geeft) wordt de performance helemaal gigantisch.

1 van de grote voordelen van de Athlon64 en de opteron was/is dat ze, hoewel het 64 bit cpu's zijn, nog steeds "oude" 32 bit software draaien. Het voordeel van de dual core is dat de huidige software er meteen gebruik van kan maken.

Nu ik erover nadenk... het was eigenlijk niet zo slim van intel om zo snel met HTT te komen en te zorgen dat alle software er voor gebakken wordt, want hoewel ze er 10% sneller van worden, wordt AMD er nu minstens 70% sneller van.

[Olaf van der Spek]

Dat zijn toch wel 2 zeer sterke troeven.

Zo'n voordeel is het toch niet dat die aansluiting voor de tweede core er al op zit? Hij is toch niet bruikbaar.

[Verwijderd]

Dat is wel degelijk een voordeel, het overstappen bij de productie van single- naar dualcore wordt zo makkelijker en goedkoper, je hoeft bij wijze van spreke alleen de core te copy-pasten en aan de SRI te hangen, en je bent klaar.
Dit is niet alleen gunstig voor de prijs, maar ook voor het moment waarop de dualcore cpu's beschikbaar zijn.

[joffri]

Hmm ik zie op het schema duidelijk gescheiden L2 cache, 1MB per cpu.

Volgens mij heeft intel's dual core een gedeelde L2 cache, (wat volgens de topicstarter voor een snelle communicatie tussen de cores moet zorgen, waar ik zo mijn twijfels over heb. Ik denk niet dat cores via het geheugen met elkaar gaan communiceren)

http://www.tweakers.net/nieuws/34014

Weet iemand waarom er gescheiden L2's zijn én belangrijker, wat de gevolgen daarvan zijn.

dan nog iets, HT0, HT1,HT3 3 thread's, en een pad voor de memory controller. Maar hoezo 3 paden voor 2 cores ?

Wij danken u bij voorbaat voor uw inlichtingen

//edit typo

[Verwijderd]

dan nog iets, HT0, HT1,HT3 3 thread's, en een pad voor de memory controller. Maar hoezo 3 paden voor 2 cores ?

Het zijn geen threads (dan heet het HTT ipv. HT) maar hypertransport bussen.

En de reden dat er 3 zijn: dit is een opteron 8xx, die hebben allemaal 3 HT bussen (dual of single core, maakt niet uit)
1 bus gaat naar "het systeem" (Southbridge ed.)
en de 2 andere bussen gaan naar eventuele andere cpu's.
Een 2xx heeft 2 bussen, 1 voor systeem, en 1 voor de andere cpu.
En een 1xx heeft er 1, want hij hoeft niet te communiceren met andere cpu's want die zijn er niet.

edit:
Voordelen van een niet gedeelde cache: Iedere core kan snel bij zijn eigen cache, sneller als wanneer dit gedeeld is. En er is sowieso meer cache (2x 1MB > 1x1MB)

[Verwijderd]

voordeel van een gedeelde cache:
Iedere core kan bij de cachegegevens van de andere core en 2MB gedeeld kan efficienter zijn dan 1+1MB doordat een core meer dan 50% van de cache kan gebruiken en er geen zaken dubbel hoeven te worden opgeslagen.

Elk voordeel heeft zijn nadeel. Wat uiteindelijk het beste werkt hangt sterk af van de manier hoe het geimplementeerd is.

[Verwijderd]

Daar heb je gelijk in, maar over het algemeen zijn AMD cpu's niet zo gevoelig voor de hoeveelheid cache of bandbreedte, maar meer voor de latency, en daarom is een niet-gedeelde cache misschien sneller.

[Ronald]

De amd oplossing heeft 2x zoveel l2 op de processor als de intel oplossing.

- Meer performance

De Amd oplossing deelt de bandbreedte naar de cache niet met 2 cores

- Meer performance

Nadeel is dat meer cache meer silicium kost en dus yields.

Amd processoren kunnen vanaf de Athlon MP al rechtstreeks met elkaar communiceren.

De hypertransport verbindingen zijn extern, naar andere cpus en/of naar de agpbridge/pci tunnel (aka northbridge)

[player-x]

vraag me af hoeveel de core groter word met dual in plaats van singel core desine

[Gogar]

2*90^2
---------- = 0.96
130^2

zelfs kleiner dan de huidige 130nm chips

[Verwijderd]

hij is niet 2x zo groot als een single core want de de HT bussen, de memory controller, en de SRI worden gedeeld, 70% ofzo?

1.7*90^2
------------ = 0.81
130^2

[Verwijderd]

Hoe zou Cool'n'Quiet zich gedragen bij 2 cores?

Als je idle draait heb je natuurlijk niet de rekenkracht van 2 cores nodig, zelfs niet van 1 core, dus ik vraag me af of C'n'Q gewoon een core uitschakeld als deze niet nodig is, of deze toch aanhoudt op een lage clock om sneller "wakker te worden" als je een programma opstart oid.

[Verwijderd]

De cool'n quiet zal wrs juist hetzelfde werken als voor een single core , volgens mij gaan de 22cores wel op eenzelfde kloksnelheid gaan werken aangesturd door 1 "klok" (de juiste naam schiet me niet meteen te binnen

[Da_DvD]

Opteron gebruikt geen Cool en Quiet.. dus daar hoeven ze zich geen zorgen om te maken

[Verwijderd]

wie wil deze jonge helpen
ik ben nog maar een beginnende computer freak
maar weet nog niet waar al die afkorting voor staan die ze hier gebruik
cache geheugen jah dat weeet ik wel maar SSE IAM32 SRI (jah is een system request interface maar waar is dat voor
wie wil deze domme jonge helpen leren
tnx

[FireWood]

SSE is een apparte instructieset die gebruikt wordt in speciale gevallen, waar bij veel specifiek rekenwerk nodig voor is. In de praktijk voornamelijk video encoding

Die andere twee weet ik ongeveer, maar niet genoeg om uit te leggen

[TheGhost]

misschien helpt dit:

klik

beetje zoeken met Google helpt vast ook wel

[Left]

Maar hyperthreading werkt toch heel anders dan echt multiprocessing ?
Ik dacht dat je met hyperthreading alleen maar bepaalde types instructies tegelijkertijd kon uitvoeren ... Software die hiervoor geoptimaliseerd is die buit de mogelijkheden van een multi processor systeem toch lang niet maximaal uit ?

Dus je kunt een mulit core AMD wel laten vertellen dat hij hyperthreading ondersteunt, en software die geoptimaliseerd is voor hyperthreading zal dan wel werken, maar je gooit dan wel een stukje performance weg. Of zie ik het verkeerd ?

[Verwijderd]

Ik zou zeggen: draai even een benchmark en vertel het ons. dan weten we het tenminste, is het opgehelderd