Pentium 4 en SDRAM, een ramp van formaat?

Column: Pentium 4 en SDRAM, een ramp van formaat?

De Pentium 4 is een maand geleden gereleased, maar vooral door de enorme hoeveelheid artikelen en discussies die er de laatste tijd zijn verschenen op Tweakers.net, lijkt het al een stuk langer geleden. De meeste van deze discussies gingen over de performance van de Pentium 4 vergeleken met de Athlon. De conclusie die we al zoveel keer hebben moeten aanhoren is meestal dat de Pentium 4 inderdaad in een aantal applicaties (soms veel) sneller presteert, maar dat vooral vanwege de prijs de nieuwe processor voor de meeste mensen nog geen oplossing is. Deze hoge prijs is mede te danken aan het Rambus geheugen, op dit moment het enige geheugen dat gebruikt kan worden in samenwerking met de Pentium 4. Naast de kosten van het geheugen, is ook de i850 (Tehama) chipset van Intel ongelooflijk duur.

Veel mensen kijken daarom ook uit naar de eerste SDRAM chipset van Intel voor de Pentium 4: codenaam Brookdale. Intel verwacht dat de Pentium 4 met deze chipset, die in het derde kwartaal van 2001 moet uitkomen, een groot deel van de mainstream markt kan overwinnen. Later, in 2002, zal ook ondersteuning van DDR SDRAM toegepast worden. Maar hoe aantrekkelijk zijn de prestaties van een Pentium 4 met SDRAM eigenlijk? Wat moeten we daarvan verwachten?

Anand Lal Shimpi deed deze week een zeer interessante ontdekking. In de eerdere review van de Pentium 4 die hij geschreven had, liet hij ook de Linpack geheugen benchmark los op verschillende processoren. Hieronder is het resultaat daarvan te zien. Deze benchmark is vooral geschikt om te laten zien hoe een processor kan presteren in applicaties die veel geheugenbandbreedte nodig hebben. Wij concentreren ons op het deel waarbij de datagrootte groter is dan het cachegeheugen van de processor, waar duidelijk te zien is dat de prestaties steeds meer naar een rechte lijn toegaan.

Het valt natuurlijk gelijk op dat de Pentium 4 hier superieure prestaties levert. In eerste instantie is de gedachte dat dit ligt aan het RDRAM geheugen. Dual channel PC800 RDRAM heeft namelijk een data-overdrachtssnelheid van (0,800 * 2 * 2) = 3,2GB/s (de eerste * 2 komt door het 2 bytes brede Rambus kanaal, de tweede doordat er twee kanalen gebruikt worden). Dit sluit perfect aan bij de quad pumped 100MHz bus van de i850, die ook voor een bandbreedte van 3,2GB/s zorgt. Anand wees die theorie echter af, omdat het verschil met de AMD760 met DDR geheugen dan ook veel kleiner zou moeten zijn (ook daar heeft het geheugen een grotere data-overdrachtssnelheid dan normaal gebruikt, en sluiten chipset en geheugen perfect op elkaar aan). Daarom zou dit verschil volgens Anand door de geavanceerde branch prediction van de Pentium 4 komen en is het niet zo afhankelijk van het RDRAM.

In zijn bespreking van de VIA KT133A chipset deze week spreekt hij echter zichzelf tegen. Er wordt niet zoveel over gezegd, aangezien het hier over de Athlon gaat, maar dit keer heeft Anand ook een PC600 RIMM tot zijn beschikking. Een klein rekensommetje leert ons dat dit geheugen met (0,600 * 2 * 2) = 2,4GB/s data kan doorvoeren. Dat is dus, logischerwijs, 25% minder dan bij het PC800 geheugen. Volgens Anand's eerdere theorie zou het effect hiervan op de Linpack benchmarks niet zo verschrikkelijk groot zijn. Maar de performance daalt met dit geheugen bijna 20%! Dit laat dus wel zien dat de Pentium 4 verschrikkelijk afhankelijk is van de geheugenbandbreedte bij deze tests. Als we even door redeneren: PC133 SDRAM heeft een data-overdrachtssnelheid van 1GB/s. Vergeleken met PC800 RDRAM is dat zo'n 69% minder. Een voorzichtige schatting is dan dat de Linpack performance met minimaal 50% daalt (t.o.v. het PC800 RDRAM, en dat lijkt mij nog een zeer optimistische schatting). Teken deze lijn in de nieuwste grafiek van Anand, en het wordt duidelijk dat deze combinatie het qua Linpack performance zelfs in de meest optimistische situatie verliest van de AMD Athlon op de AMD760 en VIA KT133A chipsets. Het komt zelfs verdacht dicht in de buurt bij de Pentium III op een i815 chipset.

