Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 42 reacties
Bron: X-Bit Labs

X-Bit Labs bericht dat Intel van plan is om in de tweede helft van 2007 de overstap van DDR2- naar DDR3-geheugen te maken. Evenals bij de overstap van DDR- naar DDR2-geheugen zal de transitie niet van de ene op de andere dag plaatsvinden. Het DDR2-geheugen zal nog meer dan een jaar naast DDR3 blijven bestaan. Bij de introductie in 2007 zal het DDR3-geheugen standaard werken op een kloksnelheid van 800MHz om door te groeien naar 1333MHz in 2009. Onderzoeksbureau iSuppli verwacht dat DDR3 in 2008 een marktaandeel van 55 procent zal behalen en een marktaandeel van 65 procent in 2009.

Elpida DDR3 geheugenchips
Moderatie-faq Wijzig weergave

Reacties (42)

Ik dacht dat Intel binnenkort overging op dat seriele geheugen, ben even de naam kwijt... iemand?
Dat is nog gewoon DDR2/3-geheugen, alleen bij FB-DIMM wordt er een extra chip op het geheugenreepje gezet die zorgt dat de seriele communicatie vertaald wordt naar iets wat de geheugenchips snappen.
Met andere woorden: de moederbord layout wordt een pak simpeler door het verminderd aantal datalijnen naar de geheugenslots en de northbridge. Deze, en zeker sinds de komst van Dual Channel DDR, maken de layout van een moederbord een hoop ingewikkelder.
FB-DIMM? Maar dat was toch voor servers?
FB-DIMM maakt gewoon gebruik van DDR(2/3)-chips, alleen de interface met de geheugencontroller is serieel. En het is idd. alleen voor servers.
Is het mogelijk dat AMD ipv ddr3 meteen overstapt op XDR, en hiermee dd3/intel ver achter zich laat?

DDR3 is idd leuk enzo, maar voor een echte boost moeten ze toch verder kijken ben ik bang.
waarom?
met dual channel ddr1 400 voor een single core heeft AMD op dit moment meer als genoeg geheugen bandbreedte.
met ddr2-800 hebben ze ook voor dual cores ook meer als genoeg.

sterker nog waarschijnlijk heeft een single core genoeg aan single channel ddr400.
met een quad core (waarvan ze de eerste demo in 2006 volgens AMD) moet ddr2-800 meer als genoeg bandbreedte hebben, zeker omdat ze eigenlijk nooit allemaal tegelijk de volle bandbreedte nodig hebben.
gaat niet alleen om de band breethe ook de latencys van XDR zijn heel stuk lager en kosten zouden ook lager zijn

en het disgin gemak want XDR hoeven de baanen op het mobo niet meer evenlang te zijn.
ach latency
de latency van ddr2 800 4-2-2 is al lager als die van ddr400 en 2-2-2 en die van ddr3 word bij 1333mhz nog weer lager.

verder is het effect van latency steeds kleiner, en eigenlijk al marginaal te noemen.

daarnaast zullen de royals die voor xdr betaald moeten gaat worden een stuk hoger zijn als die voor normale DDR geheugen type.

het zal best een mooie techniek zijn, maar na RIMM ben ik niet erg happig om weer iets van rambus te gebruiken.
Bereken eens even hoe veel clockcycli een 3 GHz CPU staat te wachten op z'n data als die een cache miss heeft...

Latency matters.

De enige reden waarom verhoging van bandbreedte (gepaard gaand met hogere latency) vaak positief uitdraait is omdat een CPU veel tijd spendeert aan 'domme' kopieerbewerkingen (of zeer weinig bewerkingen op een stroom van data). Van zodra een applicatie een beetje sprongetjes maakt in de data zakt de performantie zienderogen. Dat is ook de reden waarom een Athlon 64 zeer sterk is in games, terwijl een Pentium 4 het nog steeds zeer goed doet tijdens encodering.
latency dusnt matter much.
zelfs in bijna alle games in het verschill tussen 2-2-2 en 3-4-4 minder als 2.5%
nogal weinig voor geheugen waar je meestal 2 keer zo veel voor betaald.

