Quadcore Opteron 'Barcelona' komt in vier smaken

Dat heeft niks met HT te maken. En voor single-socket systemen maakt de HT versie/bandbreedte ook nauwelijks iets uit.

DDR2 heeft bandbreedte genoeg volgens mij. Zeker voor AMD.

Is de doorvoersnelheid in zulke systemen dan de bottleneck?
Lijkt mij eerder dat je met veel cores een meer random toegang tot het geheugen krijgt en het wisselen van pagina's is met DDR2 volgens mij net zo langzaam als met SDram. (in verhouding met de bussnelheid, dus in zoveel kloktikken)

Is de doorvoersnelheid in zulke systemen dan de bottleneck?

Dat weet ik eerlijk gezegd niet. Maar met een hogere bandbreedte heb je natuurlijk ook meer tijd om te verspelen als 'access' time.

Dat weet ik eerlijk gezegd niet. Maar met een hogere bandbreedte heb je natuurlijk ook meer tijd om te verspelen als 'access' time.

Dat gaat alleen op als je per access dermate veel data kunt binnenhalen dat je de access time kunt verbloemen.
In het theoretische geval dat je maar 1 byte per keer inleest, en steeds op een andere pagina, doet bandbreedte er eigenlijk helemaal niet toe, je bent dan voor praktisch de volle 100% afhankelijk van de access time.
In dit geval helpen vooral betere en grotere caches... daarom is het wat droevig om te zien dat de L2-caches van Intels quadcore maar liefst 4x zo groot zijn als die van AMD (2x4 mb vs 4x512 kb).

Ach, blijkbaar is x86 toch 'beter'. Anders zou server-land toch al lang overgestapt zijn op bijvoorbeeld Itanium of PowerPC? Maar die kunnen op veel vlakken gewoon niet concurreren tegen x86.

Dat komt omdat x86 al een voorsprong heeft van 20 jaar. Er wordt gewoon aan vastgehouden omdat men bang is te investeren in iets nieuws. Iets nieuws wat geen zekerheid biedt.

Dit is vergelijkbaar met bedrijven die in hun kelder nog een oude 386 hebben staan met een App geschreven in COBOL en eigelijk niks eraan willen moderniseren onder het mom van "Het werkt nog!"

Een BIOS is oud, maar zo'n groot probleem is het niet momenteel.

Een BIOS is oud en gedateerd. Toevallig stond er een paar maanden geleden op Tweakers een voorstel van Intell geloof ik, dat er een nieuw systeem met flashgeheugen in de maak was. Denk hierbij aan een "nieuwere bios" die meer kan zoals hardware checks, safety checks op je hardware componenten, assistentie met overclocken etc. etc.

Dat komt omdat x86 al een voorsprong heeft van 20 jaar. Er wordt gewoon aan vastgehouden omdat men bang is te investeren in iets nieuws. Iets nieuws wat geen zekerheid biedt.

Zo is het juist niet.
x86 heeft nooit echt veel gedaan in server-land, omdat het niet krachtig genoeg was.
Pas in de tijd van 486 en Pentium kwam x86 een beetje op als file/printserver in Windows-netwerken enzo...
Nog weer later begon x86 een beetje de taken van de grotere unix-systemen over te nemen...

Pas sinds de laatste paar jaren hebben we ook echt multi-CPU x86-systemen en is er 64-bit zodat er ook voor grote databases, websites etc genoeg verwerkingskracht aanwezig is, en de Itaniums, POWERs, PA-RISCs, MIPS, Alpha's etc langzaam maar zeker in het gedrang komen.
x86 is dan wel niet de snelste CPU, maar de prijs/prestaties zijn niet te kloppen... en x86 is aan een flinke inhaalslag bezig. Doordat de office/thuismarkt nu zo groot is, kunnen x86-CPUs enorm snel ontwikkeld worden, en komen de andere bedrijven in een steeds kleinere niche-markt terecht, waar je ook ziet dat de grote namen een voor een de handdoek in de ring gooien, en ofwel de tent sluiten (zoals DEC), of overgaan van 'eigen' systemen naar standaard x86-servers (bv HP, Sun, SGI).