In ogenschouw genomen dat in toekomstige applicaties steeds meer geheugenbandbreedte zal worden gebruikt, en dat bijvoorbeeld in Tom's laatste blik op de Pentium 4 wordt gezegd dat het sneller zijn van de P4 bij het coderen van MPEG4 met FlaskMPEG - geoptimaliseerd voor SSE2 - vooral te danken is aan de geheugenbandbreedte, is het veilig om te zeggen dat één van de grote voordelen en prestatie-booster van de Pentium 4 wegvalt bij het gebruik van SDRAM. Heeft de Pentium 4 echt RDRAM nodig om zijn kwaliteiten te laten zien? JA.

Dat maakt in mijn ogen de markt voor de Brookdale chipset erg klein. Er zijn hogere kloksnelheden mogelijk dan met de Pentium III, maar dat moet ook lukken met de nieuwe 0,13micron revisie van de P3. Er is ondersteuning voor SSE2, maar het is nog maar de vraag of dat voor een grote performance boost kan zorgen zonder het snelle Rambus geheugen. De P4 is duidelijk ontworpen om gebruik te maken van die enorme geheugenbandbreedte die zij tot haar beschikking heeft en - sorry, anti-Rambus-mensen - dat zorgt ervoor dat de Pentium 4 gewoon niet tot zijn recht kan komen met SDRAM.

Mijn verwachting is dan ook dat de Rambus-prijzen, ondanks alle perikelen hieromheen, toch sterk zullen gaan dalen dankzij de push van Intel, omdat het kopen van een Pentium 4, ook als er wél SDRAM chipsets beschikbaar zijn, eigenlijk alleen maar zin heeft met RDRAM modules. Als later de DDR SDRAM versie van Brookdale uitkomt kan dat nog een verschil maken, maar reken zelf maar uit wat het verschil in performance t.o.v. Rambus PC800 zal zijn met de 2,1GB/s pieksnelheid die DDR geheugen op het moment bereikt. Behalve als de DDR DIMM's ook spectaculair in prijs gaan dalen, is PC600 dan nog aantrekkelijker bij de Pentium 4. Omwille van de concurrentie hoop ik dat AMD een processor kan ontwikkelen die ook goed gebruik kan maken van een grotere geheugenbandbreedte, want het is duidelijk dat de huidige Athlon niet echt veel met het DDR SDRAM doet.

Disclaimer: Velen zullen als kritiek op dit stukje hebben dat er alleen wordt gekeken naar slechts één, ook nog eens theoretische, benchmark. Maar het is juist de bedoeling dat we hier kijken naar de toekomst en in de toekomst komen zeer waarschijnlijk meer applicaties uit die erg blij zijn met wat meer geheugenbandbreedte (zoals bijvoorbeeld Quake 3). De Linpack benchmark laat erg goed zien hoe processoren gebruik maken van deze bandbreedte bij het doen van floating point berekeningen.

Reacties (44)

Als Intel wil dat de Pentium 4 wel met DDR een succes wordt, is het misschien een idee om een dual channel DDR chipset te bouwen, das 4,2 GB/s , en dan kan die P4 wel gebruike

Dat is eigenlijk wel een leuke optie, alleen zullen de moederborden dan verschrikkelijk duur worden; twee bussen voor 184 pins DDR-SDRAM is een stuk moeilijker op een bord onder te brengen dan 2 RDRAM kanalen (RDRAM telt veel minder pins, is ook maar 16bit breed). Tja, wie weet verovert Rambus toch nog de wereld.

Als mijn geheugen nog goed werkt gaat nVidia dat anders wel doen in hun nog te releasen DDR chipset .

"Can you say 10-layer mobo ?"
Nog meer geld ... pff .. en die P4 is al duur ...