de enige uitzondering was Halo met 15%. wat vooral de schuld lijkt van gewoon een slechte port vanuit de xbox.

in de tijd van de SD-RAM en ddr-266 maakte latency nog verschil maar tegenwoordig is dat zelden meer het geval.
Bereken eens even hoe veel clockcycli een 3 GHz CPU staat te wachten op z'n data als die een cache miss heeft..
Als dat voorkomt ja. Maar aangezien de caches steeds groter en slimmer worden, en ook programmeurs en compilers steeds beter met cache om leren gaan, neemt het belang van lage latency af.
Het is sowieso een gegeven dat de latency relatief alleen nog maar omhoog gaat, bij nieuwe technologieen voor meer bandbreedte/kloksnelheid.
Dat is ook de reden waarom een Athlon 64 zeer sterk is in games, terwijl een Pentium 4 het nog steeds zeer goed doet tijdens encodering.
De vraag is of die 'sprongetjes' in games niet verminderd kunnen worden, of zodanig opnieuw geordend dat ze (meestal) binnen een cache van 2-4 mb vallen.
Ik denk dat het antwoord hierop 'ja' luidt, en dat de voorsprong van de Athlon64 in games een beetje een vertekend beeld is. De trend in hardware is nu eenmaal dat we naar meer bandbreedte en hogere latencies gaan (ook AMD gaat over op DDR2), en ook de software zal hier rekening mee moeten gaan houden.
zelfs in bijna alle games in het verschill tussen 2-2-2 en 3-4-4 minder als 2.5%
Minder DAN.

Die latency-aanduidingen zijn maar een deel van de totale latency. Daar komt nog heel wat bij, vooral als er geen geÔntegreerde geheugencontroller is. Dus geheugen waarbij bepaalde fracties van de latency verbeterd zijn hebben nog altijd een relatief hoge totale latency.

Daarbij komt nog dat gelukkig de meeste geheugentoegangen binnen de cache blijven. Maar ik had het dus wel degelijk over een cache-miss, en dat is zeer applicatie-afhankelijk hoe vaak dat voorkomt.
Als dat voorkomt ja. Maar aangezien de caches steeds groter en slimmer worden, en ook programmeurs en compilers steeds beter met cache om leren gaan, neemt het belang van lage latency af.
Niet echt. De caches worden wel steeds groter maar de programmeurs daarom niet slimmer. En compilers hebben nooit veel invloed gehad op de cache, omdat dit vooral beÔnvloed wordt door het gebruikte algoritme en geheugenlayout, waar alleen de programmeur controle over heeft.
De vraag is of die 'sprongetjes' in games niet verminderd kunnen worden, of zodanig opnieuw geordend dat ze (meestal) binnen een cache van 2-4 mb vallen.
Dat doet men reeds zo goed mogelijk voor performantie-kritieke toepassingen. Feit is dat al die data gewoon niet in de cache past, en sommige algoritmes zullen nooit cache-vriendelijk zijn. En 2-4 MB is echt nog niet de gemiddelde hoeveelheid cache. 1 MB begint in trek te komen, maar men verkoopt even goed nog Celerons met 256 kB. Dan telt RAM latency zwaar mee.

Kijk, de Pentium 4 is een rekenwonder ware het niet dat het tegengehouden wordt door cache misses en jump misprediction. De Athlon 64 is helemaal zo krachtig niet maar lage latencies en korte pijplijnen zorgen voor een hogere efficientie.

