AMD geeft testrit 4x4-platform in München

waarom zou een oudere technologie om te produceren goedkoper zijn? er kunnen immers meer chips op 65 uit een wafer gehaald worden? Omdat AMD dit proces pas gebruikt gebruikt AMD dit nog niet voor de top of line processoren.

ik denk dat dat nog al tegen valt,
wat je hier namelijk vergeet, is dat er ook nog zoiets bestaat als productie-foutjes...

het probleem met deze hele cpu productie is sins het begin der tijd al de relatief 'extreem' hoge uitval ... natuurlijk kun je altijd ngo cores uitschakelen en 't hele ding als dual of single core verkopen. maar dat is verre van ideaal...

hoe ingewikkelder de chip hoe lager de yields... -
DAT is dan juist de rede waarom je met dit soort cpu's dus op een 'vertrouwe' manier wilt produceren....ook al kost 't je veel meer wafers...

Hetzelfde is gebeurd met de Pentium 4 EE, door sommigen bestempeld als Emergency Edition. Dat was ook een serverprocessor rebranded naar desktop processor, om te concurreren met de veel beter presterende Athlon 64 X2 dualcores.

Nu AMD wat mindere tijden tegemoed gaan, kunnen ze maar beter wat goedkope trucen uit de mouw trekken, en hopen dat K8L en 65nm productie snel verloopt. Voordeel voor AMD is dat het met de verkopen wel goed zit; er zit denk ik een groot vertragingseffect in de technische superieuriteit die Intel op dit moment geniet.

elke AMD socket heeft zijn eigen toegang tot een stuk geheugen dat heeft Intel niet en daarom is de FSB zo zwaar belast. Bovendien verhoogt de bandbreedte van het totale geheugen met elke socket die in een AMD systeem gebruikt word. Schaalbaarheid is dus wel degelijk beter bij AMD

elke AMD socket heeft zijn eigen toegang tot een stuk geheugen dat heeft Intel niet en daarom is de FSB zo zwaar belast. Bovendien verhoogt de bandbreedte van het totale geheugen met elke socket die in een AMD systeem gebruikt word. Schaalbaarheid is dus wel degelijk beter bij AMD

Dat is niet helemaal waar.
De keerzijde van het feit dat iedere socket z'n eigen geheugen heeft, is dat niet iedere CPU zomaar bij al het geheugen kan, en dus via de HT-link de geheugencontroller van de andere CPU aan moet spreken.
Aangezien bijna geen enkele normale desktop-applicatie NUMA-aware is, heb je vaak alleen maar nadeel van deze situatie.
Het kan een voordeel zijn als je onafhankelijke processen draait, maar dat is meer iets voor de server-wereld, niet voor desktop/workstation, waar je vaak liever 1 a 2 applicaties zo snel mogelijk hebt draaien. En als je de Opteron-benchmarks ziet, moet je concluderen dat NUMA daar vaak een nadeel is, en een systeem juist helemaal niet zo goed schaalt met meerdere CPUs, waar een Xeon dat wel doet.

toegegeven dat een gedeeelte van het geheugen alleen door de HT bus bereikt kan worden, maar dat is nog altijd sneller dan al het geheugen en de communicatie door de FSB te leiden.
Hoe meer cores je wil gebruiken des te groter word de FSB bottleneck. dus waar jij denkt dat een Xeon beter schaalt zie Ik dat juist niet gebeuren. Op dit moment is de Xeon wel sneller waar er maar twee processoren gebruikt worden, maar als je hoger schaalt wint de opteron.
Bij twee applicaties geef je elk een eigen processor en heb je niets met de HT link te maken.
Feit is dat de software inderdaad achterloopt bij de hardware, maar denk dat dat snel ingelopen gaat worden nu het offensief van beide kanten is ingezet voor multicore en ook Intel door heeft dat ze met eejn beter schaalbare oplossing moeten komen

toegegeven dat een gedeeelte van het geheugen alleen door de HT bus bereikt kan worden, maar dat is nog altijd sneller dan al het geheugen en de communicatie door de FSB te leiden.

Dat statement klopt niet.
Het hangt allemaal af van de bandbreedte van HT-bus en FSB.
Ik durf de bewering wel aan dat je met de huidige HT-bus van AMD niet tegen de 1333 FSB van de Xeon op kunt met 4 cores of minder.

