Prestatieverlies grotere geheugenconfiguraties getackeld

Sinds enige tijd is er volgens LostCircuits een gerucht dat de ronde doet op verschillende fora over prestatieverlies bij grotere geheugenconfiguraties. Dit gerucht zou zijn ontstaan nadat The FiringSquad een artikel had gepost over het bouwen van het ultieme 'high-end gaming workstation'. In het artikel kunnen we zien dat de 2,8GHz Pentium 4-processor in combinatie met de i875-chipset en 2x512MB aan geheugen stukken beter (39%) presteerde dan bij het gebruik van 4x512MB aan geheugen. Reden genoeg dus voor LostCircuits om zelf op onderzoek uit te gaan om te kijken of The FiringSquad gelijk heeft of niet.

Volgens LostCircuits kunnen er drie oorzaken zijn voor de slechte prestatie bij het gebruik van 2GB aan geheugen. Als eerste kan er een softwareprobleem zijn. Een tweede oorzaak zou het OEM-moederbord zelf kunnen zijn. Sommige fabrikanten stellen hun BIOS namelijk zo in dat als alle vier de banken gevuld worden, het geheugen minder snel wordt aangesproken. Een derde probleem zou kunnen worden veroorzaakt door de geheugencontroller van de i875-chipset. Deze zou namelijk het geheugen langzamer gaan aanspreken als de MCH te warm wordt.

Uit de benchmarks blijkt echter dat er zo goed als geen verschil is tussen de performance met 1GB aan geheugen of 2GB aan geheugen. Het maximale verschil dat LostCircuits wist te meten was 6%, dat kan worden toegewezen aan de instellingen van de geheugencontroller in het BIOS bij het gebruik van vier banken. In Photoshop 7.0 was er echter iets raars aan de hand. Als de tijd die Photoshop erover deed om een bepaalde bewerking uit te voeren met de hand werd gemeten, dan waren er geen verschillen zichtbaar tussen een configuratie met 1GB aan geheugen of 2GB aan geheugen. Als de meting echter werd overgelaten aan de ingebouwde timer, dan waren deze vaak hoger dan de meting met een stopwatch. Daarnaast waren de resultaten met de ingebouwde timer moeilijk te reproduceren. Het lijkt er dan ook op dat de ingebouwde timer van Photoshop niet is te vertrouwen en dat benchmarks die van deze timer gebruik maken niet moeten worden vertrouwd.

Reacties (47)

[XXfrankieXX]

Dit las ik op http://www.chip-architect.com/news/2003_04_20_Looking_at_Intels_Presco tt_part2.html:

64 bit virtual addressing for the desktop will be needed many years before 4 GByte physical memory becomes common place on your motherboard . The point is that the whole idea of virtual memory with page management only works if the virtual memory space is much larger then your physical memory. I actually had to save my work and restart the image software many times during the work on the large images of this article, edited in uncompressed mode. Often I had to shoot down by hand as many tasks possible with Task Manager to free virtual memory just to get my work saved. The problem is not the 1 Gigabyte DDR on my Dell Inspiron 8200. The whole problem is the 4 Gigabyte virtual memory limitation which becomes so polluted with scattered around bits and pieces of allocated memory so that it's not possible to find a decent part of continues memory anymore. All the result of course of languages like C with explicit pointer handling and processors that do not have specific pointer registers. There is no way to defragment virtual memory like a hard disc to open up larger continuous areas. The only way to "defragment" virtual memory is to save your work on time, shut down the program and restart again.I think these mission critical 32 bit bank transaction servers only work because they start up and kill small processes all the time to avoid virtual memory pollution. Imagine that you have to start killing all kinds of tasks by hand in the hope that you can save a few hours worth of bank transactions....

Dan zou het probleem dus liggen aan dat de processor 32 bits is.

[Beaves]

Dat een 32-bit CPU om meer als 4GB aan geheugen te kunnen aanspreken een vertaalslag nodig heeft en dat er daardoor extra latencies ontstaan klopt, maar dat heeft niets met dit bericht te maken.
Ook het feit dat een 32-bit CPU blijkbaar moeite heeft met 1GB aan RAM + een leuke hoeveelheid virtueel geheugen maakt niet uit voor dit bericht.