Dus mijn enige conclusie is: latency matters. Hoe of wanneer men betere latencies gaat bereiken laat ik een beetje in het midden. L3 caches kunnen een uitkomst bieden, XDR, geÔntegreerde geheugencontroller, etc...
De caches worden wel steeds groter maar de programmeurs daarom niet slimmer.
Ik zei dat de caches slimmer werden, niet de programmeurs.
En compilers hebben nooit veel invloed gehad op de cache, omdat dit vooral beÔnvloed wordt door het gebruikte algoritme en geheugenlayout, waar alleen de programmeur controle over heeft.
Dat is precies waar ik op doel, programmeurs worden zich meer bewust van efficient gebruik van caching, omdat dat steeds belangrijker wordt.
Dat doet men reeds zo goed mogelijk voor performantie-kritieke toepassingen. Feit is dat al die data gewoon niet in de cache past, en sommige algoritmes zullen nooit cache-vriendelijk zijn.
Maar ik beweer dus dat spelletjes vaak beter zouden kunnen. Natuurlijk past niet altijd alles in de cache, en is niet alles cache-vriendelijk, maar je kunt het nog wel zo goed mogelijk implementeren. En zo nu en dan krijg je ook 'verschuivingen' in de technologie, waardoor een algoritme dat eerst langzamer was, nu sneller is, omdat de verhoudingen tussen ALU, cache en geheugen compleet anders liggen.
En 2-4 MB is echt nog niet de gemiddelde hoeveelheid cache. 1 MB begint in trek te komen, maar men verkoopt even goed nog Celerons met 256 kB. Dan telt RAM latency zwaar mee.
Nu niet, maar ik had het over de de verwachten cachegrootte ten tijde van DDR3/XDR. Want zoals je begrijpt, past het dan prima in mijn verhaal: meer latency, maar grotere caches, dus op zoek naar nieuwe algoritmen/implementaties voor optimaal gebruik van deze configuraties.
En dan is een logisch gevolg dus dat de latency minder belangrijk wordt, want daar wordt nu 'omheen' geprogrammeerd.
Ik zei dat de caches slimmer werden, niet de programmeurs.
...
Dat is precies waar ik op doel, programmeurs worden zich meer bewust van efficient gebruik van caching, omdat dat steeds belangrijker wordt.
Je zei, en ik quote: "programmeurs en compilers steeds beter met cache om leren gaan". Naar mijn ervaring neemt het percentage programmeurs dat iets kent van cachevriendelijke geheugenlayout niet toe. En compilers hebben geen significante invloed op de efficiŽntie van geheugentoegang.

Ik zie dezelfde evolutie als bij harde schijven: Die worden maar marginaal sneller voor elke generatie, terwijl processors nog steeds ferm krachtiger worden. Dat leidt tot situaties waarbij bepaalde applicaties die veel van de harde schijf gebruik maken niks sneller worden. Hetzelfde fenomeen krijgt men met applicaties die sterk afhankelijk zijn van de latency van geheugen.