Een klein rekensommetje leert ons dat dit geheugen met (0,600 * 2 * 2) = 2,4GB/s data kan doorvoeren. Dat is dus, logischerwijs, 25% minder dan bij het PC800 geheugen. Volgens Anand's eerdere theorie zou het effect hiervan op de Linpack benchmarks niet zo verschrikkelijk groot zijn. Maar de performance daalt met dit geheugen bijna 20%! Dit laat dus wel zien dat de Pentium 4 verschrikkelijk afhankelijk is van de geheugenbandbreedte bij deze tests.

Zoals al eerder opgemerkt is PC600 RDRAM meer dan 25% langzamer dan PC800 RDRAM, aangezien die getallen een nogal grove afronding zijn. Maar los daarvan, je schrijft hierboven dat als je 25% langzamer geheugen neemt, de performance maar met minder dan 20% daalt in een zeer geheugenspecifieke en -intensieve test. Volgens mij bewijst dat juist dat het geheugen dus NIET allesbepalend is. Want waar komt die 5+% performance anders vandaan die niet verloren gaat?

En voor de toekomst, bandbreedte zal naarmate de kloksnelheid en cacheomvang omhoog gaan steeds belangrijker worden dan latency. Dus het lijkt erop dat SDRAM zijn beste tijd heeft gehad. Want ongeacht wat Femme zegt - de 8-20% performancewinst van DDR is NIET boeiend. Kijk maar naar die Linpack benchmarks, daar blijft het dan al flink achter op de P4.

En voor de toekomst, bandbreedte zal naarmate de kloksnelheid en cacheomvang omhoog gaan steeds belangrijker worden dan latency. Dus het lijkt erop dat SDRAM zijn beste tijd heeft gehad. Want ongeacht wat Femme zegt - de 8-20% performancewinst van DDR is NIET boeiend. Kijk maar naar die Linpack benchmarks, daar blijft het dan al flink achter op de P4.

Wat wil je hier mee zeggen? Die Linpack benchmarks zijn dus totaal niet representatief voor realworld apps. Quake III, MPEG encoding en bepaalde SPECfp en SPECint tests zijn erg geheugenbandbreedte afhankelijk, maar de meestgebruikte applicaties draaien ondanks de gigantische Rambus bandbreedte sneller op een Athlon / AMD 760.

Bij de apps waar de P4 goed scoort is het verschil in clock-voor-clock performance tussen de Athlon/AMD 760 niet eens zo heel groot.

Jij zegt dat geheugen latency op den duur niet meer van belang is. De aanhangers van het DDR platform (InQuest enz.) beweren juist het tegenovergesteld. Volgens hun is de bandbreedte van DDR SDRAM en Rambus _voldoende_ maar blijven latencies altijd een probleem. Daar kan ik me persoonlijk wat meer bij voorstellen dan de stelling dat latencies op termijn niet meer belangrijk zijn. De latencies die de CPU t.o.v. het geheugen ziet nemen alleen maar toe. Dat is funest voor de performance als er een cache misser optreed. Men kan wel lekker de geheugen bandbreedte verhogen, maar als er geen applicaties zijn die daarom vragen dan heb je daar _niks_ aan.

Efficientie is niet belangrijk. Performance is belangrijk. Intel snapt dit, en vindt het daarom geen probleem om een 1.4GHz CPU te leveren die dezelfde performance geeft als een 1GHz CPU van AMD. Want wat zegt dat getalletje nou helemaal? Helemaal niets, hoewel het wel handig kan zijn voor marketing, en dat weten ze bij Intel natuurlijk wel. Dus clock-voor-clock performance is zoiezo niet belangrijk.

Nu over de latency: wat is nou op termijn beter? Een SDR tuinslang waar na 0.1 seconde na het openzetten van de kraan water uitkomt en waar 1 liter per seconde uitkomt, of een Rambus tuinslang waar pas na 1 seconde water uitkomt, maar waar wel 1.5 liter water per seconde uitstroomt?

Om dit te relateren tot cache-missers, na verloop van tijd weet de tuinman vanzelf waar hij moet sproeien en gaat het steeds minder vaak fout Uiteindelijk hoeft de kraan nog maar 1x open.