Ik vind de quote een beetje vreemd, ik ken zeer veel mensen en bedrijven die met 1GB of meer geheugen werken en die hoeven echt niet elke keer processen af te sluiten. Ik krijg het idee dat de beste man een Win 9x OS gebruikt wat een brak geheugen beheer heeft. Onder Windows NT OS'en ken ik die problemen niet. Veel bedrijven hebben ook continue servers aan met 1GB of meer geheugen (zie T.net), die hoeven ook niet elke keer processen te stoppen.

Het gaat immers om evenveel geheugen, alleen de hoeveelheid per DIMM verschild (2 x 1GB of 4 x 512MB). Daar zit dus een merkbaar maar klein verschil tussen.

[OzBoz]

en 2x512MB aan geheugen stukken beter (39%) presteerde dan bij het gebruik van 4x512MB aan geheugen.

Hoezo evenveel? Of kan ik niet tellen

[ShadowLord]

Sorry hoor, maar ik dat stukje lees heeft deze dude niet echt door hoe het geheugen gemanaged wordt in Windows.

Een applicatie krijgt een virtueel geheugen blok van 2 GB. Windows laat de applicatie niet bij de bovenste 2 GB van de adresruimte waar hij eigenlijk wel bij zou moeten kunnen. Ook valt er een een klein beetje geheugen af aan het begin van dit blok virtueel geheugen om het debuggen van applicaties makkelijker te maken.

Dit blok van 2 GB heeft totaal niets te maken met het virtuele geheugen waar Windows mee te maken heeft. Dat is een combinatie van de pagefile en het RAM. Windows kan de verschillende blokken geheugen die gebruikt worden in het 2 GB virtuele geheugen van de applicatie naar eigen inzien mappen in de pagefile en RAM. Als de pagefile gefragmenteerd en vol raakt (wat ik me niet echt kan voorstellen, tenzij je VEEL te veel erg zware geheugen-verkwistende apps open het staan) dan heb je ene probleem ja. Maar, in tegenstelling tot wat gezegd wordt, zou dit, door Windows beheerde, fysieke geheugen (in theorie) gedefragmenteerd kunnen worden.

Aan de andere kant, als je applicatie erg verkwistened om gaat met zijn 2 GB virtueel geheugen, dan is dat de fotu van de applicatie en zal de ontwikkelaar maar eens een 'Geheugenmanagement voor dummies' boek moeten aanschaffen.

[Ralph Smeets]

E Chip Architect heeft wel degelijk gelijk. Er zijn namelijk twee soorten virtueel geheugen en jij haalt ze beiden door elkaar.

Een moderne processor kan in minimaal twee modes werken, die meestal supervisor (of kernel-mode) en user-mode worden genoemd. Bij Intel en AMD processors zijn er meer van dit soort modes en worden aangeduid met Kernel-level 0, 1, 2 en 3.

Het OS draait in level 0 en beheert de zogenaamde TLB. Dit is een bank met registers die virtuele geheugenADRESSEN vertallen in physieke geheugenadressen. Hierdoor kunnen bijvoorbeeld twee verschillende applicaties het hetzelfde physieke geheugenadres benaderen. Bijvoorbeeld:
TLB1 : 0-1 -> 0-1, directe mapping
TLB2: 0-1 -> 2-3, de applicatie denkt dat hij adres 0 en 1 gebruikt, maar in werkelijkheid is dat adres 2 en 3.
TLB3: 1-2 -> 2-3, idem
enzovoort.
Elke applicatie krijgt een of meer TLB's toegewezen.

Als je dus meerdere applicaties hebt lopen, die allemaal een gedeelte van het physieke geheugen benaderen maar wel allemaal van andere virtueele geheugenadressen gebruik maken, dan heb je dus een probleem. Zeer zeker als die applicaties allemaal 1GB aan geheugen nodig hebben. 4GB virtueel geheugen staat dus gelijk aan 4 keer een 1GB proces!

De pagefile waar jij over spreekt wordt helaas ook virtueel geheugen genoemd, maar dat is dus een foute naam. Onder alle andere OSen heet het swap-geheugen wat een veel betere naam is. Want TLB-pages worden van en naar harddisk geswapped.

[Verwijderd]

Elke applicatie krijgt een of meer TLB's toegewezen.

Als je dus meerdere applicaties hebt lopen, die allemaal een gedeelte van het physieke geheugen benaderen maar wel allemaal van andere virtueele geheugenadressen gebruik maken, dan heb je dus een probleem.

Volgens mij klopt dit niet helemaal.

