Quadcore Opteron 'Barcelona' komt in vier smaken

Volgens de nieuwste geruchten brengt AMD zoals beloofd in het tweede kwartaal de eerste quadcore Opterons uit. De modelnummers lijken er echter op te wijzen dat de nadruk komt te liggen op servers met één processor.

Drie van de vier chips hebben een nummer dat begint met een '1', wat er op duidt dat ze voor Socket AM2+ bedoeld zijn en dus niet kunnen samenwerken met anderen. De kloksnelheid van deze processors loopt op tot 2,5GHz bij een tdp van 120W. Het laatste model begint wel met de '2' voor dual Socket F-servers, maar opvallend genoeg is dat de zuinigste en minst hoog geklokte uitvoering: dit model zou op 1,9 of 2,0GHz draaien bij een 68W tdp. Op zich zal dit zonder twijfel een goed product zijn - zeker als het aankomt op prestaties per watt - maar waarom AMD niet meteen iets zwaarders inzet in dit segment is onduidelijk.

Model	Socket	Klok	Tdp
Opteron 2258 HE	Socket F	1,9-2,0GHz	68W
Opteron 1266	Socket AM2+	2,1GHz-2,3GHz	95W
Opteron 1268 SE	Socket AM2+	2,4GHz	120W
Opteron 1270 SE	Socket AM2+	2,5GHz	120W

Reacties (84)

[Webdoc]

Het zou best slim zijn van AMD op servers met 1 socket te promoten. Moederborden met 1 socket zijn aanzienlijk goedkoper te maken, en per slot van rekening is dit hetzelfde als 2-3 jaar geleden een systeem met vier sockets, en die begonnen toen (als je alle vier processors in je server had) zo rond de 6-7000 Euro. Prijzen van deze dingen zijn nog niet bekend maar lijkt me dat dit veeeel goedkoper gaat worden

[Verwijderd]

tja ik denk dat je zo altijd wel kunt zeggen dat het een topproduct is. Echter concurreert AMD niet met het verleden maar met Intel en die hebben met de Clovertown toevallig wel een core in huis die in multicpu opstellingen werkt.

En volgens mij valt er nog altijd het meeste te verdienen aan de "veel cpu" systemen dus ik vraag me af of deze lijst compleet is

@hieronder, ik doelde idd op de winstgevendheid niet op de aantallen

[mph_rbi]

En volgens mij valt er nog altijd het meeste te verdienen aan de "veel cpu" systemen dus ik vraag me af of deze lijst compleet is.

Ik denk dat het leeuwendeel van verkochte servers toch single-processor systemen zijn. Multiproc is uiteraard winstgevender, maar de massa (MKB bijv.) heeft geen 8 of 16 cores nodig lijkt mij

[SkizikS]

In aantallen kan dat kloppen maar ik zou de markt in multi CPU servers niet onderschatten bekijk de prijzen maar eens van de huidige xeon/opteron2xxx procs; een groot deel van de prijs zit in de betrouwbaarheid de ze moeten halen in deze markt maar daar zit vast wel een grotere winstmarge aan vast dan bij de opteron 1xx(x) imho.
Verder zitten deze procs in database en webservers daar zijn er vast en zeker veel van

[Dutch2007]

jah zijn compatible MAAR!, je hebt dan maar HT 1.0 ipv de HT3.0 die ze aankunnen... (je mist dus wat functionaliteit)

[mieJas]

HT 1.0 geeft je bandbreedte genoeg op een single socket systeem. Geen nood

[GENETX]

Nee, performance... AMD klapt niet opeens de 64-bit instructieset oid eruit

[Dutch2007]

ook functionaliteit, nml het trug kunne klokken van de 4 cores onafhankelijk d8 ik ergens gelezen te hebben nml....

[Olaf van der Spek]

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

[DavidAxe]

... maar opvallend genoeg is dat de zuinigste en minst hoog geklokte uitvoering: dit model zou op 1,9 of 2,0GHz draaien bij een 68W tdp. Op zich zal dit zonder twijfel een goed product zijn - zeker als het aankomt op prestaties per watt - maar waarom AMD niet meteen iets zwaarders inzet in dit segment is onduidelijk.