Kortom, server-land stapt JUIST over op x86, dit hebben ze vroeger nooit gebruikt. Vooral omdat x86 'goed genoeg' is, en lekker goedkoop.

In dit geval helpen vooral betere en grotere caches... daarom is het wat droevig om te zien dat de L2-caches van Intels quadcore maar liefst 4x zo groot zijn als die van AMD (2x4 mb vs 4x512 kb).

2x4 mb vs 4x512kb + 1 x 2 tot 4 mb.
vergeet de L3 niet.

daarbij lees je praktische nooit 1 byte uit, en hebben AMD's server in de meeste gevallen een flink lagere latency als die van intel. (FB-Dimm + FSB = niet zo'n geweldige access tijd.)

daarbij denk ik niet dat in jouw voorbeeld grote cache echt veel zullen helpen, als zoals je zegt de data steeds ergens anders vandaan moet komen.
je hebt een hoop entrys van 1 byte nodig om 4x0.5 + 2mb te vullen. veel te veel om allemaal goed voorspelt te hebben ruim van te voren, waardoor je dus alsnog veel in het geheugen moet zijn, ook met 4mb meer cache.

en ja je zal vast wel een voorbeeldje kunnen verzinnen waar wat ik hierboven zeg niet waar is maar dat doet er niet toe want het komt nooit voor.

Een BIOS is oud, maar zo'n groot probleem is het niet momenteel.

Mag dan oud zijn, en in de toekomst mag er misschien een ander naampje aangegeven worden, functies toegevoegd worden of andere veranderingen, maar je ze altijd een Basic Input/Output System nodig hebben om genoeg hardware aan te sturen zodat je je OS kunt laden. Ook een EFI is een BIOS.

2x4 mb vs 4x512kb + 1 x 2 tot 4 mb.
vergeet de L3 niet.

Ik vergeet de L3 niet, maar die wordt gebruikt als 'mirror' van de L2-caches, en is even groot, dus biedt effectief geen meerwaarde qua caching, en is alleen bedoeld voor efficientere syncronisatie tussen de L2-caches.

daarbij lees je praktische nooit 1 byte uit

Nee, dat is de theoretische worst-case... in de praktijk echter is een enkele burst-write doorgaans minimaal 64 bytes, en dat dan dualchannel, dus pas bij meer dan 128 bytes inlezen kun je beginnen aan het terugwinnen van de access-time... en dat is toch wel erg veel, in de praktijk komt het heel vaak voor dat je minder dan 128 bytes per keer leest.

daarbij denk ik niet dat in jouw voorbeeld grote cache echt veel zullen helpen, als zoals je zegt de data steeds ergens anders vandaan moet komen.
je hebt een hoop entrys van 1 byte nodig om 4x0.5 + 2mb te vullen. veel te veel om allemaal goed voorspelt te hebben ruim van te voren, waardoor je dus alsnog veel in het geheugen moet zijn, ook met 4mb meer cache.

Zo werkt een cache niet. Een cache is set-associative. Sowieso hebben alle caches cachelines van 64 bytes, dus dat is je 'primitieve'. Kleiner dan 64 bytes lees je nooit uit en sla je nooit op.
Met brokken van 64 bytes gaat die 2 mb alweer 64 keer zo snel op als met 1 bytes.
Afgezien daarvan zijn de cachelines onderling dus ook nog onderdeel van een 'set', en kun je niet zomaar alle cachelines aan compleet andere geheugengebieden koppelen... Het gaat dus NOG sneller op dan 64 keer. Vooral bij AMD, waar de associativiteit bijzonder laag is, en dus de cache maar in een paar sets en dus een paar geheugengebieden opgedeeld kan worden.
Op deze gebieden is Intel absoluut heer en meester.

Kortom, ik heb niet eens een voorbeeldje nodig, jij moet nog maar eens de handleidingen van AMD en Intel nalezen over hoe hun caches werken, en je mening herzien. Je zit er grofweg een factor 1000 naast qua aantal entries momenteel.

Ik vergeet de L3 niet, maar die wordt gebruikt als 'mirror' van de L2-caches,

waar heb je dat gelezen?

voor zover ik weet word AMD's cache niet inclusive nog exclusive maar een soort hybride oplossing.