De TLB is alleen maar een cache voor de algemene page table. Telkens als een nieuwe page table wordt geselecteerd (bij een context switch) wordt de TLB geflushed.

Net na de context switch zal het process dus even iets langzamer draaien omdat de TLB gevuld moet worden. Dat zal initieel een aantal TLB misses opleveren. Het juiste adres wordt dan uit de page table gehaald, in de TLB gezet, en bij de volgende memory access gaat de translation een stuk sneller.

De werking is dus redelijk vergelijkbaar met de data en instructie caches van de CPU. Bv, ook bij de TLB geld: Als de TLB vol is en er moet een nieuwe entry in dan zal er gewoon door het OS een victim gekozen worden die er uit gaat.

Lees eens een boek van Tanenbaum of Silberschatz zou 'k zeggen. Daar staan bovengenoemde concepten best wel makkelijk en nog een stuk uitgebreider uitgelegt.

edit:
belediging weggehaald

[HellPunk]

Dank voor de extra uitleg, alleen dat eerste regeltje was echt niet nodig...

[Ralph Smeets]

Ik heb zelf weinig ervaring met OSen, echter, ik heb ontzettend veel ervaring de architectuur van CPU's. Komt ondermeer doordat het
mijn vak is

Ik weet dus wel heel duidelijk wat een TLB is en ken de boeken van Tanenbaum en Silberschatz allebij van voor tot achter. (De moeili
jkste fouten om te vinden bij een CPU komen meestal van het TLB-cache-samenspel af).

Echter, ShadowLord heeft het hele stuk van XXfrankieXX niet begrepen omdat hij swap-file met virtueel geheugen door elkaar haalde.

Daarnaast klopt de bewering:

Als je dus meerdere applicaties hebt lopen, die allemaal een gedeelte van het physieke geheugen
benaderen maar wel allemaal van andere virtueele geheugenadressen gebruik maken, dan heb je dus een probleem.

helemaal, want onafhankelijk van hoeveel TLB-entries je tot je beschikking hebt, in een multitasking OS zoals bijvoorbeeld Windows X
P, krijgt elke task zijn eigen virtueel geheugen gebied aangewezen. Als je dus meer dan vier tasks hebt die elke 1GB nodig hebben, h
eb je met de 4GB-limiet dus een aardig probleem en moet je overstappen op de 48bits adresserings technologie die Intel in heeft gebo
uwd.

[Verwijderd]

Ik heb zelf ooit nog eens een module geschreven voor memory management in de kernel (paging algoritme, pre-paging enz) maar is lang geleden.

Als je dus meer dan vier tasks hebt die elke 1GB nodig hebben, heb je met de 4GB-limiet dus een aardig probleem

Als ze echt al dat geheugen in hun working-set hebben wel. Dan krijg je een trashing situatie dat er bij elke context switch enorm veel pages ingeladen moeten worden.
Logisch gezien kan het toch nog steeds? Elk process krijgt toch gewoon een address space van address 1 t/m 4294967295. Onder Windows kan daar maar 2 of 3 gig tegelijk van in RAM zitten. De rest van dat geheugen zit dan in de swap-file en wordt ingeswapped als dat noodzakelijk is. In zo'n situatie zouden bij alle frames in RAM met pages van dat enkele process corresponderen. Als het volgende process dan gaat draaien worden zijn pages ingeswapped. Of dat voor allemaal lukt binnen de executie tijd is dan nog maar de vraag.

Ik ga er dan wel vanuit dat de swap file wel gewoon groter dan 4GB kan zijn. Meer dan 32bit hardware addressing heb je hier niet perse voor nodig (helpt wel), omdat je best in files >4GB kan seeken. Je moet dan wel wat extra rekenen (In C++ bv BigInt lib ofzo). In dit geval is dat te doen, omdat de latency om naar swap te gaan toch al enorm is. De extra rekenstappen vallen relatief dan in het niet.

[Verwijderd]

Geheugen kan inderdaad gedefragmenteerd worden, het is alleen een taak die vrij complex is; Windows doet dit (nog) niet maar er zijn andere OS'en die het wél kunnen.
Overigens draaien banken vaak alleen de front-ends van applicaties (de knoppen en de plaatjes) op Windows, de backend word in de regel door grote mainframes en unixbakken geregeld; die gaan ook wat beter met geheugen om.
Volgens mij heeft de schrijver van het artikel trouwens iets anders niet helemaal goed; PhotoShop geeft bij mijn 196MB fysiek geheugen nooit problemen, zelfs niet bij de plaatjes die groter zijn dan mijn fysieke geheugen.