Hoe meer cores je wil gebruiken des te groter word de FSB bottleneck. dus waar jij denkt dat een Xeon beter schaalt zie Ik dat juist niet gebeuren.

Je hebt m'n post maar half gelezen. Ik zeg dat NUMA beter is voor server-toepassingen, maar niet voor desktop.
Kortom, Xeon zal met server-toepassingen minder schalen, maar met desktop niet... misschien zelfs beter.

Bij twee applicaties geef je elk een eigen processor en heb je niets met de HT link te maken.

Maar zoals ik al aangeef, is het niet heel gebruikelijk voor desktop/workstation-gebruikers om 2 of meer bandbreedte-intensieve applicaties tegelijk te gebruiken.
Vaak zullen ze liever willen dat een enkele applicatie zo snel mogelijk loopt... zoals een spelletje, of 3d rendering, of video-editing oid.
En ik denk dat juist daar de Kentsfield beter scoort dan een 4x4.
4x4 is immers ook eigenlijk geen desktop-platform, maar gewoon een Opteron-systeem, dus voor de server/workstation-markt. Het is dus voor andere taken ontworpen.

K8L is echt wat anders.

Dat blaast alles letterlijk weg. Maar je zult tot 2008 moeten wachten voor je hem kunt kopen.

Tot die tijd blaast de Core2 alles weg, behalve wat latency sensitive code.

Bijvoorbeeld CFD codes die graag een terabyte ram nodig hebben.

Gelukkig draaien we dat niet allemaal. Wat physicists draaien dat op universiteiten.

May i beg you pardon.

Testen voor AMD gebeurd ver weg in Azie. Een fabrieksarbeider zit op de 30 eurocent per uur. Natuurlijk IT'ers wat meer. Testen gaat volautomatisch en kost een paar weken per chip.

Dus het kost iets stroom, dat is alles.

Het drukken zelf is de daadwerkelijke CONSTANTE kostprijs per chip.

Ik gok rond de 50 dollar per quad father chip. Het zijn er 2, dus rond de 100 dollar totale kostprijs.

Daar komt bij dat het drukken in Duitsland gebeurd.

Dat is peperduur personeel. Soms ook Nederlands personeel (meegeleverd door ASML).

Die verdienen gemiddeld factor 5 tot 50 meer als hun collega's in Azie.

Dat testen is werkelijk spotgoedkoop.

Development is een ander verhaal natuurlijk. Daar zitten veel verborgen kosten in zoals testcpu's al verspreiden naar allerlei bedrijven.

De grootste kostenpost bij AMD en intel is en blijft de kale constante productieprijs per chip. Dit natuurlijk daar ze zoveel chips verkopen.

@diederik77.
Het testen van een chip is een redelijk kostelijke zaak. En net als de productie van een chip (nog nooit iemand tegengekomen die dat 'drukken' noemt, maar goed) heeft dat weinig te maken met de arbeidskost: de kapitaalskost is namelijk stukken duurder.

Een deftige chip tester kost al gauw 2 miljoen dollar. Voor complexe chips doet die er pakweg 3 seconden per chip over.
In de zeer optimistische veronderstelling dat die 365 dagen per jaar absoluut non-stop draait en die tester op 1 jaar afgeschreven moet worden (en dat is niet uitzonderlijk), dan kost het testen van 1 chip:
2mil * 3/ 365*24*3600 = $0.19.
Per uur kost die machine $228. Vanuit dit opzicht is het verschil in loonkost per uur van $10 (Europa) <> $2 (Taiwan) slechts een fractie van de test kost.

Wat de productiekost betreft: loonkost is daarbij helemaal al geen factor omdat de machines nog een orde grootte duurder zijn. De prijs van een geproduceerde wafer is ruwweg $6000. Daar kan je pakweg 300 werkende processors uit halen. De kostprijs is dus ergens rond de $20 per processor.

'I beg your pardon' uitbazuinen is geen garantie dat de persoon in kwestie er zelf iets van weet.

QED in dit geval.

Toch lijkt het mij logisch dat twee CPU's ook stukken meer verstoken, stroom is (helaas!) geen gratis goed..

socket AM3 is uitgesteld, quadcores komen voor zowel socket 1207 en AM2 uit als de tussenliggende AM2+ stap. Althans dat is wat er gezegd word nu.