daarbij kan de L3 uitgebreid worden en zijn er geen plannen om de L2 uit te breiden, puur als mirror word het dus sowiso niet gebruikt.
dus of exclusive of hybride, in beide gevallen moet je de l3 wel mee tellen.

Kortom, ik heb niet eens een voorbeeldje nodig, jij moet nog maar eens de handleidingen van AMD en Intel nalezen over hoe hun caches werken, en je mening herzien. Je zit er grofweg een factor 1000 naast qua aantal entries momenteel.

goh, dus er zijn dus helemaal niet persee grote caches nodig om het goed te doen in jouw voorbeeld alleen een grote associativiteit,
en ook met grote caches moet je nog steeds vaak in het geheugen zijn.

daarbij heeft alleen AMD's l1 cache een lage associativiteit van 2 waar de L2 cache van AMD gewoon 16 way associative is.
in ruil voor die lage associativiteit in de L1 kan AMD wel 2 reads per cycle uitvoeren waar intel er maar 1 kan doen.
en die lage associativiteit word voor een groot deel gecompenseerd door de 2 keer so grote ruimte die AMD heeft.
zo veel "heer en meester" is intel dus ook weer niet.

goh, dus er zijn dus helemaal geen grotere caches nodig om het goed te doen in jouw voorbeeld alleen een grote associativiteit,

Nee, ik zei groter EN beter, waarbij beter dus oa hogere associativiteit inhoudt, maar ook bv slimmere prefetching, en efficientere write-back, om maar wat te noemen.
Grote associativiteit bij een kleine cache gaat je juist weer opbreken op het moment dat je NIET alleen hele kleine brokjes van allerlei plekken wilt ophalen.
Dus je wilt beiden.

Verder ben je weer lekker bezig... Een post geleden zat je er FINAAL naast, en nu ga je weer gewoon direct over op de volgende sloot onzin alsof er niks gebeurd is. Ga je nou eerst eens verdiepen in de materie, ipv je maar blind staren op AMD.

Deze tests tonen onomstotelijk aan hoe het met de caches van AMD en Intel gesteld is: reviews: Intel Core 2 Extreme QX6700 review
Kun je met geen mogelijkheid in het voordeel van AMD uitleggen. Maar jou kennende zul je toch wel weer een poging willen wagen.

ja natuurlijk ga ik een poging wagen want in die review word de oude k8 met de nieuwe conroe vergelijken.

met de komst van de k8L kan die hele cache vergelijking in de prullenbak want de bandbreedte word verdubbeld naar het zelfde nivo als de conroe namelijk naar 2x 128bit (conroe = 1x256bit).

en kijk, de fx-62 is bijna precies de helft langzamer als de x6800 conroe (het verschil komt vrij goed overeen met het verschil in clocksnelheid)
goh wat zal hier nu gebeuren als de k8L even veel bandbreedte krijgt als de conroe?

en dan kan de K8L ook 2 reads per cycle uitvoeren en zal die scores dus 2 keer hoger uitkomen als nu, en dus ver boven die van de conroe.

dit heb ik als 3 of 4 keer aan je uitgelegd inmiddels maar telkens weer kom je met die zelfde pagina aanzetten.
gaat informatie die intel er niet goed uit doet komen er bij jouw niet in ofzo? heb je echt zo'n bord voor je kop?
goed ik maak fouten maar niet 4 keer de zelfde.

Verder ben je weer lekker bezig... Een post geleden zat je er FINAAL naast,

en jij zat er niet finaal naast? natuurlijk jonge.

Ik heb echt geen fouten gemaakt hoor.
Ik heb Technische Informatica aan de TU Delft gestudeerd... dit is mijn vakgebied.
Jij wist aan de andere kant blijkbaar een paar uur geleden nog niet eens wat een set-associative cache was... en nu doe je weer alsof je de waarheid in pacht hebt. Waarom zou ik je uberhaupt nog serieus nemen?
Ik ga er maar niet meer op in, het is toch hopeloos.
Je zult het zelf wel merken als de K8L uitkomt.
Tot die tijd laat ik je nog maar even in de waan.