[TD-er]

ehhh dus als ik het goed begrijp heeft de interne timer van Photoshop sneller gelopen met meer geheugen erin.
Anders kan de gemeten performance nooit lager uitvallen.
Dat een timer minder tikken geeft wanneer de machine drukker bezig is kan ik me voorstellen... maarmeer tikken... dat zou betekenen dat de computer mogelijk vaker zou kunnen switchen tussen threads of processen wanneer er meer of minder geheugen in zit.

Ik ben heel erg benieuwd of dat met alle windows OS-en zo is. (dus NT, 2000, XP, 2003 en de varianten die standaard al bedoeld zijn voor meer geheugen, zoals datacenter en Advanced server.)

[CumpsD]

en niet vergeten, laat ze deze testen ook eens doen op niet-windows systemen, benieuwd of die rariteiten zich daarin verder zetten

[DannyXP1600]

nee, zoals jij het uitlegt klopt het niet. Dan zou het dus niet zijn omdat er meer geheugen in zit dat de tijd sneller gaat lopen, maar omdat er te weinig in zit gaat het te langzaam. Met 1 GB aan geheugen een grote bewerking doen loopt de tijd bijvoorbeeld op 0,99999999 realtime snelheid en met 2 GB geheugen wel precies 1.
Denk niet DAT het zo is, maar om even in jouw redenatie mee te gaan...

[LSDsmurf]

Maar het gerucht dat het inderdaad trager is klopt dus volgens hun testen.
Ook al is het slechts met enkele procentjes het is en blijft trager.

[sweetdude]

Als eerste kan er een softwareprobleem zijn

Sommige fabrikanten stellen hun BIOS namelijk zo in dat als alle vier de banken gevuld worden, het geheugen minder snel wordt aangesproken. Een derde probleem zou kunnen worden veroorzaakt door de geheugencontroller van de i875-chipset. Deze zou namelijk het geheugen langzamer gaan aanspreken als de MCH te warm wordt.

Deze problemen zijn toch op een vrij simpele manier te onderzoeken. Als een systeem met 2x 512 beter presteerd dan een systeem met 4x512. Dan lijkt het me niet meer dan logisch dat je dan ook nog eens probeerd met 2 x1024. Mocht dit dan sneller zijn dan kun je dus al haast zeker zeggen dat het geen software probleem of MCH probleem is en dat het dus een andere problemen moet zijn.

[HarryL]

wel raar dat dat zo is.
Maar wat is nou 6%.
En wie heeft er nou 2 GB aan geheugen in zijn pc..

[Devion]

Wat dacht je van GFX Designers? 3DSMax? Maya? C++/# coders? en ga maar zo door, meeste developers hebben standaard 1GB+

Renderstations zit meestal zelsf 4GB in (en een dual setup van Xeons to boot )

[Verwijderd]

Bij ons staan dual MP 2400+'jes te pruttelen met per systeem 4 GB aan geheugen.

Die worden gebruikt als 3D CAD?CAM stations. Moet zeggen dat het wel lekker rap is

In mijn eigen PC zit 1GB en voor persoonlijk gebruik heb ik daar NU nog genoeg aan. Het verschil tussen 1 en 2 GB is niet zo goed te merken. Tussen 512 en 1 GB duidelijk wel. Photoshop start verdorrie opeens zeker 2x zo snel op. Laat staan de bewerkingen.

[Verwijderd]

moeten ze ook eens kijken welke sneller is na een uur of 3. waarschijnlijk de 2GB, omdat je swap erg traag is

[Juicy]

moeten ze ook eens kijken welke sneller is na een uur of 3. waarschijnlijk de 2GB, omdat je swap erg traag is

Ik begrijp niet waarom men deze quote met een +4 inzichtvol kan modereren ... Wat heeft in hemelsnaam de snelheid van de swap hiermee te maken. Deze snelheid staat zo-ie-zo los van de hoeveelheid geheugen en de kans is groot dat de swap niet eens wordt gebruikt bij een geheugen van 2 GB ...

[genivos]

Onzin, Windows gebruikt altijd swap onafhankelijk hoeveel geheugen je in je PC hebt zitten (standaardregel voor swap is zelfs geheugen x2). Of het in dit geval in snelheid scheelt durf ik niet te zeggen maar ga nu niet beweren dat win geen swap gebruikt bij 2Gig geheugen. Dat het invloed op de snelheid heeft, dat denk ik wel.