Wat ik hiermee wil zeggen: de huidige generatie software is nog niet gebaseerd op high-bandwidth geheugen, maar op de karakteristieken van SDRAM: latency laag en niet teveel bandwidth. Als software developers hun software zouden herschrijven zouden ze op basis de kennis dat RDRAM wordt toegepast veel efficientere software kunnen maken.

Het ziet er naaruit dat SDRAM de komende tijd nog zo dominant blijft dat developers dit niet gaan doen en zal SDRAM dus inderdaad de interessantere technologie blijven om toe te passen. Dit komt niet omdat SDRAM beter is, maar door de huidige software en de verdelingen in de markt.

Jij gaat er blijkbaar vanuit dat standaard applicaties om een of andere reden in de toekomst erg veel bandbreedte gaan verstoken. Ik zou niet direct weten waarom mijn browser over 2 jaar zoveel bandbreedte nodig heeft dat je er twee PC800 Rambus channels continu mee vol kunt bursten. Ondertussen zit je wel steeds met die latency penalty.

Je gebruikt je webbrowser ook altijd om te benchmarken wou je zeggen?

Maar zoals ik zei - SDRAM blijft de beste keuze voorlopig omdat dat dus juist *niet* gebeurt. Het is alleen onterecht om te claimen dat SDRAM een betere technologie is dan RDRAM, want dat is simpelweg onwaar. Legacy applicatie en ontwikkelaarsacceptatie zijn de redenen dat SDRAM het beste performed met de huidige applicaties, niet superieure technologie.

Ik ben er daarnaast van overtuigd dat RDRAM in wat voor vorm dan ook in de toekomst wel terug zal komen als standaard. Kijk naar bijv. USB en FireWire, dit zijn soortgelijke technologieeen en ook stukken beter dan hun alternatieven (Serieel? Parallel?)

[voor wie het zich afvraagt, ik reageer op mezelf omdat ik niet op de post van Femme direct meer kan reageren, dieptemaximum overschreden ofzo.]

Ik anders wel

Leuke column, je hebt alleen de artikelen niet goed gelezen.

Er wordt eea nl duidelijk uitgelegd: P4 is ontwikkeld met hoge bandbreedte van RDRAM in het achterhoofd. Deze gebruikt dat dus dan ook op een effectieve manier. P3 was dit niet, daarom kan een P3 dan ook niet effectief met RDRAM omgaan.

Athlon is netzoals de P3 niet ontwikkeld met de brandbreedte van, in dit geval, DDR SDRAM, vandaar dat de scores van de Athlon op dit moment een vergelijkbaar (teleurstellend) resultaat geven als de P3 met RDRAM doet.

Er wordt vervolgens geconcludeerd (en in mijn ogen terecht) dat DDR SDRAM pas echt door zal dringen op het moment dat de opvolger van de Athlon daar is, omdat deze netzoals de P4 ontwikkeld zal zijn om gebruikt te kunnen maken van de hogere bandbreedte.

DDR SDRAM zal wel kunnen laten zien wat het kan op het moment dat de VIA DDR P4 chipsets daar zijn, en die zullen dan waarschijnlijk eenzelfde soort plaatje laten zien tov de Athlon.

DDR SDRAM voor de Athlon heeft op dit moment dus hetzelfde probleem als RDRAM tot voorkort had met de P3: wel bandbreedte, maar geen CPU die er iets mee kan.

Dit is iets heel anders dan wat jij met je column probeert te suggeren, dus nogmaals, beter lezen en begrijpen wat er wordt geschreven.

Ehm... ik geloof dat jij mijn artikel niet helemaal goed hebt gelezen.

P4 is ontwikkeld met hoge bandbreedte van RDRAM in het achterhoofd. Deze gebruikt dat dus dan ook op een effectieve manier.
P3 was dit niet, daarom kan een P3 dan ook niet effectief met RDRAM omgaan.
Athlon is netzoals de P3 niet ontwikkeld met de brandbreedte van, in dit geval, DDR SDRAM, vandaar dat de scores van de Athlon op dit moment een vergelijkbaar (teleurstellend) resultaat geven als de P3 met RDRAM doet.

Dat zeg ik toch?