Links? Want dat nieuws heb ik gemist.

het stond op the inquirer ergens. weet het is niet de beste bron, maar heb het ook ergens anders gelezen, maar weet niet meerw elke site dat was.
heb helaas geen links voor je.

Klik mij

voor de luie tweakerd een samen vatting....

• K8L komt eerder uit dan AM3
• K8L krijgt 2 geheuge controlers ...
  > voor dr2 (socket AM2 & AM2+
  > voor ddr3..(socket AM3)
  (dit maakt de K8L backwards compatible voor AM2 en AMD2+
• AM2+ is een veredelde AM2 (pin compatible) socket met als belangrijkste nieuwe optie. Hyper Transport v3....

Klik mij

voor de luie tweakerd een samen vatting....

K8L komt eerder uit dan AM3
K8L krijgt 2 geheuge controlers ...
> voor dr2 (socket AM2 & AM2+
> voor ddr3..(socket AM3)
(dit maakt de K8L backwards compatible voor AM2 en AMD2+
AM2+ is een veredelde AM2 (pin compatible) socket met als belangrijkste nieuwe optie. Hyper Transport v3....

Ja, maar niets over Socket 1207... 4x4 is geen Am2, Am2+ of Am3, dus het lijkt er nog steeds op dat er geen quadcores in gaan passen.

[reactie op ddbruijn]Ik wordt wel heel erg moe van jou.
Je kan niet zelf zoeken en zelfs dit nieuws bericht niet lezen.
Maar ik zal je nog een keer op de goede weg zetten.
De quadcore zal als eerste als Opteron op de markt worden gezet. Dit in een socket 1207. Dit mag je zelf zoeken is niet moeilijk te vinden.

over het 4x4 platform

Volgens AMD zal het 4x4-platform later probleemloos kunnen worden voorzien van quadcoreprocessors, waarvan de codenaam 'Agena' is.

Dit staat in het bericht hier boven dus dat was niet moeilijk.
4x4 staat voor 4 CPU core en 4 GPU core's.
dus als je volgend jaar twee quad core er in stopt krijg je een 8x4 systeem.

Lees dit eerst eens:

http://www.microsoft.com/...ready/expressupgrade.mspx

ze worden hier los verkocht in winkels dit is gewonen handel niet van merk pc's.

Je vergeet dat prijzen in dollars bijna altijd zonder 'taxes' is.. Dus 1000,- lijkt mij wel de prijs.

Licensed Device. You may install one copy of the software on the licensed device. You may
use the software on up to two processors on that device at one time. Except as provided in the
Storage and Network Use (Ultimate edition) sections below, you may not use the software on any
other device.

te vinden onder 2a in de text.

de ultimate edition. tussen haakjes in de gequote text heeft enkel betrekking op de Storage and Network use.

1. STORAGE. You may store one copy of the software on a storage device, such as a network server.
You may use that copy to install the software on any other device to which a license has been
assigned.
2. NETWORK USE. Instead of installing the software on the licensed device, you may install one copy
on a storage device, such as a network server. You may use that copy only to run the software on
your licensed device over an internal network.

uit de aditional terms voor de ultimate edition.

Zo ver als ik dat kan zien kunnen zowel de basic als de premium en ultimate edition gebruik maken van 2 processoren.

Een cluster heeft niets te maken met het ondersteunen van heel veel proc door het besturings systeem. Juist niet zou ik eerder zeggen.
1 computer met 128 procesoren is geen cluster dat is een mainframe.
Een cluster is een hele serie computers die centraal aan het werk worden gezet. Maar de clients zijn vaak gewoon 1 of 2 proc desktop computers.
Hierdoor heb je veel rekenkracht voor weinig geld. Je moet alleen wel in staat zijn om het werk te verdelen. En op elke client moet een OS draaien. De client OS hoeft echter niet meer te kunnen als aan de server te vragen wat er gedaan moet worden en dat uitvoeren en de resultaten weer naar de server sturen.
Projecten als Folding@home vormt samen een cluster.

Dat is verschil in strategie tussen Intel en AMD.
Intel roept al lang van te voeren wij gaan dit en dat doen en hier heb je vast een voorproefje en dergelijke.
AMD is meer van eerst maken en produceren en dan prijs geven.

Het zelfde zie je bij twee andere bedrijfen.
MS loopt al jaren te roepen over hoe geweldig Vista gaat worden en wat er allemaal wel niet in komt. Daar zie je ook gelijk het risico. Ze hebben het heel vaak moeten bij stellen.
Hun collega's van Apple die maken eerst iets en zeggen dan wij hebben iets ontwikkeld en het ligt morgen in de winkel.

Dus dat AMD nog niet zo veel benchmarks vrij geeft wil nog niet zeggen dat het niets is/word.

Het probleem met die FSB is dat er alle communicatie met de rest van het systeem door moet, up en down.

Zoals de communicatie naar en van het geheugen, videokaart, southbridge en zelfs de 2 Cores onderling.

Dat vreet. Het vereist veel bandbreedte. Wat AMD in ieder geval doet is de communicatie van en naar het geheugen niet over de HTT bus richting de rest van het system gooien, de 2 CPU's comminiceren over een aparte HTT bus, dus staan los van de HTT bus richting de rest van het systeem.

Shared L2 cache?

Kijk 'ns naar dit plaatje. Rechts is Kentsfield.

Er is telkens 4MB L2 shared per core pair, 8MB totaal. Als de ene Core/Cache communiceert met de andere dan moet het via de FSB up en down over de Northbridge.

Kentsfield mag alleen een Quadcore genoemd worden omdat er 2x2 cores onder één heatspreader op 'n stuk siliconen gebakken zit.
In weze is kentsfield een herhalings operatie van de originele PentiumD, 2 losse delen die moeten communiceren over de FSB, die toch al zwaar belast is door de communicatie met het geheugen. Onder zware belasting zal de FSB het systeem gaan afknijpen.

Maw, het blijven allebij halfslachtige tussenoplossingen. Totdat we echte quadcores krijgen in '07.
Ik herhaal mezelf, maar welke het beste presteert is nog maar de vraag, hoogstwaarschijlijk is het toch Kentsfield, aangezien Intel op Core-niveau betere prestaties haalt op dit moment dan AMD.

Dat vreet. Het vereist veel bandbreedte. Wat AMD in ieder geval doet is de communicatie van en naar het geheugen niet over de HTT bus richting de rest van het system gooien, de 2 CPU's comminiceren over een aparte HTT bus, dus staan los van de HTT bus richting de rest van het systeem.

Dat is dus niet waar. Wanneer een CPU het geheugen van een andere CPU aan moet spreken, gaat dat dus via de HTT bus.
Verder wil ik wel eens bewijs zien van het feit dat een CPU meerdere HTT-bussen heeft.
Voor zover ik weet, is er maar 1 HTT-bus per systeem, en wordt er een crossbar-switch gebruikt om de bandbreedte te verdelen tussen alle agents op de bus.

Shared L2 cache?

Kijk 'ns naar dit plaatje. Rechts is Kentsfield.

Er is telkens 4MB L2 shared per core pair, 8MB totaal. Als de ene Core/Cache communiceert met de andere dan moet het via de FSB up en down over de Northbridge.

Ik weet wat een Kentsfield is ja, arrogante drol.
Inderdaad, shared L2-cache per core. Dat betekent dus dat er tussen die twee cores geen synchronisatie nodig is van de L2-cache.
Je hoeft dus maar 2 caches synchroon te houden via een bus. Bij AMD moet je wel 4 caches synchroon houden over 1 bus.

In weze is kentsfield een herhalings operatie van de originele PentiumD, 2 losse delen die moeten communiceren over de FSB, die toch al zwaar belast is door de communicatie met het geheugen. Onder zware belasting zal de FSB het systeem gaan afknijpen.

Zie ook: forum: Mijn voorlopige bevindingen over multicore-processing

De Pentium D komt er niet veel slechter vanaf dan de Athlon X2 met z'n HTT-bus, en dat is maar 2 cores.
Bij de Kentsfield hoeft er niet meer te gebeuren dan bij een Pentium D, het zijn nog steeds maar 2 caches. De FSB daarentegen is wel sneller en efficienter geworden.
Bij de 4x4 moet je nu 4 cores ipv 2 cores over dezelfde bus gaan synchroniseren.
Ik denk dat ik wel kan voorspellen wat er efficienter is.

Ik herhaal mezelf, maar welke het beste presteert is nog maar de vraag, hoogstwaarschijlijk is het toch Kentsfield, aangezien Intel op Core-niveau betere prestaties haalt op dit moment dan AMD.

Dat sowieso, maar ik denk dat mijn code genoeg aanleidng geeft om aan te nemen dat het als geheel ook efficienter is.
Helaas heeft nog niemand met een Opteron-systeem de code getest. Het zou wel interessant zijn om te zien of een Athlon X2 beter is dan twee singlecore Opterons van vergelijkbare snelheid... of hoe twee of meer dualcore Opterons zouden schalen.

arrogante drol. Nou Nou!

Verder wil ik wel eens bewijs zien van het feit dat een CPU meerdere HTT-bussen heeft.

Even googlen.. Geen bewijs, maar het eerste resultaatje, zomaar een artikeltje, voor bewijs zul je verder moeten googlen.

Meerdere HTT links per Systeem.

While Kentsfield in all likelihood will scale nicely in mutli-threaded applications and under heavy multi-tasking scenarios, the chip still shares a single front side bus, which unlike AMD's dedicated HT links for each dual core CPU, is a shared-bus architecture and potentially not as efficient. Time and benchmark data will tell the real story here of course.

Inherent dus aan dit plaatje.

Wat probeer je nou zo halsstarrig te verdedigen. Niemand weet niks totdat het echt aan de tand gevoeld is. En tot die tijd is en blijft het koffiedik kijken.

[edit:]
Dat sowieso, maar ik denk dat mijn code genoeg aanleidng geeft om aan te nemen dat het als geheel ook efficienter is.
Ik had je artikel al gelezen, en alhoewel het erg interessant en goed onderbouwd is denk ik dat je erg veel conclusies trekt uit één enkele code. Zonder je verder op de kast te willen krijgen overigens.

Even googlen.. Geen bewijs, maar het eerste resultaatje, zomaar een artikeltje, voor bewijs zul je verder moeten googlen.

In dat plaatje zie ik maar 1 HTT bus, namelijk dat rode lijntje. Daarmee worden de CPUs met elkaar verbonden, met de chipset, en met de PCI Express tunnel.
Als het aparte bussen zouden zijn, dan zou dat dus betekenen dat 1 van de twee CPUs niet met de chipset kan communiceren, en dat lijkt me niet zo.
Ik denk dus dat je het plaatje verkeerd hebt begrepen.

Ik had je artikel al gelezen, en alhoewel het erg interessant en goed onderbouwd is denk ik dat je erg veel conclusies trekt uit één enkele code. Zonder je verder op de kast te willen krijgen overigens.

Het zijn 3 verschillende implementaties van hetzelfde algoritme. 3 stukken code dus, niet 1. Waarbij 3 verschillende systemen worden getarget.
Als ik te veel conclusies trek, dan zou je die moeten kunnen aanvechten met steekhoudende argumenten en bewijs van het omgekeerde, en dat is nog niet gebeurd, dus ik zie geen reden om te twijfelen aan mijn conclusies. Als je het beter weet, verlicht mij dan.

athlon 64 en opteron 1xxx hebben idd 1 htt bus. de opteron 2xxx en dus zometeen ook de quadfather hebben er 2 en de opteron 8xxx heeft er 3. bij HTT3 kunnen die bussen ook nog een keer gesplitst worden. Nu snap Ik waarom jij dacht dat er bij de HTT opzet hetzelfde zouy gebeuren als bij de FSB aanpak. dus niet het geval. de FSB bus word veel zwaarder belast, immers ook de cache coherency moet over de fsb terwijl dat bij AMD over de HTT links gaat, zelfde geld voor inter processor communicatie

de FSB bus word veel zwaarder belast, immers ook de cache coherency moet over de fsb terwijl dat bij AMD over de HTT links gaat, zelfde geld voor inter processor communicatie

Ik leg het nog 1 keer uit:
AMD moet 4 caches synchroniseren over 1 bus, Intel maar 2 caches.
De HTT links van AMD worden dus veel zwaarder belast.
Daarnaast blijken ze na testen ook een heel stuk trager te zijn dan shared L2-cache, en amper sneller dan FSB (Pentium D).
Ik word er bijzonder moe van dat ik dat al 20 keer heb gezegd, en dat het steeds maar genegeerd wordt, en hetzelfde onzinverhaaltje over AMD weer opgerakeld wordt.
Ik weet dat je die flauwekul ergens met google hebt gevonden, maar zou je niet eens zelf nadenken? Of nog beter, zou je niet eens zelf wat code schrijven om te testen hoe efficient zo'n HTT-link nou werkelijk is, ipv klakkeloos de foute/verouderde conclusies van een ander over te nemen? Kom op zeg, dit is tweakers.net, beetje niveau mag je hier toch wel verwachten?

Ik zal blij zijn als die benchmarks er zijn, dan zien al die zieke AMD-fans, die hier maar onzin lopen te posten en informatieve posts met de waarheid weg lopen te modereren, misschien eindelijk eens in dat ze het gewoon helemaal bij het verkeerde eind hebben.

De reden dat jij het iedere keer moet uitleggen is omdat jij je niet genoeg verdiept hebt in de materie en gewoon niet gelijk hebt!
Ik vind het helemaal niet erg als je erg stellig dingen gaat roepen maar kom dat gelijk met een paar links waarin duidelijk wordt dat je gelijk hebt.

link naar AMD tech doc

HyperTransport™ Technology to I/O Devices
– Three links, 16-bits in each direction, each supports
up to 2000 MT/s or 4.0 GB/s in each direction
(2000MT/s supported by Rev E and later)
– Each link on uniprocessor (UP) models supports
connections to I/O devices.
– Each link on dual-processor (DP) models supports
connections to I/O devices, and any one of the three
available links may connect to another DP or MP
processor.
– Each link on multiprocessor (MP) models supports
connections to I/O devices or other DP or MP
processors.

en verder van de AMD site

Direct Connect Architecture
For servers and workstations, the best 2-way and 4-way architecture for x86 computing
Addresses and helps reduce the real challenges and bottlenecks of system architecture because everything is directly connected to the CPU
Directly connects the processor cores to a single die to even further reduce latencies between processors

Dat is nu net het verschil tussen de eerste dual core van Intel en van AMD. Bij Intel waren het 2 singel core op 1 die en moet het idd via de FBS. AMD had echter een dual core ontwikkeld en de cores kunnen dus ook rechtstreeks met elkaar communiceren zonder een FBS of een HT-link te belasten.
Het grote verschil is dat Intel een shared L2 gaat gebruiken en AMD een shared L3.
Als je een shared L2 gebruikt heb je ook grote kans dat er cycles verloren gaan omdat er eerst ruimte gereserveerd moet worden en daarna kan er pas gewerkt worden. Of gegevens moeten eerst uit het L2 naar het RAM worden geschreven en later weer worden opgehaald. Als je echter 1 treath hebt dat zou je alle L2 kunnen gebruiken en heb je weer een voordeel.
Dat is dus nog even afwachten.
Het is alleen bij Intel zo dat nu 2 dualcore proc op 1 package zitten en van elkaar het bestaan niet weten. Hierdoor moeten ze comuuniceren via de FBS alsof het 2 verschillende CPU's zijn.
Daarnaast is ook de HTlink van AMD sneller als de FBS van Intel en het eigen RAM gebruik hoeft er niet over.

Maar dat de multie CPU van AMD meer HT links hebben had je ook kunnen weten dat is nu juist het verschil tussen een Opteron 1, 2 en 8 serie!
Ik hoop dat je bovenstaande eerst goed leest en als je weer reageert er ook een paar ondersteunende links bij doet.

k vind het helemaal niet erg als je erg stellig dingen gaat roepen maar kom dat gelijk met een paar links waarin duidelijk wordt dat je gelijk hebt.

Dat heb ik gedaan... Ik heb zelfs 3 versies van mijn programma gepost zodat iedereen zelf kan benchmarken.

Verder is jouw informatie van de Opterons, deels van de 8xx-serie, en dus niet van toepassing op de Athlon X2 en FX waar we het hier over hebben.
Zorg dus zelf dat je je beter verdiept.

AMD had echter een dual core ontwikkeld en de cores kunnen dus ook rechtstreeks met elkaar communiceren zonder een FBS of een HT-link te belasten.

Dat weet ik, en mijn programma onderzoekt in hoeverre dat efficient te gebruiken is, en dat valt dus vies tegen in de praktijk. Daar hoor ik je niet over.

Als je een shared L2 gebruikt heb je ook grote kans dat er cycles verloren gaan omdat er eerst ruimte gereserveerd moet worden en daarna kan er pas gewerkt worden. Of gegevens moeten eerst uit het L2 naar het RAM worden geschreven en later weer worden opgehaald. Als je echter 1 treath hebt dat zou je alle L2 kunnen gebruiken en heb je weer een voordeel.
Dat is dus nog even afwachten.

Je hoeft niet af te wachten, ik heb al code geschreven die specifiek gebruik probeert te maken van shared L2-cache. De resultaten zijn bekend.

Het is alleen bij Intel zo dat nu 2 dualcore proc op 1 package zitten en van elkaar het bestaan niet weten. Hierdoor moeten ze comuuniceren via de FBS alsof het 2 verschillende CPU's zijn.
Daarnaast is ook de HTlink van AMD sneller als de FBS van Intel en het eigen RAM gebruik hoeft er niet over.

Als je je wat beter verdiept in het dualcore-ontwerp van AMD, zie je dat het bij AMD niet anders werkt. Er is immers maar 1 memory controller voor 2 cores. Er is dus een interne link die gebruikt wordt om de cores te synchroniseren en het gebruik van de memory-controller te arbitreren, vrijwel gelijk aan hoe Intel dit doet.
Het blijkt dan ook in de praktijk nauwelijks sneller dan een Pentium D, bij het gebruik van shared memory tussen cores, en veel trager dan de shared cache van de Core2, zoals mijn code aantoont.

Ik hoop dat je bovenstaande eerst goed leest en als je weer reageert er ook een paar ondersteunende links bij doet.

Lees jij dit maar eens: forum: Mijn voorlopige bevindingen over multicore-processing
Draai de code, en dan wil ik je nog wel eens horen.
Ik heb die link al veel vaker gegeven, dus niet zo'n brutale mond, eerst die link volgen, code draaien, en geef dan maar toe dat ik gelijk heb. Aan dat theoretische gezever in die documentatie heb je niks, want alleen met een praktijktest kun je echt vergelijken hoeveel efficienter een HT is dan een FSB, en dat valt zwaar tegen. Jammer, maar helaas.
Ook in deze review doet de dual Opteron het helemaal niet zo goed: reviews: Intel Core 2 Extreme QX6700 review
Verklaar dat eens? Dit systeem moet vergelijkbaar zijn met de 4x4, afgezien van de kloksnelheid. Maar je zult ook wel inzien dat alleen iets meer kloksnelheid het verschil met de Kentsfield niet recht gaat trekken. Het gaat fundamenteel fout bij de communicatie tussen cores en memory controllers. Daar haalt de Kentsfield veel van z'n winst.

Nog een fijne dag verder.

Ik heb het helemaal niet over de feitelijke prestaties die jij gemeten hebt met jouw code.
Jij verkondigd dat bij AMD de comunicatie via de HT gaat en dat is gewoon niet waar.
Dat de quad core van Intel ondanks de theoritische belemmering van de communicatie tussen de twee core's over de FBS sneller is als de syncronisatie tussen twee dual core's via de HT, dat heeft voor een groot deel te maken met het feit dat de Core2duo cores gewoon sneller zijn als de Opteron core's. Daar hoor je mij ook helemaal niet over.

een paar poste hier boven zeg jij het volgende:

Dat is dus niet waar. Wanneer een CPU het geheugen van een andere CPU aan moet spreken, gaat dat dus via de HTT bus.
Verder wil ik wel eens bewijs zien van het feit dat een CPU meerdere HTT-bussen heeft.
Voor zover ik weet, is er maar 1 HTT-bus per systeem, en wordt er een crossbar-switch gebruikt om de bandbreedte te verdelen tussen alle agents op de bus.

Jij zegt dus dat er maar 1 HT link is. Ik zeg dat dat niet altijd zo is.
De 4x4 systemen hebben 2 HT links. 1 om te syncroniseren tussen elkaar en 1 om met de rest van het systeem te praten.
Dus het feit dat twee proc onderling lopen te comuniceren om de boel te syngroniceren heeft geen invloed op de prestaties op de link naar de chipset.
Dat de Intel desondanks sneller is heeft met de rekenkracht te maken van de procesor als de snelheid van de bus.

Als je je wat beter verdiept in het dualcore-ontwerp van AMD, zie je dat het bij AMD niet anders werkt