Hier ben ik het niet helemaal mee eens. Lang niet alle software zal baat hebben bij zoveel cores en dan is vooral kloksnelheid belangrijk. Bij software die wel zulke hoeveelheden cores optimaal benut, zal er vooral vraag zijn naar zoveelmogelijk cores en is de kloksnelheid wat minder belangrijk. Ook zal bij deze lage TDP meer van dergelijke processoren in een rack zijn te proppen.

[martijnvanegdom]

Nee, maar je vergeet 1 dingetje.. Het OS. Als je 2 zware aps heb die allebei 1 volle cpu trekken, merk je daar op een quad core niks van, op een dualcore loopt je OS als stroop, plus andere progjes die niet echt meer lekker lopen.

Voor mij heeft een quad-core wel zin

1 cpu voor (vm) Windows + IE6
1 cpu voor (vm) Windows + IE7
2 cpu's voor linux en de programma's die dan nog openstaan

Quadcore here I come

[TD-er]

Ik werk hier op een dualcore machine en met 2 VMware instanties, die in deze situatie altijd beide tegelijk bezig zijn, merk ik nog vrij weinig vertragingen. (slim gebruik maken van meerdere hdd's scheelt een hoop)
Ik vraag me dus af hoeveel voordeel quad-core werkelijk gaat brengen, behalve bij de echt multi-threaded apps, zoals WinRAR, diverse MPeg encoders etc.

[mad_max234]

Zijn deze nu wel of niet compatible met AM2 mobo? Als het goed is kan je deze dus gewoon op je AM2 mobo prikken met een bios update zou het moeten werken toch?

Eindelijk een antwoord op al dat intel geweld , kan niet wachten op de resultaten. Ik hoop dat ze echt weer een stuk sneller zijn dan de C2D want dan gaat intel teminsten ook weer van hun luie gat komen. En ga zo maar door. lekker voor ons dus.

[Verwijderd]

Ik kan me niet voorstellen dat deze dingen sneller zijn dan een Core processor.

Er is niks veranderd, alleen wat extra cores.

[Countess]

dat heb je dan helemaal fout.
de K8L is even veel veranderd tov de K8 als de core2 anders is als de core1.
eigenlijk is er vrij weinig over van de orginele k8 core alleen de basis opzet doet nog denken aan de k8, maar verder is hij helemaal vernieuwt.

in floatingpoint gaan ze waarschijnlijk de vloer aanvegen met de core2. over integer performance weten we nog niet genoeg over om daar iets over te zeggen maar het zal waarschijnlijk dicht bij elkaar komen te liggen clock voor clock.

@ mad_max234 : ja deze kan je gewoon een in AM2 mobo stoppen. voor single socket systemen heeft HTT 3.0 niet zo veel zin dus lever je er niks aan performance op in als je geen AM2+ mobo hebt.

[Verwijderd]

Ja inderdaad dat was ik ook net aan het denken

Of het zijn 2 dual-core processors die op socket F 2x2=4 cores hebben

[r.marijnissen]

Het laatste model begint wel met de '2' voor dual Socket F-servers....................

Dus quad cpu x 2= 8 cores.
Daar moet je een mooi servertje op kunnen draaien dacht ik zo.

[Parlor_Inventor]

en ik zeg: data starvation.

Volgens mij is de rek er bij de huidige architecturen echt uit en moet er wel op het diepste niveau iets veranderen omdat het toevoegen van meerdere cores, ook al is de code er voor geoptimaliseerd, niet meer afdoende is. Er moet anders over software gedacht worden.

De Cell bijvoorbeeld is een leuk concept (geen cache maar zelf in te vullen local store, één core die de anderen van taken voorziet) maar eist dus wel dat software niet slechts opnieuw gecompileerd wordt, niet aangepast wordt, maar eigenlijk compleet opnieuw geschreven wordt wil je er echt voordeel uit halen.

Zo ver zal het niet komen vrees ik. De geschiedenis wijst uit dat oude concepten, hoe slecht ook, alleen maar worden uitgebreid en van hogere getalletjes worden voorzien. Waarom zijn we anders nog steeds met x86 bezig? En hebben PC's nog steeds een BIOS?

[MetalMike]

en ik zeg:

[Countess]

AMD64 is juist gemaakt om een aantal van die bottleneck in de oude x86 op te lossen.
als alles straks over is op 64bit kan best een groot deel van de oude "legacy" x86 ondersteuning verdwijnen uit de CPU's bijvoorbeeld.

de reden dat er zelden voor een geheel nieuw ontwerp word gekozen en ze nog minder vaak ook echt aanslaan is de software. er is geen grote verscheidenheid aan software als die voor de x86. waarom zou je daar vanaf willen stappen?

en data starvation zal denk ik erg mee vallen. ddr2-800 dual channel voor 4 cores zou afdoende moeten zijn, zeker met vrij veel cache en onderlinge communicatie via die cache en rechtstreeks via de crossbar.
en bij dual socket system krijg je bij AMD niet 1 keer maar 2 keer dualchannel ddr2-800 geheugen, en met de komst van htt3.0 een hele grote snelle link tussen de beide sockets en geheugen controlers.
elke extra socket betekend dus extra bandbreedte bij AMD.
en nu htt3.0 er is kan AMD dat eigenlijk echt helemaal gaan waar maken, ook met 4 way servers en zelfs 8way servers.

[Olaf van der Spek]

en ik zeg: data starvation.

DDR2 heeft bandbreedte genoeg volgens mij. Zeker voor AMD.

Zo ver zal het niet komen vrees ik.

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.

BIOS

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

[TD-er]

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)