Ik heb het hier het grootste deel over normaal PC133 SDRAM, en niet over DDR SDRAM. Volgens mij zie jij overal 'DDR' staan, waar ik toch echt 'SDRAM' schrijf. Alle dingen die jij in deze reactie zegt, staan ook zo (of in ieder geval niet het tegendeel) in mijn artikel. Jouw reactie gaat helemaal niet over de effecten van SDRAM op de P4 prestaties, maar over DDR SDRAM op de P4 en Athlon (en ik heb het helemaal niet over de Athlon).

Het enige wat ik kan concluderen uit jouw reactie is dat je de andere artikelen, net als ik, goed hebt gelezen, maar dat je in mijn artikel kennelijk wat alinea's hebt overgeslagen.

Whoopsie daisy, je hebt gelijk. Iets te snel gereageerd iid. Mijn lapje tekst klopt wel, maar de kritiek in jou richting is idd niet geheel terecht.

Goede column! ben het wel met je eens, maar ook wel een beetje met anand. Ik denk dat je dit als conclusietje kan trekken. Erg veel bandbreedte is fijn, maar als de branchprediction niet goed is heb je er niet veel aan. Ik denk dat je daarmee ook de slechte prestaties van de DDR chipsets mee kan verklaren. denk dat het verschil tussen een Palomino op de KT133A en eentje op bijv de AMD 760 veel groter zal zijn, dan als je op beide thunderbirds prikt.

Hoezo presteren de DDR chipsets slecht? 8-20% extra performance vind ik niet fout. De maximale bandbreedte kan minder efficiënt benut worden als bij Rambus, maar daar staat tegenover dat DDR lagere latencies heeft.

De prijzen (ander verhaal) zijn nu al op Rambus niveau terwijl er nog nauwelijks DDR mobo's worden verkocht.

Femme je spreekt jezelf tegen

De maximale bandbreedte kan minder efficiënt benut worden als bij Rambus, maar daar staat tegenover dat DDR lagere latencies heeft.

Doordat DDR zulke lage en Rambus zulke hoge latencies heeft kan DDR zijn bandbreedte dus beter gebruiken dan Rambus in de praktijk (uitgezonderd Photoshop en dat soort proggies)

[little joke]
lijkt mij nou niet fijn als proc om 17 cycles te moeten wachten op mijn burst, beetje vergelijkbaar met een rotje, eerst een kwartier wachten tot dat lontje afgebrand is en dan die 'burst'
[/little joke]

Ik bedoel burstrates. Rambus haalt hier een hoger rendement.

Mensen vergeten we niet gewoon het allergrootste probleem van Rambus?

De latency van rdram is 17 cycles and up
(hangt van aantal rimms af)

De branchprediction van de P4 heeft een positieve invloed, niet vanwege de bandwithproblemen maar vanwegen de latencyproblemen, daarom scoort p4 met SDram slecht, latency is laag genoeg, maar de bandwith...

Dat pc600 zo slecht presteerd komt omdat het niet op "600" Mhz werk maar slechts op 249
(of daaromtent)
zodat de latency bijna 2x zo hoog wordt tov pc800, en daar kan zelfs de branchprediction van de p4 niet tegenop.

Over dat de Athlon de bandwith van DDR niet kon benutten:
BULLSHIT (boel)
De Athlon heeft een 200Mhz bus en wordt dus alleen maar gehinderd door het langzame SDram,
De athlon komt pas los met DDR,
(vroege) test wijzen al een performanceboost aan van 17% aan, en dat wordt nog meer als de 333Mhz bus en pc2600 gereleased worden, evt in combinatie met dual-channel (Nvidia Crush?)

* 786562 stefana3a

Je slaat hier de plank enigsinds mis:
Recente testen met de kt133A, die de athlon kan draaien op 133mhz (ddr) FSB, laten een prestatie winst zien ten opzichte van de 100mhz (ddr) bus met de oude kt133 die zeer dicht bij de amd 760 ddr in de buurt komt.

Dit laat zien dat de athlon tot zijn recht komt bij hoge FSB, niet zo zeer bij de hogere bandbreedte van geheugen.

De geheugenbus kan op 266MHz FSB synchroon lopen aan de FSB. Dit zou de sterke snelheidstoename van de KT133A chipset kunnen verklaren.

Zou kunnen, maar dan zou je verwachten dat een pc100/athlon combinatie niet veel zou onderdoen in performance voor een pc133/athlon combinatie wat wel het geval is.