Dan wint de Conroe nog steeds, want 100% efficientie is natuurlijk een utopie. Afgezien daarvan liggen de kloksnelheden van de K8L lager (zie dit nieuwsitem), terwij de Conroe tegen die tijd hoger klokt.

ja met luttele procenten zal hij bij de write benchmark nog steeds winnen misschien. hoe cares, in real world applicaties gaan we dat echt niet terug zien.

en "tegen die tijd" is over 2-3 maanden met een beetje geluk. sorry maar de kloksnelheid van de conroe gaat dan niet ineens flink omhoog ofzo, zeker die van de quad cores niet.

Hoe kom je daarbij? De Core2 is volgens dit document ook al 'dual port', dus 2 reads per cycle: http://www.agner.org/optimize/microarchitecture.pdf

dan hebben ze duidelijk iets fout gedaan want hun max read snelheid is het zelfde als de max write, en hij is maar net iets hoger als de max read van de huidige k8's die maar de helft aan bandbreedte heeft.

wat hij wel kan is 1 read en 1 write tegelijk uitvoeren, maar dat kan de k8 ook.
reken maar uit trouwens : 2930mhz * 256bit / 8 = 93.760GB/s
dat zou de maxium lees snelheid moeten zijn als wat jij zegt waar is, maar hij doet maar de helft daarvan.
alleen bij copy komt hij daar in de beurt met 85GB/s

en het zelfde sommetje voor AMD.
2800mhz * 128bit / 8 = 44.800GB/s.
echte score... 43.89GB/s

zelfde som voor intel weer maar nu ervan uit gaande dat ze maar 1 read per keer kunnen doen.
2930 * 128 / 8 = 46.688GB/s
echte score 45.82

beide zitten trouwens maar ongeveer 1GB/s af van hun maximale theoretische bandbreedte. efficiëntie speelt in deze benchmarks duidelijk geen grote rol.

(er staan ook nog 3 interessante bottlenecks in die link van jouw voor de core2 architectuur trouwens, waarvan 1 in ieder geval niet gelden voor de K8L en een andere niet van toepassing is. (p124) )

Ja, kom dan eens met een pagina met K8L-resultaten... oh wacht, AMD houdt angstvallig z'n K8L-samples achter... wat zou daar de motivatie van zijn?...

geen idee, omdat ze het nog niet uit willen brengen. dat is vrij normaal in deze industrie, en zegt dus nog niks.

maar dat 2 keer meer bandbreedte 2 keer zo veel read/write snelheid lijkt me vrij duidelijk (of moet ik nog een sommetje voor je maken?).
alle inefficiëntie zitten al in de oude score verwerkt en met 2 keer meer bandbreedte word hij niet ineens een stuk inefficiënter procentueel gezien. misschien iets maar niet veel.

daarbij zijn dat synthetische tests speciaal gemaakt om zo efficiënt met de cache om te gaan. daar zie je echt niet heel veel terug van een efficiëntere of beter cache systeem, maar eigenlijk bijna alleen de bandbreedte.

als je een punt wilde maken voor het efficiënter zijn van het conroes cache systeem moet je toch echt een andere benchmark zoeken.

Afgezien daarvan zit je er gewoon totaal naast, omdat je ook in deze thread weer duidelijk aantoont geen flauw benul te hebben van hoe een cache werkt, laat staan hoe een complete CPU werkt.

ach rot toch op. je hebt zelf al meerdere fouten gemaakt en blijft de zelfde maken.
daarbij kan ik in tegenstelling tot jouw wel nieuwe dingen leren blijkbaar en is mijn kennis van geheugen en cache systemen inmiddels aardig uitgebreid.

Je hebt nooit meer dan hele oppervlakkige en onsamenhangende verhalen, die bol staan van de vermeende prestaties van een toekomstige AMD-processor en foute aannamen omtrent allerlei huidige en toekomstige technologie.

en die van jouw staan altijd bol van de fouten aannamens over AMD huidige en toekomstige implementaties van verschillende onderdelen en technieken, van cache tot productie processen.

*** edit ****

Ik heb echt geen fouten gemaakt hoor.

right, jouw ego begint echt steeds schrikbarendere vormen aan te nemen.