[Olaf van der Spek]

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.

[Verwijderd]

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).

[killingdjef]

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.

[Verwijderd]

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.

[Countess]

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.

[afterburn]

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.

[Verwijderd]

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.

[Countess]

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.

[Verwijderd]

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.

[Countess]

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.

[Verwijderd]

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.

[Countess]

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.

[klakkie.57th]

1 woord virtualisatie.
I kan echt niet wachten op deze quadcores. De rek is er nog lang niet uit.

[Olaf van der Spek]

Maar 2,3 ghz binnen het normale TDP van 95 W. Dat is toch jammer.
Intel heeft al een 2,67 ghz quad-core.

[Verwijderd]

...met als verschil dat de Intel Quadcores een TDP van 130W hebben, dat vergeet je voor het gemak even...

[un1ty]

En laten we even niet vergeten dat het begrip 'tdp' voor intel en AMD verschillen.
voor intel was het het gemiddelde als ik het goed heb.
en voor AMD is het het max. vermogen.

[knirfie244]

De Q6600 heeft maar een TDP van 105 Watt en werkt op 2.4GHz. Daarnaast komt intel dit jaar nog met 45nm quadcore processors, deze zullen waarschijnlijk een stuk zuiniger zijn...

[Wouter Tinus]

Alleen de 2,66GHz desktopversie heeft een 130W TDP, de even snelle Xeon is 120W, de 2,4GHz desktop 105W en de 2,33GHz en lager geklokte Xeons 80W. En dan is er nog de zuinige 1,6GHz/50W-uitvoering.

Edit: nee, Intels TDP is niet het gemiddelde, maar een worst-case scenario gebaseerd op bizar stroomvretende (wel echt bestaande, maar niet nuttige) code, een zogenaamd 'power virus'. Het is dus een praktisch maximum. AMD's TDP is een meer theoretisch maximum gebaseerd op de hoeveelheid stroom die het moederbord moet kunnen leveren. In de praktijk zit er niet zo heel veel verschil tussen sinds de introductie van de Core 2-generatie, beide merken zitten ruim onder hun TDP bij volle belasting: nieuws: Energiemeting van Core 2 Duo en Energy Efficient Athlon

[Verwijderd]