[Verwijderd]

Je hebt er werkelijk geen bal van begrepen als je denkt dat swap 2x geheugen zou zijn.

[Munters]

Je kunt de swap uitzetten, maar dat is over het algemeen niet verstandig.
Er zijn gewoon stukken geheugen die lange tijd niet nodig zijn. Die gaan gewoon naar de swap, zodat het RAM nuttigere gegevens kan vasthouden. Al is het maar een disk-cache.

Een slim OS schrijft blokken die al langere tijd niet gebruikt zijn gewoon naar de swap, wanneer de machine idle is. Maar houdt tegelijk deze gegevens vast in het RAM.
Zodra de machine weer wat te doen krijgt, kan er zeer snel weer gebruik gemaakt worden van de gegevens (want nog aanwezig), of zeer snel vrijgegeven worden (want al physiek naar de swap geschreven).

Overigens wordt de swap ook in twee modes gebruikt. De eerste is een "overloop", zodra het OS RAM nodig heeft, wordt de huidige inhoud naar een swap geschreven. De swap space groeit hierbij, maar kan ook vol zijn. Indien de disk vol zit, kun je dus een out-of-memory krijgen.
Ook is het mogelijk dat de swap het complete virtuele geheugen beslaat en de fysieke RAM altijd een mapping op de swap heeft. Dit kost extra swap ruimte, maar heeft als groot voordeel dat uitswappen altijd lukt. De ruimte is tenslotte gereserveerd. Het RAM zou je dan als een cache voor het viruele geheugen kunnen beschouwen.

[Iblies]

Meneer Genivos, als je veel geheugen hebt, 512MB+ kun je swap gerust uitzetten. Met het gewone huis- tuin en keuken werk moet je het makkelijk trekken. Veel games doen niet zo moeilijk met zoveel geheugen en/of gebruiken zelf een eigen swap die ze zelf beheren en niet door windows.
Als je 1GB+ en je bent aan fotosoepen kun je het uitschakelen en kijken of de computer het redt. Voor 'normale' foto's moet het wel lukken. Werk je met veel en grote foto's dan ontkom je er niet of om meer geheugen te kopen, raad ik wel aan want scheelt gigantisch veel tijd, of swap aan te zetten.


@pietje de pukkelaar
Als de prijs van geheugen nog erg hoog was dan zou ik inderdaad met jouw redenatie meegaan. Weinig geheugen wordt dan gecompenseerd met een beetje swap. Maar nu bijna elke pc standaard wordt voorzien van 512 MB is swap niet echt nodig. Want swap zal altijd een remmende werking hebben op de prestaties. De harde schijf is immers nog steeds een van de, zoniet de, langzaamste onderdeel van de computer.

[genivos]

@AdV: Dat zeg ik niet, jij begrijpt blijkbaar geen bal van mijn verhaal. Ik geef alleen aan wat standaard is. Leren lezen is misschien handig voor jou.

@Iblies: leuk verhaal en snap ik allemaal wel. Ik ben er alleen vanuit gegaan dat ze standaard instellingen gebruiken of ingesteld hebben. Toch adviseert men (en ik ook) om toch swap te gebruiken. Gezien de reacties en de scores 'inzichtvol' heeft het blijkbaar geen zin hier eigenlijk iets over op te merken...

[pietje63]

Ik kan me een artikel van enkele jaren geleden in de computer idee (dat las ik toen nog..) herinneren waar een soort gelijke kwestie ook al besproken was.

Ze wisten toen te vertellen dat:
2*64MB langsamer was dan 1*128MB
128MB+16MB langsamer was dan 128MB

de algemene conclusie uit dat artikel was dat meer geheugen niet altijd bevoorderlijk was voor de snelheid en dat je zo min mogelijk banken moet gebruiken.

Terug naar deze kwestie. Ik vind dat ze naas 4*512MB ook 2*1024MB hadden moeten meten (en misschien ook nog 2*256MB) om uit te zoeken wat de effecten zijn.

[aheemstra]

