DDR VS DDR2 icm C2D E6400

[Lumics]

Mensen ik zit met een dillemma:

Ik heb in mijn pc 2 x 512 MB PC3200 DDR (Veritec (no-name dus) geheugen.

Mijn moederboard (Asrock 775Dual vsta) kan ook ddr2 geheugen pakken.

Nou is er iemand die 1 x 1GB DDR2 PC5300 CL5 Kingston geheugen wil ruilen tegen mijn 2 x 512 DDR Geheugen. Omdat ik graag een nwe moederboardje wil in de nabije toekomst vraag ik mij af of dit een goede deal is.

Momenteel kan ik dus dual channel draaien. Als ik dat ene reepje DDR2 erin gooi, zou ik dus maar single channel kunnen gebruiken. Zou dit in de praktijk merkbaar zijn?

Of zeggen jullie, goede deal, ruilen!

Rest van het systeem:

C2D 6400
Asrock 775Dual Vsta
Msi 7900GTO
Sata + IDE HD.

[Jird]

het verschil single channel - dual channel is zeker merkbaar, hoe zwaarder de programma's die je draait hoe meer je het merkt. gezien je videokaart verwacht ik dat je wel games speelt en daarin zul je het best merken. maar, aangezien je binnenkort toch een nieuw moederbord wilt aanschaffen en je daar (waarschijnlijk, geen idee welk je wilt kopen) alleen DDR2 in kan proppen zou ik het persoonlijk zelf wel doen. je hoeft dan bij dat moederbord nog maar 1 latje geheugen te kopen ipv 2.

just my 2 cents

[RoD]

Met dat DDR geheugen heb je sowieso maar maximaal PC3200. Je krijgt er dus PC5300 met meer bandbreedte voor terug. Je levert dan dual channel in, maar dat wordt dus grotendeels gecompenseerd door het snellere PC5300 geheugen. Bovendien geeft een bottleneck aan bandbreedte door het geheugen niet zo gek veel performanceloss bij de C2D. Zoek maar eens naar wat reviews.

[Lumics]

RoD schreef op zondag 31 december 2006 @ 13:44:
Met dat DDR geheugen heb je sowieso maar maximaal PC3200. Je krijgt er dus PC5300 met meer bandbreedte voor terug. Je levert dan dual channel in, maar dat wordt dus grotendeels gecompenseerd door het snellere PC5300 geheugen. Bovendien geeft een bottleneck aan bandbreedte door het geheugen niet zo gek veel performanceloss bij de C2D. Zoek maar eens naar wat reviews.

Ik zal eens even zoeken op wat reviews. Ook zag ik hetzelde geheugen bij Alternate voor 115e staan.
Dus mocht ik idd performance loss ervaren, zou een extra reepje DDR2 ook een oplossing kunnen zijn.

[Verwijderd]

RoD schreef op zondag 31 december 2006 @ 13:44:
Met dat DDR geheugen heb je sowieso maar maximaal PC3200. Je krijgt er dus PC5300 met meer bandbreedte voor terug. Je levert dan dual channel in, maar dat wordt dus grotendeels gecompenseerd door het snellere PC5300 geheugen. Bovendien geeft een bottleneck aan bandbreedte door het geheugen niet zo gek veel performanceloss bij de C2D. Zoek maar eens naar wat reviews.

Is de grap van dual channel niet dat je uit 2xPC3200 effectief PC6400 (6,4GB/s) haalt? 1x PC5300 geeft dus maar 5,3 GB/s wat dus een lagere geheugenbandbreedte betekent. Als je er later dan nog een reepje PC5300 bij zet verdubbel je dat wel weer

[RoD]

Verwijderd schreef op zondag 31 december 2006 @ 13:56:
[...]

Is de grap van dual channel niet dat je uit 2xPC3200 effectief PC6400 (6,4GB/s) haalt? 1x PC5300 geeft dus maar 5,3 GB/s wat dus een lagere geheugenbandbreedte betekent. Als je er later dan nog een reepje PC5300 bij zet verdubbel je dat wel weer

Ik zeg ook dat het deels gecompenseerd wordt En mede door het feit dat het performanceverschil niet groot is, is een upgrade naar het nieuwere DDR2 (en tevens makkelijker upgradebaar doordat het een 1GB latje is) wel zinvol.

[Lumics]

Dan is voor mij de vraag, zou ik dat voorlopig echt merken die 1,1 Gig transmissie snelheid?

[Lumics]

Nou ik heb de ruil voltooid. En het werkt allemaal prima. De 3dmark scores zijn lichtelijk verbeterd.
Ik vraag me nu alleen af of het zin heeft om nog een gig erbij te gooien. Waarin zal ik het prestatie verschil vooral in merken?

[3DDude]

Lumics schreef op dinsdag 02 januari 2007 @ 21:38:
Nou ik heb de ruil voltooid. En het werkt allemaal prima. De 3dmark scores zijn lichtelijk verbeterd.
Ik vraag me nu alleen af of het zin heeft om nog een gig erbij te gooien. Waarin zal ik het prestatie verschil vooral in merken?

jah 1 erbij heb je 2GB geheugen loopt lekker soepel met C2D, en kan je dat weer dual channel draaien, waardoor je genoeg bandbreedte krijgt. als je er geld voor (over) hebt gewoon doen!

[BlackWolf666]

Weten jullie zeker dat die hoge timings gecompenseerd worden door de frequentie van DDR2 geheugen?? Ik betwijfel het..

[JeroenNietDoen]

Jah met DDR2 hoef je niet meer op je latencies te testen. Geilen op Cas3/4 is er niet meer bij, die verschillen zijn zeer minimaal en IMHO het geld niet meer waard.

Maar het blijft leuk om van die dodo's te zien patsen met hun CAS4

[Capi]

Correct me when im wrong, maar is het niet zo dat je dual channel alleen werkt als je een kit koopt, dus dezelfde types.

Dat je er niet gewoon ieder latje van 1gb naast kan prikken toch?

[GH45T]

Kaap schreef op woensdag 03 januari 2007 @ 11:05:
Jah met DDR2 hoef je niet meer op je latencies te testen. Geilen op Cas3/4 is er niet meer bij, die verschillen zijn zeer minimaal en IMHO het geld niet meer waard.

Maar het blijft leuk om van die dodo's te zien patsen met hun CAS4

Sorry hoor, maar zelfs op Athlon XP systemen waar het CAS verschil toch erg belangrijk was volgens velen heb ik het verschil niet echt gezien bij dagelijkse werkzaamheden. Het maakte wel *iets* uit maar als je zag wat je meer kwijt was...

De hoge latency's van DDR2 geheugen worden grotendeels gecompenseerd door de hogere kloksnelheden. Latency's worden dan ook in relatief uitgedrukt, PC 6400 DDR2 CAS4 heeft dezelfde absolute latency als PC 3200 DDR CAS2.

Maar goed, ook DDR2 vind ik behoorlijk overdreven op het moment. Ik heb zelf 4 modules van 512 MB PC3200 DDR in dual channel en dat draait echt als een speer. Hogere geheugensnelheden zijn maar zeer marginaal merkbaar terwijl je er de hoofdprijs voor betaald, zeker op dit moment. Als je extreem wilt gaan overklokken, dan wordt het pas interessant om ook daadwerkelijk snel geheugen te hebben.

TonyDeZiekePony schreef op woensdag 03 januari 2007 @ 11:10:
Correct me when im wrong, maar is het niet zo dat je dual channel alleen werkt als je een kit koopt, dus dezelfde types.

Dat je er niet gewoon ieder latje van 1gb naast kan prikken toch?

Wordt wel aangeraden, kan ook uitmaken maar is niet noodzakelijk. Zoals ik al zei heb ik 4 modules in Dual channel en dit zijn 3 verschillende merken en types modules door elkaar. De identieke zijn ook geen dual channel kitje, wel uit dezelfde batch overigens.

[ Voor 19% gewijzigd door GH45T op 03-01-2007 11:14 ]

[_the_crow_]

BlackWolf666 schreef op dinsdag 02 januari 2007 @ 22:07:
Weten jullie zeker dat die hoge timings gecompenseerd worden door de frequentie van DDR2 geheugen?? Ik betwijfel het..

De timings zijn relatief ongeveer gelijk gebleven. CL5 met PC5300 is qua lantency ongeveer gelijk aan CL3 op PC3200. Timings worden ook relatief uitgedrukt. Namelijk in clockcycles.

[Lumics]

TonyDeZiekePony schreef op woensdag 03 januari 2007 @ 11:10:
Correct me when im wrong, maar is het niet zo dat je dual channel alleen werkt als je een kit koopt, dus dezelfde types.

Dat je er niet gewoon ieder latje van 1gb naast kan prikken toch?

Ik was wel van plan om er dan hetzelfde merk/type naast te zetten. dat is hetzelfde als een kitje. Maar dan misschien uit een andere serie. Maakt niet uit.

[Verwijderd]

Volgens mij maakt de grote en geavanceerde cache van de Core2 Duo het verschil.
Op een Pentium 4/D merk je wel aardig wat van de latencies van DDR2-geheugen, omdat die cache minder goed kan voorspellen wat er uit het geheugen gehaald moet worden.
Hoe traag de toegang tot je geheugen ook is, als je maar vroeg genoeg begint met binnenhalen maakt het niet uit.
Of zoals Cruijff het verwoordt: Als je te laat bent, moet je eerder vertrekken.

Over die dual-channel kits trouwens...
Je *hoeft* niet per se een enkel kitje te hebben. Wat je wel moet hebben is twee reepjes van dezelfde capaciteit, en grofweg dezelfde specificaties. De zwaktste schakel bepaalt de kloksnelheid en latencies die je kunt gebruiken.
En er zijn ook uitzonderlijke gevallen waar geheugen niet op een bepaald moederbord werkt, of niet in combinatie met geheugen van een ander type, omdat de elektrische specificaties niet 100% kloppen. Maar volgens mij is dat niet meer zo'n issue de laatste tijd.

[Croga]

Verwijderd schreef op woensdag 03 januari 2007 @ 23:01:
Op een Pentium 4/D merk je wel aardig wat van de latencies van DDR2-geheugen, omdat die cache minder goed kan voorspellen wat er uit het geheugen gehaald moet worden.

Dit verhaal zit natuurlijk nog een heel stuk ingewikkelder in elkaar.....

Doordat de P4/D een langer pipeline heeft, zal een vergissing in de prediction logic (waardoor de pipeline helemaal opnieuw gevuld moet worden) een burst-retrieve op het geheugen tot gevolg hebben. Hierdoor is een grote geheugen bandbreedte veel belangrijker dan bij de C2D/Athlons. Tegelijk zorgt het er ook voor dat lage latency bij de P4/D veel minder belangrijk is dan bij de C2D/Athlons.

Ofwel: Juist bij de P4/D zijn de latencies veel minder belangrijk. Bij de C2D blijkt uit tests ook iedere keer weer dat meer bandbreedte betere resultaten levert dan lagere latencies terwijl juist de Athlon64s meer uit lage latencies halen (dat heeft dan weer te maken met de ingebouwde geheugen controller. De P4/D/C2D moet nog wat extra latency van de communicatie met de NB slikken waardoor het effect van lage latency vermindert wordt; de Ath64 heeft daar minder last van)

Afijn.... Het zijn allemaal vrij ingewikkelde verhalen

[Verwijderd]

Sorry, maar daar ben ik het absoluut niet mee eens.
Wat jij beschrijft is wat er gebeurt met branch misses, en dat heeft weinig te maken met het geheugen.
De cache is in principe niet afhankelijk van de pipeline-lengte, afgezien van het feit dat je iets eerder je lees-operaties moet starten. Maar zolang je het goed kunt voorspellen, kun je dus de latency maskeren.
De C2D is daar alleen beter in dan de P4.
Verder loopt de P4 ook op een hogere kloksnelheid, dus in absolute zin is het verschil in pipeline-lengte veel kleiner, uitgedrukt in doorlooptijd, en dus het tijdstip wanneer de voorspelling gedaan moet worden.
Het zou wel kunnen dat de kortere pipeline van de C2D het makkelijker maakt om juiste voorspellingen te doen, maar dat is lastig te bepalen.

Tests geven ook juist aan dat de C2D er minder gevoelig voor is dan de P4, dus jouw verhaal klopt ook niet met praktijkresultaten.

Over de Athlon ben ik het ook niet eens. Hij is vooral gevoelig voor de geheugenlatencies omdat de cache niet zo efficient is. Zou de cache net als de C2D beter voorspellen wat hij moet inladen en wegschrijven (en minder onnodige operaties vanwege de exclusive caching), dan zou de latency ook beter verhuld kunnen worden.
Maar juist omdat de cache relatief weinig doet bij een Athlon (in veel gevallen maakt 1 mb vs 512 kb ook weinig tot niks uit), heeft het geheugen een directer effect op de prestaties.
In feite hetzelfde verhaal als bij de P4... Behalve dan dat de latencies bij de P4 in absolute zin groter zijn.
Maar bij de Core2 Duo zijn de latencies juist praktisch hetzelfde als bij de P4, er wordt immers gebruik gemaakt van dezelfde moederborden. De cache maakt het grote verschil.
De pipeline heeft vooral effect op de latency van de cache, maar die is een stuk lager dan die van het geheugen, dus niet zo relevant voor de geheugenlatencies: reviews: Intel Core 2 Extreme QX6700 review
Dat scheelt ruim een factor 10.

[Croga]

Verwijderd schreef op donderdag 04 januari 2007 @ 00:37:
Wat jij beschrijft is wat er gebeurt met branch misses, en dat heeft weinig te maken met het geheugen.
De cache is in principe niet afhankelijk van de pipeline-lengte, afgezien van het feit dat je iets eerder je lees-operaties moet starten. Maar zolang je het goed kunt voorspellen, kun je dus de latency maskeren.

Als je kijkt naar de werking van cache zal de vulling van de cache voor een groot deel afhankelijk zijn van de branch prediction. Branch prediction vult de pipeline met de instructies die het meest waarschijnlijk als volgende uitgevoerd moeten worden. Vervolgens wordt de cache gevuld met de bijbehorende data. Een miss in de prediction logic zorgt er dus automatisch voor dat een groot deel van de data in de cache ook opnieuw geladen moet worden.
Dit is zo'n beetje het meest belangrijke punt in de hele discussie: Branch prediction heeft een direct effect op de efficientie van de cache en daarmee automatisch ook op hoe er met het geheugen om gegaan wordt.

Goed voorspellen scheelt je dus zowel in benodigde bandbreedte als in latency. Als branch prediction altijd de juiste voorspelling zou doen, zouden we allemaal met PC133 CL5 toe kunnen. Helaas is dat niet zo......

Verder loopt de P4 ook op een hogere kloksnelheid, dus in absolute zin is het verschil in pipeline-lengte veel kleiner, uitgedrukt in doorlooptijd, en dus het tijdstip wanneer de voorspelling gedaan moet worden.

Ja, zo werkt het dus niet....
C2D en Ath64 voeren veel meer instructies per clockcycle uit dan P4. De pipeline bestaat uit instructies. Die paar extra megahertzen gaan daar dus niet helpen. Resultaat: De predictors van de C2D en Ath64 hebben het vele malen drukker dan die van de P4. In absolute zit is de pipeline lengte van de P4, uitgedrukt in doorlooptijd, dus ook veel langer.
Doorlooptijd = lengte / IPC / snelheid. Lengte is bij de P4 veel langer, IPC is kleiner, snelheid is iets groter. Doorlooptijd is bij de P4 dus langer.

Het zou wel kunnen dat de kortere pipeline van de C2D het makkelijker maakt om juiste voorspellingen te doen, maar dat is lastig te bepalen.

Nee, de kortere pipeline zal het niet makkelijker maken voorspellingen te doen. De kortere pipeline zorgt er echter wel voor dat de performance hit door een prediction miss kleiner zal zijn aangezien het herladen van de pipeline minder tijd/werk kost.

Tests geven ook juist aan dat de C2D er minder gevoelig voor is dan de P4, dus jouw verhaal klopt ook niet met praktijkresultaten.

Waarvoor is de C2D precies minder gevoelig? De C2D is duidelijk minder gevoelig voor brute geheugen-transfer snelheid. Dat heeft alles te maken met wat er hiervoor geconstateerd is (kortere pipeline dus bij miss prediction minder data die uit de cache gegooid hoeft te worden).

reviews: Intel Core 2 Extreme QX6700 review

Let goed op deze link. Als je goed kijkt zul je zien dat de totale geheugen latency bij de Athlon64 zo'n 10ns onder de C2D ligt. Een verhoging van de latency op het geheugen zelf zal dus relatief meer performance kosten op een Ath64 dan op een C2D/P4.

[Verwijderd]

Croga schreef op donderdag 04 januari 2007 @ 08:42:
[...]

Als je kijkt naar de werking van cache zal de vulling van de cache voor een groot deel afhankelijk zijn van de branch prediction. Branch prediction vult de pipeline met de instructies die het meest waarschijnlijk als volgende uitgevoerd moeten worden. Vervolgens wordt de cache gevuld met de bijbehorende data. Een miss in de prediction logic zorgt er dus automatisch voor dat een groot deel van de data in de cache ook opnieuw geladen moet worden.
Dit is zo'n beetje het meest belangrijke punt in de hele discussie: Branch prediction heeft een direct effect op de efficientie van de cache en daarmee automatisch ook op hoe er met het geheugen om gegaan wordt.

Dat is dus onzin.
Ten eerste kijkt de branch prediction niet zo heel ver vooruit, dus zo enorm veel data kan er niet gelezen worden in die code.
Ten tweede wil een branch naar een ander stuk code helemaal niet zeggen dat de data daar niet in de cache staat. Sterker nog, vanwege de enorm grote caches vandaag de dag is dat maar heel zelden het geval, en is die invloed verwaarloosbaar.
Ten derde, zelfs al staat de data niet in de cache, dan nog is het onwaarschijnlijk dat ALLE data niet in de cache staat, danwel niet in dezelfde cacheline of een aangrenzende als een voorgaand stuk data, zodat het niet in 1 burst-read ingeladen kan worden, en maar 1 keer de latency gerekend hoeft te worden.
Als laatste verklaart dit niet waarom een langere pipeline meer of minder last heeft van de latency.
De lengte van de pipeline bepaalt namelijk alleen hoe lang een pipeline flush duurt. Als we uitgaan van een processors met identieke branch prediction-mogelijkheden en cache, dan zullen alle processors, ongeacht hun pipeline-lengte even vaak goed of fout voorspellen. Het effect van de latency wordt pas groter als er vaker fout voorspeld wordt, zodat er meer gecached zou moeten gaan worden (wat gezien bovenstaande verhaal maar zelden voorkomt, dus het verschil in prediction moet redelijk groot zijn).

Goed voorspellen scheelt je dus zowel in benodigde bandbreedte als in latency. Als branch prediction altijd de juiste voorspelling zou doen, zouden we allemaal met PC133 CL5 toe kunnen. Helaas is dat niet zo......

Dit voorspellen doet de branch-prediction niet. Dat doet de cache.
Branch-prediction bepaalt alleen of een branch al dan niet genomen wordt.
Vervolgens worden er instructies in de ooo-buffer geladen, en worden lees- en schrijfopdrachten geprepareerd en uiteindelijk naar de LSU gestuurd... alwaar ze door de cache verwerkt worden, die dan eventueel geheugenopdrachten gaat bufferen om ze uiteindelijk in burst-writes om te zetten, na voorspeld te hebben over wat voor soort geheugentoegang het zou kunnen gaan.
En DAAR maakt de C2D het verschil met de P4.

Ja, zo werkt het dus niet....
C2D en Ath64 voeren veel meer instructies per clockcycle uit dan P4. De pipeline bestaat uit instructies. Die paar extra megahertzen gaan daar dus niet helpen. Resultaat: De predictors van de C2D en Ath64 hebben het vele malen drukker dan die van de P4.

Ik snap niet hoe je tot deze conclusie komt.
In principe doet iedere processor iedere clockcycle een 'stap' met de complete pipeline. Dus in theorie kan iedere cycle de IP een plaats opgeschoven worden, en zouden er nieuwe instructies binnen kunnen komen, waaronder branches, dus moet iedere cycle het mechanisme lopen.
Hogere frequentie is dus automatisch een 'drukkere' processor.
In de praktijk kan de P4 alleen in verhouding minder instructies per clockcycle afronden dan de andere processors, bij dezelfde code (maar wat jij beweert, geeft me eerder de indruk dat je denkt dat er op die processors ineens meer branches in de code zitten?).
Maar ik kan wel een stuk code bedenken dat iedere cycle op een P4 een branch uitvoert. Dan zal de processor dat toch moeten voorspellen. En dat doet ie ook.

In absolute zit is de pipeline lengte van de P4, uitgedrukt in doorlooptijd, dus ook veel langer.
Doorlooptijd = lengte / IPC / snelheid. Lengte is bij de P4 veel langer, IPC is kleiner, snelheid is iets groter. Doorlooptijd is bij de P4 dus langer.

IPC hoort niet in deze vergelijking thuis.
IPC is namelijk puur afhankelijk van de instructiemix die je naar de processor stuurt.
Doorlooptijd is het theoretische minimum van 1 instructie, niet van een mix.
In een groot deel van de pipeline is er helemaal geen kans op oponthoud... en verder zijn de execution units voor de meest gebruikte instructies op alle CPUs even snel, in het ideale geval: 1 cycle.

Nee, de kortere pipeline zal het niet makkelijker maken voorspellingen te doen. De kortere pipeline zorgt er echter wel voor dat de performance hit door een prediction miss kleiner zal zijn aangezien het herladen van de pipeline minder tijd/werk kost.

Wat dus weinig met de cache en het geheugen te maken heeft.

Waarvoor is de C2D precies minder gevoelig? De C2D is duidelijk minder gevoelig voor brute geheugen-transfer snelheid. Dat heeft alles te maken met wat er hiervoor geconstateerd is (kortere pipeline dus bij miss prediction minder data die uit de cache gegooid hoeft te worden).

Nogmaals... nee.
Je haalt gewoon de hele tijd branch prediction en prefetching door elkaar. Dat gebeurt niet op hetzelfde moment, niet op hetzelfde niveau, en de afhankelijkheden zijn vooral indirect en toevallig.

Let goed op deze link. Als je goed kijkt zul je zien dat de totale geheugen latency bij de Athlon64 zo'n 10ns onder de C2D ligt. Een verhoging van de latency op het geheugen zelf zal dus relatief meer performance kosten op een Ath64 dan op een C2D/P4.

Ja, maar dat is niet het hele verhaal. Want in de praktijk is de Athlon nergens sneller in, ook niet in geheugen-intensieve applicaties. Door de cache van de C2D is hij alsnog sneller, omdat hij minder vaak gebruik hoeft te maken van geheugen.
Verder zou je moeten opvallen dat een verschil van 'maar' 10 ns wel heel weinig is voor een geintegreerde controller tov een chipset.
Dit komt voor een groot deel doordat het gemaskeerd wordt door de voorspellende gaven van de cache. De Pentium 4 scoort veel trager in dezelfde test met dezelfde chipset.
Een andere test, die onvoorspelbaar is voor de C2D-cache, laat veel hogere latencies zien.
Hier zie je zelfs een test waarin de C2D sneller is dan de Athlon: http://www.anandtech.com/...s/showdoc.aspx?i=2795&p=5
Fysiek onmogelijk, maar de cache maakt het mogelijk.
Zie ook het enorme verschil met de Pentium.

[Lumics]

He mensen, het gaat allemaal een beetje te diep voor mij. daarnaast ook redelijk offtopic. Ik heb er een ander kingston reepje bijgeplaatst en merk weinig verschil. Behalve de kleine tikjes tijdens fear die verdwenen zijn.

Anyway weer 120 euro lichter. Bedankt voor het meedenken allemaal