Voorbeeldje: geheugenaanvraag (zonder verzenden)stel je hebt: (sysbus/procbus, in Mhz)
referentiespeed: 1Ghz (10 ticks= 1/100.000.000 sec)

100/200 (100 ddr) 2-2-2,
proc doet geheugenaanvraag: 10 ticks
geheugen reageert: 20
wachttijd: 0
totaal: 30

100/200 3-3-3
proc doet geheugenaanvraag: 10 ticks
geheugen reageert: 30
wachttijd: 0
totaal: 40

133/200 2-2-2
proc doet geheugenaanvraag: 8 ticks
geheugen reageert: 20
wachttijd: 1
totaal: 29

133/200 3-3-3
proc doet geheugenaanvraag: 8 ticks
geheugen reageert: 30
wachttijd: 1
totaal: 39

133/266 2-2-2
proc doet geheugenaanvraag: 8 ticks
geheugen reageert: 20
wachttijd: 0
totaal: 28

133/266 3-3-3
proc doet geheugenaanvraag: 8 ticks
geheugen reageert: 30
wachttijd: 0
totaal: 38

* 786562 stefana3a

Je kijkt hier alleen naar latencies (in dit is nog maar het halve verhaal). Met verzenden kom je bij 32 bytes transfer op iets van:

133/133 CAS2:
CAS latency: 15ns
Critical Word latency: 7,5ns
System latency: 4x7,5ns
Transfer latency: 3x7,5ns (er moet nog 3x8 bytes over de bus)
Async penalty: 0ns
Totaal: 75ns
Bus (133MHz) wachttijd: 10 cycles
Effectieve bus bandbreedte: 426MB/s
Proc wachttijd: 100 cycles

100/200 CAS2:
CAS latency: 20ns
Critical Word latency: 10ns
System latency: 10ns + 2x10ns + 5ns (data op dubbele snelheid, adres niet)
Transfer latency: 3x10ns
Async penalty: 0ns
Totaal: 95ns
Bus (200/MHz FSB) wachttijd: 19 cycles
Effectieve bus bandbreedte: 337MB/s
Proc wachttijd: 95 cycles

133/200 CAS2 (VIA KT133):
CAS latency: 15ns
Critical Word latency: 7,5ns
System latency: 10ns + 2x7,5ns + 5ns (data op dubbele snelheid, adres niet)
Transfer latency: 3x7,5ns
Async penalty: 5ns
Totaal: 80ns
Bus (200MHz FSB) wachttijd: 16 cycles
Effectieve bus bandbreedte: 400MB/s
Proc wachttijd: 80 cycles

133/266 CAS2 (VIA KT133A):
CAS latency: 15ns
Critical Word latency: 7,5ns
System latency: 2x7,5ns + 2x3,75ns (data op dubbele snelheid, adres niet)
Transfer latency: 3x7,5ns
Async penalty: 0ns
Totaal: 67,5ns
Bus (266MHz FSB) wachttijd: 18 cycles
Effectieve bus bandbreedte: 473MB/s
Proc wachttijd: 68 cycles

266/266 CAS2 (AMD 760):
CAS latency: 7,5ns
Critical Word latency: 3,75ns
System latency: 2x7,5ns + 2x3,75ns (data op dubbele snelheid, adres niet)
Transfer latency: 3x3,75ns
Async penalty: 0ns
Totaal: 45ns
Bus (266MHz FSB) wachttijd: 12 cycles
Effectieve bus bandbreedte: 709MB/s
Proc wachttijd: 45 cycles

266/266 CAS2.5 (AMD 760 reference systemen):
CAS latency: 9,375ns
Critical Word latency: 3,75ns
System latency: 2x7,5ns + 2x3,75ns (data op dubbele snelheid, adres niet)
Transfer latency: 3x3,75ns
Async penalty: 0ns
Totaal: 46,875ns
Bus (266MHz FSB) wachttijd: 14 cycles
Effectieve bus bandbreedte: 608MB/s
Proc wachttijd: 53 cycles

Ik weet niet zeker of dit allemaal klopt, maar het komt wel overeen met de werkelijkheid (KT133 performance ligt precies tussen AMD760/PC2100 CAS2.5 en KT133/PC133). De bandbreedte berekening komt ook redelijk overeen met de benchmarks van AnandTech.