Nu ja, het is gewoon een kwestie van prioriteiten natuurlijk. Maar nogmaals, mijn enige conclusie is dat latency er wel toe doet en daar maatregelen voor getroffen moeten worden zoals extra cache (als latency niet deerde hadden we niet eens cachegeheugen), wegwerken van overhead, nieuwe procestechnologie, etc.
Naar mijn ervaring neemt het percentage programmeurs dat iets kent van cachevriendelijke geheugenlayout niet toe. En compilers hebben geen significante invloed op de efficiŽntie van geheugentoegang.
Dan verschilt onze ervaring.
Ik zie dezelfde evolutie als bij harde schijven: Die worden maar marginaal sneller voor elke generatie, terwijl processors nog steeds ferm krachtiger worden. Dat leidt tot situaties waarbij bepaalde applicaties die veel van de harde schijf gebruik maken niks sneller worden. Hetzelfde fenomeen krijgt men met applicaties die sterk afhankelijk zijn van de latency van geheugen.
En omdat harddisks langzaam zijn, hebben we diskcaches gekregen. Wat is nu het geval... we hebben nu zo veel intern geheugen, dat complete databases van enkele GB groot in het geheugen passen, en de harddisk eigenlijk amper meer nodig is. De latency van de harddisk doet er dus niet meer toe.
We zijn bijna op een punt aangekomen waar 'alles' in het interne geheugen past.
Swappen is ook bijna verleden tijd voor de standaard-gebruiker, want 1 gb geheugen is makkelijk te betalen, en met 1 gb past je OS, je mailclient, je browser, je tekstverwerker etc makkelijk in het geheugen.
Maar nogmaals, mijn enige conclusie is dat latency er wel toe doet en daar maatregelen voor getroffen moeten worden zoals extra cache (als latency niet deerde hadden we niet eens cachegeheugen), wegwerken van overhead, nieuwe procestechnologie, etc.
En ik zeg dus dat we op een punt aan gaan komen waar het dermate weggewerkt is dat het in een aantal gevallen er niet toe doet. We krijgen wel steeds grotere caches, maar onze datasets veranderen niet zo enorm. Er gaat dus steeds meer in de cache passen. Denk maar eens na, straks heb je een CPU met 4 mb cache. Hoe vaak komt het voor dat je een algoritme hebt dat EN compleet onvoorspelbare geheugenaccess heeft EN meer dan 4 mb tegelijk nodig heeft? Dat valt best mee, lijkt me. Meestal kun je ofwel je data zodanig ordenen dat het netjes gegroepeerd is, dus dat je maar 1 keer het probleem van latency hebt voor een hele groep data, of je kunt je data zodanig opslaan dat je voor een groot deel binnen die 4 mb cache je random access patronen hebt. Dus doet latency er niet zo heel erg meer toe.
ook de latencys van XDR zijn heel stuk lager en kosten zouden ook lager zijn
Alleen maar voordelen en geen nadelen?
Dat geloof je toch zelf niet?
Er zit ook een marketingspunt aan vast. Doordat de grote OEM's de productlijn van Intel volgen, zul je zien dat het ook op een gegeven moment goed gaat verkopen. Stel dat AMD daadwerkelijk XDR gaat invoeren, dan kun je lang wachten voordat het aanslaat. En bovendien zal dat XDR niet het goedkoopste geheugentype worden, en daarom ben ik bang dat het zelfde gaat gebeuren zoals dat bij Intel gebeurde in de RDRAM tijd.
Het kan ook andersom, dat AMD wint met XDR zoals indertijd met DDR toen Intel de plank mis sloeg met RDRAM. Als de royalties van XDR niet te hoog zijn en yields niet te laag uiteraard.
Het DDR3-geheugen zal nog meer dan een jaar naast DDR2 blijven bestaan.
Andersom had dat moeten zijn.
Ik hoop ook dat AMD snel overstapt naar XDR geheugen en DDR2 & DDR3 gewoon overslaat, maar het lijkt me hoogst onwaarschijnlijk. Zeker gezien het feit dat DDR2 en DDR3 ruim voldoende is om de bandbreedte behoefte van een AMD processor te vullen.

off-topic: waarom hebben tweakers zo'n moeite met 'als' en 'dan'.. valt me echt op... Maarja :) Korte introductiecursus: Als het een groter is DAN het andere, dan zeg je 'DAN'. Als het evengroot is ALS het andere, dan zeg je ALS. Lijkt me toch niet zo moeilijk wel..?
Bedankt, ik kan het het nooit onthouden.
Maarja, heeft ddr3 nog nut met de huidige processoren, amd heeft zelfs nog genoeg aan ddr-ram....
Maarja, heeft ddr3 nog nut met de huidige processoren, amd heeft zelfs nog genoeg aan ddr-ram....
Of AMD genoeg heeft aan DDR geheugen is maar zeer de vraag. Het is natuurlijk niet voor niets dat er een nieuw socket en DDR2 ondersteuning komt (al kŠn dat ook gewoon met de prijs en beschikbaarheid van DDR-2 geheugen te maken hebben).