Je mag de gHz van Amd en intel niet zomaar vergelijken, dit is nl niet de enige factor voor prestatie.

[Olaf van der Spek]

Je mag de gHz van Amd en intel niet zomaar vergelijken, dit is nl niet de enige factor voor prestatie.

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.

[SRI]

K8L is natuurlijker weer sneller dan K8L, ???

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

[ferdinand]

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.

[arjankoole]

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

[Verwijderd]

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

[Olaf van der Spek]

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.

[de_nille]

Er is nog niets geweten over de prestaties van barcelona e
Het gaat hier wel over quadcores ook natuurlijk
intels quadcores zijn ook iets lager geklokt als de dualcores
Mss is een 2.1 ghz even snel als een K8 op 3Ghz ofzo
we weten het nog niet, de toekomst zal het wel uitwijzen

[sn33ky]

Ghz-en zeggen niets over de snelheid van de CPU.

[Sir5alL]

Niets is wel erg weinig...

[xdcx]

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

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

[arjankoole]

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.

[Olaf van der Spek]

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.

[Verwijderd]

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.

[yori1989]

Goh ik kan dit 'standaard' bericht wel gaan kopiëren elke keer weer als er nieuws komt over de K8L icm quadcore.


De wattage's zijn het Maximale theoretisch maximaal verbruik.. Het uiteindelijke verbruik zal maximaal 30% lager liggen afhankelijk van de clocksnelheid.

Aangezien je niet altijd 4 cores belast zal je de meeste tijd 2 cores gebruiken.

120:4=30 Watt PER core... aangezien je ze niet altijd volledig belast én ze los van elkaar CnQ kunnen gebruiken zal je dus nog minder verbruiken.

Praktijgebruik per core zal 25 watt(100watt) zijn.. áls ze dus ook nog eens stroom zuinige technieken bij komen kijken zal je dus een idle/halfload verbruik van +- 60 watt hebben én met max-load van 100 tot 120 watt hebben bij het hoogste model van 1 serie

[Rutte]

Niet helemaal correct:
- Intel gebruikt gemiddeld gebruik
- AMD gebruikt maximaal gebruik.

Als je de TDP's van elkaar gaat vergelijken moet je hier zeker rekening mee houden, is nog best een groot verschil

[Countess]

niet helemaal.
intel gebruikt gemiddeld gebruik bij volle belasting.
en AMD gebruikt het theoretische maximum gebruik (dus alle transistoren in de CPU schakelen allemaal tegelijk, iets wat in de praktijk niet voor komt)

[jqv]

en het is bekend dat die TDP's van AMD over het algemeen beter scoren dan die van Intel.

Met de C2D's is dat gat een heel stuk kleiner geworden...

[Countess]

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.

[knirfie244]

Zoveelste keer dat dit verkeerd word gezegd, intel gebruikt geen "gemiddeld" gebruik; Intel's TDP geeft het maximaal gedissipeerde vermogen aan bij standaard gebruik. Dus niet het theoretische maximum van "stel dat nou een keer elke transistor in de chip tegelijk schakelt" van AMD...

[humbug]

So what?

Intels berekening is vergelijkbaar en dit soort getallen worden (even de koeler fabrikanten vergetend) voornamelijk gebruikt voor het vergelijk van de ene processor met de andere. Dat het verwachte gebruik lager ligt is dan ook irrelevant. Een processor met een TDP van 120W verbruikt (ongeveer) 2x zoveel als 1 met een TDP van 60W. En je verhaal veranderd daar niets aan.

[Verwijderd]

Opterons op het ''consumenten'' socket zijn in het verleden ook al leuk geweest (Denkt terug aan de 939 opteronnetjes ) Dus misschien wil AMD weer zo'n situatie hebben? Hopen dat deze beestjes ook lekker overclocken

[Barracuda]

uhm en quad quad core dan?

hier heb ik momenteel weinig aan..., heb nu al 4 quad dual core servers dus qua cores ga ik niet omhoog.

als ik mijn vmware cluster wil uitbreiden wil ik eigenlijk wel naar de 16 of meer cores per host