idd je hebt gelijk, maar ik probeerde het nog een klein beetje begrijpbaar te houden voor de
mensen die hier de b*llen van snappen

Ik heb in die thread van Anand over de KT133A zijn eigen benchmarks nog eens nagerekend en hierbij bleek dat de maximale winst (bij 4 geteste games) van de KT133A tov de KT133 (266/133 vs. 200/133 FSB/mem) 6,8% was. Dit is dus de bijdrage van de hogere FSB, maar ook van het feit dat het 133 MHz ram synchroon kon gaan lopen, wat ook winst oplevert.
In diezelfde benchmarks bleek dat de AMD 760 tov de KT133A (266/266 vs 266/133) maximaal 7,8% sneller was.

De Athlon kan dus wel degelijk aardig profiteren van DDR geheugen en niet alleen van de FSB.

Maar het komt hoe dan ook niet in de buurt van winst die de P4 pakt met dual channel Rambus. De vraag is of je je daar de komende anderhalf jaar druk om moet gaan maken, want waar de P4 zijn winst pakt is toch vooral in speciaal op de P4 aangepaste software. Er zal voorlopig nog geen real-life software komen die zich gedraagt zoals Linpack.
----------
ontopic: maar een P4 met SDRAM zou wel een ramp zijn. De P4 doet het dan niet alleen slecht met de huidige software, maar profiteert ook niet van aangepaste software.

En JIJ kan niet lezen, als we weer beledigend moeten doen.

Wat jij daar zegt heb ik ook gezegd, ik heb alleen de synchroniteit niet duidelijk vermeld, maar als ware tweaker moet je toch weten dat pc2600 op 333Mhz loopt,

Uhhh..... ligt het aan mij of denk ik als enige dat een column totaal iets anders is?

Overigens... goed gedaan.

Tsjah, ben ik wel met je eens...

Een column is iets persoonlijks, waar de schrijver zijn visie op zaken geeft.... Men hanteert hierbij niet zozeer de "wij-vorm", maar de "ik-vorm"...

Dit is gewoon een technisch review met een persoonlijk tintje (min-of-meer)...

Desalniettemin: een zeer interessant stuk...alleen geen column...

Intel had toch een deal gesloten met rambus om alleen rambus te ondersteunen bij de P4? of heb ik het mis?

En in ruil daarvoor hoefden ze die licentiekosten van Rambus niet te betalen geloof ik... Maar waarschijnlijk kost het niet supporten van SDRAM ze meer geld dan die licentiekosten, dus kiezen ze toch maar eieren voor hun geld

Daarom zou dit verschil volgens Anand door de geavanceerde branch prediction van de Pentium 4 komen en is het niet zo afhankelijk van het RDRAM.

Vreemde conclusie van Anand: waarom zou een benchmark die data-overdrachtssnelheid moet meten moeilijk voorspelbare branches bevatten?

deze quote gaat over de verschillen vd 760 en i850 en niet direct over het branchmarkprogramma

Mwaah, ik denk niet dat een p4 in combinatie met sdram zo'n geslaagde optie is (en velen met mij), naast het snelheidsprobleem zullen de prijzen van ddr-sdram tegen die tijd al zo laag zijn (IMHO ) dat een athlon met ddr-sdram een veel fijnere/snellere configuratie is!

Het is nu alleen nog moeilijk in te schatten in hoeverre de P4 baat heeft van de lagere latencies van DDR SDRAM. De P4 scoort nu eigenlijk alleen goed in benchmarks waarbij geheugenbandbreedte belangrijk is. In alle andere benchmarks zijn de prestaties vaak erg slecht. Die benchmarks (SysMark e.d., geheugenbandbreedte is daar niet echt van belang - DDR zou iig voldoende moeten zijn) zouden wel eens kunnen profiteren van SDRAM.

De latency van rdram is 17 cycles and up
(hangt van aantal rimms af)

De branchprediction van de P4 heeft een positieve invloed, niet vanwege de bandwithproblemen maar vanwegen de latencyproblemen, daarom scoort p4 met SDram slecht, latency is laag genoeg, maar de bandwith...

* 786562 stefana3a

edit:

zpelvaudje
quote overigens van mezelf (ongeveer een meter hoger)