Wat is nu net het probleem. Tegenwoordig is er veel verandert in de architectuur van de MOBO. Die oude artiekelen kunnen bij het aanmaakhout voor de openhaard. De Dual channel geheugen constructie die tegenwoordig wordt gebruikt geeft hier het probleem. Nouja.. probleem. Je moet er gewoon van profireten en weten hoe je je geheugen verdeeld. Ik spreek uit ervaring dat je dus beter op een AMD systeem 2 geheugenbanken vol kan hebben dan 1 of 3. Wil je 512 ga dan voor 2 maal 265. En ga zo maar door. Vul niet je laaste bank( als je er 3 hebt tenminste ).. dat levert problemen op zoals heel goed is uitgelegd in de laatste 2 pagina's van het bovenstaande artikel. Daar valt eigenlijk niets aan toe te voegen.

Bij de weg... er staat ook een mooie vergelijking in van een snelle processor met langzaam geheugen t.o.v. een wat langzamere proc met snel geheugen. Op bijna alle test trekt de langzamere proc. de snelle eruit. Conclusie : Bespaar nooit op de kwaliteit en snelheid van je geheugen als je een kwalitatief goed systeem aan het bouwen bent.

[SkyStreaker]

Oeps! Moddereer maar weg!

[Juicy]

wie gebruikt er dan ook 2gb aan geheugen??? In games is het totaal overbodig. Ik heb zelf 1gb en ik moet zeggen dat alles reete snel laad samen met een amd 2500+@2.2Ghz maar volgens mij is 2gb iets teveel van het goede.

Het wil nog niet zeggen dat als jij dat vind dat dat dan ook zo is ... Ik heb zelf 2 GB aan geheugen, ik gebruik mijn PC om software te ontwikkelen en maak veel gebruik van VMWare om de software op virtuele pc's te testen. Dan is het toch wel handig om 2 virtuele pc's met 512 MB uit te rusten en daarnaast toch nog zonder problemen je systeem laten draaien.

Je hebt gelijk dat het voor de "gewone" mens een beetje een overkill is, maar vlak niet iedereen uit.

btw, wie wil er nou intel, als we AMD hebben?

Flamewars zijn niet nodig ...

[Verwijderd]

1) ik zou best wel een gigje of twee willen hebben zodat m'n 3D assemblies van 100stukken ook nog zouden kunnen...

2) wie gebruikt er intel? Ikke... mobo met alle toeters en bellen en processor... Stabiliteit verzekerd...

[10011]

Ik zie nu allemaal mac freaks met hun stopwatch gaan zitten meten. En binnenkort komen er massa's berichten dat de timer al tijden niet deugd

wel mooi in computer tijd moeten we alsnog de stopwatch gaan pakken

[Abbadon]

Dat de ingebouwde timer van PS niet te vertrouwen is was voor mij al oud nieuws: met benchmarken kwam ik daar al eens achter. Dit was op een SMP doos, misschien dat HT (wat op die P4 zit) van invloed is op deze non-reproduceerbare metingen (ik doe maar een gok sinds er enkele parallelen zijn met een échte SMP setup).

Verder onderstreept dit allemaal wel weer met wat voor korrel zout je de reviews moet nemen. Ik las het FiringSquad review enkele dagen geleden al en de uitkomst staat diametraal tegenover de bevindingen van deze review op Anandtech: http://www.anandtech.com/memory/showdoc.html?i=1839 . Hoewel Anandtech alleen met een dubieuze synthetische benchmark (Sandra Sisoft) te werk is gegaan, is de conclusie dat hoe meer banken = beter maar dat het in de praktijk natuurlijk niet merkbaar is. We praten tenslotte, net als LostCircuits heeft gemeten, slechts over onmerkbare procentjes in de marge

[SED]

Dit is volstrekt oud nieuws.
Dat meer geheugen niet per definitie meer snelheid zal betekeken moet iedee tweaker al lang bekend zijn.
Mocht dat niet zo zijn dan loop je waarschijnlijk nog niet zo lang mee.
Dat heft te maken met moederbord architectuur, aantal aangestuurde sloten, mogelijkheden van het OS en timingsproblemen van de geheugenchips.

Inmiddels zijn de laatste generatie moedeborden in hun ontwikkeling al zover dat er ook effectief meer geheugen ondersteund kan worden maar optimaal is het nog niet.

Leuk dat dxeze test een bevestiging is ( geen idee voor wie, maar vooruit) van wat tweakers al vijf jaar weten.

[Verwijderd]

Aan de andere kant heb je met meer aparte geheugen chips wel meer kans dat een geheugen rij (of was het kolom) nog open staat, zodat die sneller opgehaald kan worden.