"Ik vergeet de L3 niet, maar die wordt gebruikt als 'mirror' van de L2-caches"
fout dus. wat zou AMD dan hebben aan CPU's met 6mb L3 cache als er maar 2mb L2 cache op de CPU's zit?

"Hoe kom je daarbij? De Core2 is volgens dit document ook al 'dual port', dus 2 reads per cycle"

goed, dan mag jij mij uitleggen waar de rest van de 95GB/s is gebleven.
misschien dat hij 2 keer 64bit reads can doen per cycle, maar waarom zou intel het daar op limiteren? zeker met een 256bit bus.

moet ik ook nog je grote AMD cache blunder uit een vorige discussie opzoeken?

Jij wist aan de andere kant blijkbaar een paar uur geleden nog niet eens wat een set-associative cache was...

nope ik wist nog niet precies wat dat was nee, wist wel ongeveer wat het was maar niet exact, nu heb ik me er wat in verdiept en weet ik weer wat meer.
en aangezien het alleen geld voor AMD's L1 cache blijft mijn standpunt nog redelijk overeind.
daarbij wijst de praktijk uit dat 2mb of 4mb cache bij de conroe al weinig uit maakt waarom zou het bij AMD veel meer uit moeten maken.

K8L is natuurlijker weer sneller dan K8L, ???

neem aan dat je bedoeld dat de k8l sneller moet zijn dan de k8

Dit is toch geen K8L?, toch? Die kwam toch pas volgende helft van dit jaar.

Dat klopt, maar Core 2 is klok-voor-klok sneller dan K8. K8L is natuurlijker weer sneller dan K8, maar ik denk eigenlijk niet dat die ook sneller is dan Core 2.

Volgens de eerste testen was de K8L gemiddeld 25% sneller per klok dan de C2D met hetzelfde aantal cores. C2D was op zijn beurt weer 25% sneller per klok dan de K8.

eerste testen DOOR AMD ZELF, right?

Doorgaans liegen Intel en AMD in dergelijke tests niet, omdat die tests binnen no-time onafhankelijk gedraaid worden door tech sites. Dit is geen standaard marketing, maar doelbewust op de technologie pro's, en die kun je echt niets wijs maken

Dit is toch geen K8L?, toch? Die kwam toch pas volgende helft van dit jaar.

Ik dacht van wel.

Volgens de eerste testen was de K8L gemiddeld 25% sneller per klok dan de C2D met hetzelfde aantal cores.

Hmm, die test ben ik dan vergeten. Linkje?

Doorgaans liegen Intel en AMD in dergelijke tests niet, omdat die tests binnen no-time onafhankelijk gedraaid worden door tech sites.

Maar het selectief toevoegen/weglaten van bepaalde benchmarks kan wel degelijk een grote invloed op de 'uitkomst' van dat soort tests hebben.

meer ghz zelfde architectuur -> sneller
verschillende architecturen -> zegt nix

en het gaat hier over een vergelijing van 2 verschillende architecturen...

meer ghz zelfde architectuur -> sneller
verschillende architecturen -> zegt nix

Je hebt gelijk, maar eigelijk zou je nog iets verder moeten gaan. x86-64 (AMD) en EM64T (Intel) zijn in weze dezelfde architectuur, een uitbreiding op de x86 architectuur. (Andere voorbeelden van architecturen zijn PowerPC en Sparc)

Dus, in weze:

verschillende core designs -> zegt niets
meer Ghz op dezelfde architectuur -> sneller.

maar eigelijk zou je nog iets verder moeten gaan. x86-64 (AMD) en EM64T (Intel) zijn in weze dezelfde architectuur,

xdcx bedoelde met architectuur al core design.

x86-64 en EM64T zijn instructiesets... ook wel ISA (Instruction Set Archictecture) genoemd.
Met 'gewoon' architectuur bedoelen we doorgaans vooral de implementatie van die instructieset. Die is bv bij de Pentium 4 behoorlijk anders dan bij de Core2 Duo, hoewel beiden EM64T zijn.

dat klopt, maar intel heeft net een nieuwe ontwerp, en heeft dus een TDP gepakt met marges voor te toekomst (headroom), waar AMD daarin tegen met de laatste loodjes bezig is van hun oude ontwerp en dus een groot deel van hun headroom al hebben opgebruikt.