Pas als er AMDs met DDR-2 geheugen zijn kun je echt zien of de overstap wel of geen snelheidsvoordelen heeft. Als die DDR-2 AMD chips sneller zijn als hun DDR broertjes is dat een sterke aanwijzing dat de performance van de huidige AMD chips wordt tegengewerkt door het DDR geheugen niet. Zo niet, dan niet :)
aan het meestal kleine verschil tussen socket 754 en socket 939 zie je dat AMD idd meestal niet meer bandbreeedte nodig heeft, iniedergeval niet voor single core cpu's
maar ze zijn ook bezig met dual cores en willen zelfs halverwegen 2006 quad cores demonstreren.
zeker voor die quad cores kan de huidige dual channel ddr-1 nog wel eens wat krap gaan worden.
en dual channeel ddr-2 800 lijkt daarvoor dus de perfecte oplossing.
off-topic, maar "on" jouw reactie.
Een korte cursus voor gevorderden speciaal voor jou:
Zowel bij een gelijke (even groot bijv.) als een ongelijke ( groter bijv.) vergelijking mag je 'ALS' gebruiken. Dus niet alleen 'DAN' zoals jij en met jou vele anderen tot in den treure lopen te beweren. (Bron: Encyclopedie der onwaarheden).
Het kan me niet schelen wat er al dan niet volgens een of andere encyclopedie toegelaten is. Er bestaat ook nog zoiets als stijl, en "groter als" leest niet vlot. Ik kan me wel voorstellen dat met een Hollands accent het vlotter uitspreekt of zo, maar dat moet dan niet de referentie worden.
kan me weinig schelen wat sommige mensen onder stijl verstaan, zo zeg type en schrijf ik het al jaren, zo lang ik me kan herrineren eigenlijk. dat is dus mijn stijl.
en als je het er niet mee eens bent heb je gewoon pech!.
# zodra er zo staat, gebruik je als (net zo groot als, niet zo groot als, driemaal zo groot als, bijna zo groot als ...),
# bij hetzelfde/dezelfde gebruik je als (dezelfde hoeveelheid als ...),
# bij even gebruik je als (even groot als ...),
# bij de vergrotende trap gebruik je dan (groter dan, beter dan, meer dan ...).

bron: <url>http://www.taalthuis.com/nl/schrijftips5.htm</url>
ik vraag me af hoe AMD daarop zal gaan reageren! :o
was amd's geheugencontroller niet compatibel met ddr3 ?
Huidige AMDs kunnen enkel DDR aan. Toekomstige AMDs DDR2. Of AMD deze nog te introduceren geheugencontroller ook geschikt maakt voor DDR3 is afwachten. Eerlijk gezegd verwacht ik van niet.
AMD Opteron CPU with Hyperthreading 3.0, an extended AMD64 instruction set and FB-DIMM support is expected to be released in Q4 2007. This processor is expected to be a quad core processor with the cores connected through an enhanced version of the Hypertransport protocol. K9 is expected to interface to DDR3 memory with the initial revision running at clock speeds of up to 3Ghz.

bron: http://www.mikeshardware.co.uk/Roadmap20XX.htm
Ik meen dat op de AMD roadmap, welke ik op dit moment niet kan vinden, DDR3 ook halverwege 2007 geÔntroduceerd word
Ik zie het best nog gebeuren dat straks de snelheid van t geheugen en de nieuwste GPU op dezelfde snelheid zal draaien als de CPU.. wie had dat ooit gedacht? :)
Pentium 1 + Voodoo3 + sdram ?
Komt toch aardig in de richting ...
SDR SDRAM op 183 mhz?

Maar de basissnelheid van geheugen staat eigenlijk al eeuwen stil op ongeveer 200 mhz.
Disken moeten die latency's hebben en die data doorvoer, geef toe je PC word traag van je disken zelf met RAID is het nog 1 gare konijnenbende.

Iets minder off-topic volgens mij, maar waar slaat dat plaatje bij het artikel op? Zijn dat de nieuwe chips?

Beetje on-topic, is DDR3 beetje vergelijkbaar met GDDR3?
Laat je cursor even rusten op het plaatje en je hebt je antwoord ;)
je hebt teveel paddo's op, paddoswarm. Althans dat geldt voor je 1e stukje. Totaal niet te begrijpen voor me.

2e stukje: ga eens met je muis op het plaatje staan zonder te klikken ;)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True