De grote Tweakers-geheugentest

Meer is beter, maar hoeveel beter precies?

Conclusie: twee keer vier

De invloed van de hoeveelheid geheugen in het dagelijks gebruik valt eerlijk gezegd wat tegen. Bij het merendeel van de uitgevoerde tests blijkt het niet heel veel uit te maken over hoeveel geheugen een systeem beschikt. Daarbij moeten we wel aantekenen dat we steeds één benchmark tegelijk draaiden. Wie veel programma's continu heeft openstaan, profiteert wellicht meer van extra geheugencapaciteit.

Kijken we echter naar onze benchmarks als Adobe- en Futuremark-tests, dan blijken de verschillen tussen twee reepjes van 2GB geheugen en twee reepjes van 8GB ram niet groot. Daarbij hebben we de timings gelijk gehouden en werd het geheugen op 1600MHz geklokt. Als we die kloksnelheid variëren, van 1333MHz stapsgewijs tot 2133MHz, dan zien we over het algemeen winst. Photoshop en Lightroom worden iets sneller, net als PCMark. Het meest teleurstellende resultaat leverde echter het tweaken van de timings op; strakkere timings leiden tot mindere resultaten. Waar dat aan te wijten is, weten we niet; we hadden juist op betere resultaten met lagere latencies gerekend.

De hoeveelheid geheugenkanalen maakt wel een duidelijk verschil. Een enkel reepje in een systeem, zowel van AMD als van Intel, is stukken trager dan twee modules van gezamenlijk dezelfde capaciteit. In ons high-end systeem zien we met de stap naar vierkanaalsgeheugen opnieuw snelheidswinst.

Waar we wel grote verschillen zien, is bij werklasten die aan de gpu zijn gerelateerd. De apu van AMD profiteert enorm van sneller geheugen en zet in vooral games, maar ook in grafische benchmarks, beduidend betere resultaten neer met sneller of meer geheugen. Ook de Intel-processor heeft veel baat bij sneller geklokt of meer geheugen, terwijl beide systemen ook veel beter presteren met tweekanaalsgeheugen in plaats van een enkel reepje.

Op basis van de benchmarks moeten we concluderen dat de geheugenkeus voor de prestaties over het algemeen weinig uitmaakt. Extra geheugen heeft weinig invloed, terwijl strakkere timings al helemaal geen zoden aan de dijk zetten. Als je een losse videokaart gebruikt, lijk je dus prima voor goedkoop geheugen te kunnen gaan, maar wel in kitjes van twee en zoveel je wilt. Twee reepjes van 4GB is echter al snel genoeg.

Wie echter de ingebouwde gpu van zijn processor wil gebruiken, bijvoorbeeld om games te spelen zonder losse videokaart, doet er wel verstandig aan te investeren in rap geheugen. Wie het geheugen op 1600MHz laat tikken, doet vooral de gpu van AMD-apu's zwaar tekort; die presteren veel beter met snel geheugen. Ook Intel-gpu's betalen de investering in snel geheugen terug met betere framerates. Een setje van twee geheugenmodules is in alle gevallen een stuk sneller dan een enkel reepje, maar een systeem zonder losse videokaart zou eigenlijk niet met een enkel reepje gebruikt mogen worden.

Reacties (241)

[_Pussycat_]

Als we naast de cpu ook de gpu met Furmark belasten, zijn er wat duidelijkere verschillen tussen de verschillende kitjes. Intel haalt rare trucjes uit met het energiebudget van de processor, maar vooral AMD laat zien dat extra geheugen ook flink wat energie kost.

Ik denk niet dat het geheugen de energie verbruikt, maar dat de iGPU meer energie verbruikt omdat hij meer data krijgt (en daarmee meer FPS produceert). De conclusie dat "geheugen energie kost" ist volgens mij gewoon fout.

Er zijn ook benchmarks die de geheugenbandbreedte belasten zonder de CPU te belasten, dat lijkt me hiervoor een beter test.

[xback]

Om te beginnen:

Excuses als het wat door elkaar loopt .. t'is niet eenvoudig om al deze info in een post te verwerken
Ik ga nog editeren waar nodig om het leesbaarder te maken ..


Start

"c" = clockcycles

Een eenvoudige instructie kost 1c (vb : "Add EAX, EBX" (register EBX optellen bij EAX)


Stel : De CPU heeft data nodig die niet in een register zit, en wil deze ophalen.
Dit gebeurd in onderstaande volgorde, maar het kost een aantal cycles dat de CPU dient te wachten alvorens de data klaar staat voor gebruik.
Dit noemt met een "stall"


1. Check L1 cache
Data aanwezig : 4c

2. Check L2 cache
Data aanwezig : 12c

3. Check L3 cache
Data aanwezig : 36c

4. Check RAM
Data aanwezig : ~120c

5. Check HDD
Ophaaltijde : 13ms (1000'en cycles)

Cache Hiërarchy
Cache latency
Haswell memory stall

Het kost dus ca 120c om een byte op te halen uit RAM
(64bytes in feite, maar ik kom hier later op terug)

Deze 120c is vb met 9-9-9-24 RAM

Maken we nu de vergelijking met RAM met strakke timings : 7-7-7-27
120 - ( (2 + 2 + 2) - 3) = 117C (2,5% lager)


Dit is ook ruwweg de gemiddelde winst die je ziet in de meeste benchmarks.


Waarom maakt dit meestal niets uit in de meeste software ?

Veel software is een onvoorspelbare mix van sequentiele & random access (zie hieronder)
De grootste tijd dat software data verwerkt, komt deze sequentieel binnen.
Slechts een kleinere fractie van het aantal reads gebeurd random.
Op een gegeven moment is de CPU verzadigd met data, en boek je geen winst meer met snellere RAM.

Bij sequentiele reads komt de magie van Latency Hiding erbij en elimineert de nood aan strakke timings.


Wat is Latency Hiding ?

Bij een leesbewerking vanuit RAM, gebeurd dit in blokken gelijk aan de cache line size.
Zo goed als iedere x86 vanaf de pentium 1 heeft een cache line size van 64Bytes.
Dit betekent dus als ik 1 byte wil uit RAM, dat er 64 bytes gelezen worden in die 120 cycles.

Stel nu dat ik byte per byte aan het processen ben, en dit voor 128 bytes,
dan zal de CPU tijdens het processen van de eerste 64 bytes, reeds in parallel op de achtergrond de volgende 64 gaan ophalen
en op de volgende cache lijn plaatsen.

Wanneer ik byte 65 inlees, is deze reeds aanwezig in cache, en verlies ik niet opnieuw 130 cycles, maar slechts 4(L1) .. 12(L2) of 36(L3).
In de praktijk zal dit meestal vanuit L1 zijn.
Zolang ik dus sequentieel data uitlees, zelfs al is dit verschillende gigabytes, zal de latency steeds maar 4 cycles zijn.
Het lijkt dus net alsof alle data uit de snelle cache lijkt te komen & die dure latency van 120c niet bestaat !!

In sommige BIOS'en zie je soms de optie "adjecent cache line read". Wat hier betekend dat de CPU altijd al de volgende lijn zal ophalen.
Tegenwoordig gebeurd dit op een arbitraire manier (enkel indien nodig) en dit wordt dynamisch ingeschat door de CPU.


Sequentieel:
- Ik vraag data op
-> CPU haalt 64 bytes uit RAM regio "A" (130c latency)
- Ik process 64 bytes
-> CPU haalt terwijl in parallel de volgende 64 bytes uit RAM (Regio "A" + 64)
- Ik process de volgende 64 bytes (4c latency)
-> CPU haalt terwijl in parallel de volgende 64 bytes uit RAM (Regio "A" + 128)
- Ik process de volgende 64 bytes (4c latency)
-> CPU haalt terwijl in parallel de volgende 64 bytes uit RAM (Regio "A" + 192)
- Ik process de volgende 64 bytes (4c latency)
enz.

Totale latency : (in c)
130 + 4 + 4 + 4 + 4 + 4 + 4 + 4 ........ 4 + 4 + 4 .... 4 + 4 + 4

- 1x 130c latency bij aanvang
- 4c latency per byte


Random read:
- Ik vraag data op
-> CPU haalt 64 bytes uit RAM regio A (130c latency)
- Ik process 64 bytes
-> CPU haalt terwijl in parallel de volgende 64 bytes uit RAM (Regio "A + 64")
- Dit is niet de gewenste data ! Ik wil de data uit regio "K"
-> CPU haalt 64 bytes op uit regio "K", terwijl ik 130c zit te niksen ..
Ik process de volgende 64 bytes (130c latency !)
-> CPU haalt terwijl in parallel de volgende 64 bytes uit RAM (Regio "K" + 64)
- Dit is niet de gewenste data ! Ik wil de data uit regio "Z"
-> CPU haalt 64 bytes op uit regio "Z", terwijl ik 130c zit te niksen ..
enz.

Totale latency : (in c)
130 + 4 + 4 + 4 + 4 + 4 + 4 + 4 ........ + 130 + 4 + 4 + 4 + 4 ... + 130

- 1x 130c latency bij aanvang
- 4c latency per byte
- 130c latency na elke 64 bytes


In dit voorbeeld lezen we byte per byte uit.
Dit betekend dat we 130c + 256c (4*64) nodig hebben om 1 cache lijn naar de CPU registers te kopieren.
Total : 130 (33%) + 256 (66%)

In de praktijk komen meestal integers voor (4 Bytes lang) die in 1 actie ingelezen worden naar een register (oftewel 4c * (64B / 4) = 64 cycles om 1 cache lijn uit te lezen
Total : 130 (66%) + 64 (33%)


Conclusies:
Bij sequentieel lezen maakt de RAM latency niets uit, zolang de volgende 64 bytes al opgehaald zijn, voor je klaar bent met de eerste 64 te verwerken.
Bij hevige random access, zal je tot ~6 cycles winst maken per 64 bytes .. reken zelf uit


Single, dual, quad channel:
-> 1 RAM channel is 64 bit breed. (8 bytes)
-> Er worden 64 bytes naar cache ingelezen per actie

Single : 64 bit
Dual : 128bit
Tripple : 192bit
Quad : 256bit

Om dus 1 cache line op te vullen dient fysiek volgend aantal reads gedaan te worden :
Single channel : 8 x 8B
Dual channel : 4 x 16B
Tripple channel : 3 x 24B (64 + 8 bytes)
Quad channel : 2 x 32B

Quad channel is dus 4x sneller dan single om 1 cache line op te vullen. (logisch ..)


Wanneer is Dual & Quad dan sneller ?

Sequentieel:
Als een CPU bij een bepaalde taak je cache lines sneller verwerkt, dan dat een Single Channel opstelling ze kan vullen.
Dit is een typisch patroon bij videobewerking applicaties of data compressie.
Hier wordt een grote hoeveelheid data sequentieel gelezen, en zijn de bewerking op de data zelf meestal relatief licht.

Random:
Hier is de winst veel kleiner, daar je véél meer afhangt van de latency, dan van de bandbreedte om een cache line op te vullen.
Het mag vb 10c korter zijn om de lijn op te vullen, je verliest toch nog steeds 130c omwille van de latency.


Ook nog:
Bij veel applicaties merk je geen verschil tussen traag & snel geheugen.
Dit komt omdat de actiefst gebruikte dataset past in de cache, en de CPU dus relatief weinig memory access nodig heeft.


Naar mijn mening zijn er 3 patronen die het meeste voorkomen :

- Sequentiele data, in grote hoeveelheden.
--> Grote kans op winst bij RAM met meer bandbreedte
--> Geen winst met strakkere timings

- Random data
--> Weinig tot geen winst met hogere RAM bandbreedte.
--> Kleine winst met strakkere timings

- Mix, maar kleine dataset (Meeste data komt steeds uit cache, relatief weinig memory access)
--> Kleine kans tot winst met hogere RAM bandbreedte (hangt van CPU cache grootte)
--> Geen winst met strakkere timings


Als extra:

Data kan ook met SSE(2) of AVX(2) ingeladen worden.
Dit houd in dat ik 128b (16Byte) of 256b (32Byte) aan data in 2 .. 3 cycles kan inladen vanuit cache. (aligned read)
Dit betekend dat ik in 8 tot 16 cycles een volledige cache lijn kan inlezen naar de registers.
De aandachtige lezer ziet waarschijnlijk al in dat je een serieuze geheugen bandbreedte nodig hebt om dit tempo van de CPU bij te benen. (en dat strakke timings niet uitmaakt in dit geval)
Ook is het geen toeval dat een SSE load instructie 16 bytes inleest per actie, en dat Dual Channel DDR 16 bytes naar cache stuurt per actie.

Het is dan ook geen toeval dat technieken zoals DDR (tov SDR RAM) en Dual Channel relatief snel geïntroduceerd zijn na introductie van de SSE & SSE2 instructiesets.
Toen werd al snel duidelijk dat single channel SDR RAM de bottleneck begon te worden bij grote sequentiele datavolumes, of kopieeractie in memory


Wanneer is je RAM snel genoeg ?
-> Vanaf je processor geen enkele clockcycle meer verliest door te wachten op een RAM-fetch, en dit met een load van z'n snelste load-instructie. (SSE(2) of AVX(2) register.

Stel dat een CPU exact 100c nodig heb om 1 cache line (64B) uit te lezen en te verwerken, en dat een single channel DDR3 lat 200c nodig heeft om 64B toe te leveren.
De helft van de tijd staat de CPU te "stallen" op input vanuit je RAM.
Switchen we naar Dual Channel, lopen beide gelijk. Je RAM biedt net voldoende bandbreedte om de CPU niet te laten "stallen". Maar gaan we over naar Quad Channel .. is de CPU de bottleneck, en win je niets (RAM heeft maar 50c nodig per line hier, de CPU 100c). Je RAM staat dus te wachten.

Let wel .. dit is pure theorie.
In de praktijk gaat een CPU altijd héél wat instructie uitvoeren op een portie data.
Veel reviewsites tonen aan dat sneller dan DDR 1600 niet echt nuttig is bij games (met discrete kaart).
Dit komt omdat de stalls tot een minimum herleidt zijn, en dus sneller geen zin heeft.

Conclusie :
- Vanaf dat je CPU verzadigd is, en de memory-stall's tot een minimum herleid zijn, win je 0% performance door sneller geheugen te gebruiken.
- De manier hoe een applicatie data verwerkt (groot ? sequentieel ?) geeft de user al een aardige hint of méér, sneller en/of strakker geheugen invloed zal hebben.
- De grote caches tegenwoordig, ingebouwd in de CPU, zijn meestal meer dan groot genoeg om de drukste datasets van een applicatie volledig te kunnen bevatten, wat het aantal memory transacties dramatisch reduceert.

Als afsluiter : Leuk weetje
Intel kondigde geruime tijd geleden aan dat AVX-512 op de planning stond.
Stel je dit voor : 1 volledige cache lijn uitlezen in 2 tot 3 clockcycles !
Daar staan we dan vandaag met onze Quad Channel DDR3 .. die al 2 reads moet uitvoeren om 1 lijn op te vullen .... en dan gebruiken we nog maar !! 1 !! core .......

[Reactie gewijzigd door xback op 22 juli 2024 19:43]

[Anoniem: 63975]

De conclusies die ik aan deze test kan ontlenen, is dat het beter is twee reepjes te gebruiken i.p.v. 1.

Dat 8GB de juiste hoeveelheid is.

En dat het een slecht idee is DDR3-1600 te kopen als je geen externe GPU gebruikt.

Welke snelheid dan beter is wordt niet vermeld, maar dan moet je toch standaard overklokken? En je kan wel sneller geheugen in een mobo prikken, maar als dat wordt aangestuurd op DDR3-1600 is de snelheidswinst alsnog nul. (Toch?)

Balen trouwens dat er voor socket 1150 geen chipset is die het geheugen quad channel aan kan spreken.

[Reactie gewijzigd door Anoniem: 63975 op 22 juli 2024 19:43]

[sdk1985]

De conclusies die ik aan deze test kan ontlenen, is dat het beter is twee reepjes te gebruiken i.p.v. 1

Voor die conclusie had je dit artikel niet nodig... Daarnaast is hij ook niet helemaal accuraat. Heb je een dual channel moederbord dan werk je per 2, heb je tripple channel dan werk je per 3, enz.

Dual en Triple channel

Om de geheugen bandbreedte sneller te laten stijgen dan de ontwikkeling van het geheugen zelf is aan de kant van het moederbord een oplossing bedacht. Via de geheugencontroller is een tweede parralelle verbinding met het geheugen mogelijk. Deze techniek heet dual channel. Het voordeel van deze techniek is dat de bandbreedte effectief wordt verdubbeld.

Triple channel geheugen is een vergelijkbare techniek maar maakt gebruik van sets 3 modules om de bandbreedte nog verder op te voeren.

Een moederbord heeft in het algemeen 4 of meer geheugensloten waarbij er een aantal sloten dezelfde kleur hebben. Om gebruik te maken van dual channel moeten de geheugen modules in dezelfde kleur sloten geplaatst worden. Om compabiliteit te garanderen zijn sets van 2 geheugenmodule's te koop. Deze geheugen modules zijn tegelijk geproduceerd en hierdoor worden problemen voorkomen.

Voor tripplechannel geheugen zijn kits van 3 stuks te koop. Let op dat het dual channel systeem wordt uitgeschakeld indien 3 geheugen modules worden geplaatst in een moederbord met alleen dual channel ondersteuning. Pas bij plaatsing van een vierde module zal dual channel weer werken. Let dus op of uw moederbord dual of tripple channel geheugen ondersteund.

http://www.pcinside.info/nl/hardware/geheugen

Indien je één module in een dual channel moederbord plaats dan halveer je effectief de bandbreedte. Het verschil in bandbreedte tussen bijvoorbeeld 1600 en 2133 mhz is overigens veel kleiner en schaalt niet 1:1 met de toename van het aantal mhz.

Gewoon doen wat de bedoeling is. Dat geldt eigenlijk ook voor 1600mhz, Intel en of AMD adviseren niet voor niets een bepaalde snelheid. Voor Haswell is 1600mhz de standaard, voor Sandy Bridge was het 1333mhz.

Geheugen is als een snelweg; heb je te weinig banen dan staat er file en moet je wachten. Maar een 16 baans snelweg in burma (topgear ) maakt je vrachtwagen niet sneller (je cpu).

Overigens testen ze bij bittech wel vaker de impact van geheugensnelheden en dan kom je recentelijk in Battlefield 4 toch enkele fps tegen: http://www.bit-tech.net/h...-4-performance-analysis/9 Zoals altijd (de laatste 10 jaar) blijft het netto effect van "sneller" geheugen beperkt tot 5%.

[Reactie gewijzigd door sdk1985 op 22 juli 2024 19:43]

[Wim-Bart]

Gewoon doen wat de bedoeling is. Dat geldt eigenlijk ook voor 1600mhz, Intel en of AMD adviseren niet voor niets een bepaalde snelheid. Voor Haswell is 1600mhz de standaard, voor Sandy Bridge was het 1333mhz.

Als je daarbij in de specsheets duikt dan wordt jouw stelling ook helemaal onderbouwd. De aanbevolen snelheid is de optimale snelheid waardoor er bij aansturing "extra" gedaan moet worden. Als je kijkt naar SB, daar is 1600mhz onzinnig ten opzichte van 1333mhz, marginaal zelfs, ioptimaal zou 2666mhz zijn of een factor 4, maar helaas bestaat dat dus niet. Bij Haswell is 1600mhz het optimum en alles hoger en lager is gewoon zonde van het geld, of je moet 3200mhz gaan zitten. Als je diep in de specsheets duikt zie je nog iets anders. Stel je hebt een SB en 1600mhz geheugen, dan levert de cpu het gewoon op 1333mhz aan alleen zorgt de electronica er voor dat er waits worden ingebouwd bij wegschrijven. Alleen inlezen zou sneller zijn, ware het niet dat dit alleen richting cache geschied en niet de daadwerkelijke cores in.

[Tourmaline]

Je kunt inderdaad terecht concluderen dat de hoeveelheid reepjes en de hoeveelheid geheugen er meer toe doen dan de snelheid van het geheugen. Het is ook wel simpel te verklaren, het geheugen is niet de beperkende factor.

[poor Leno]

Beetje raar dat in veel testen het schijnbaar niet zoveel uitmaakt allemaal.. Zijn dan niet de benchtests verkeerd gekozen?

Ik zou graag een hevig RAM render programma getest zien, zoals AfterEffects e.d. Daar ga je het verschil goed zien..

[Selmer]

Inderdaad, of een leuke render in Cinema 4D met GI aan. Denk dat daar inderdaad de winst van extra RAM ligt.

Photoshop is niet eens zo'n heel zwaar programma, in vergelijking met het (terecht door jou genoemde) AE.

[Tourmaline]

Als je met raw files van 50MB+ werkt dan gaat het geheugengebruik in photoshop ook snel omhoog als je aan het editten bent. Jammer dat ze meerdere zware apps niet getest hebben want dan ga je pas echt merken dat die zware apps dan ook gewoon nog lekker snel en soepel draaien met veel geheugen.

Daarnaast hadden ze sommige photoshop filters moeten testen want sommige renderen via geheugen en anderen via gpu. Dan maakt het ook een verschil.

[Reactie gewijzigd door Tourmaline op 22 juli 2024 19:43]

[Blaise]

Als je meerdere zware apps gebruikt ga je toch pas een verschil zien op het moment dat het geheugen niet meer in de RAM past? Het verschil meten tussen Virtual - en niet-Virtual Memory lijkt me niet heel interessant, je weet al dat dat heel traag is, en het vertroebelt de performance-data van de RAM met de performance van je harde schijf.

[Tourmaline]

Neen, je kunt 64 bit apps testen met 8 en bijv. 16gb geheugen en kijken hoe soepel dat loopt met 1 of 4 programma's open. Ook kun je meer geheugen toewijzen voor sommige apps zoals photoshop zodat je niet zo snel aan je geheugen limiet zit.
Met bijv. 4gb krijg je in photoshop met grote bestanden al snel een memory error!
Heb maar eens photoshop, indesign en illustrator open met 4gb ram, 8 of 16gb ram, dan ga je dat al wel merken!

Tevens zou je als je meer geheugen erin zet een ramdisk kunnen aanmaken en van daaruit photoshop draaien, dan gaan filters e.d nog een stuk sneller omdat het geheugen nu eenmaal sneller is dan welke schijf dan ook, ja ook SSD's!
Photoshop gebruikt zowel geheugen/cpu alsook gpu voor het renderen dus filters die het geheugen gebruiken gaan daarvan profiteren.

Ook voor games gaat dit verhaal op omdat ze dan nog sneller laden. Meer geheugen is altijd welkom. Snelheid is tegenwoordig niet meer zo van belang omdat je er in de praktijk weinig van merkt, maar de hoeveelheid geheugen heeft weldegelijk invloed op het soepel en snel werken van je systeem. Vooral als je veel zware programma's tegelijk moet of wilt draaien.

[Femme]

Het is niet eenvoudig om de invloed van meer geheugencapaciteit goed te kunnen testen. Photoshop is inderdaad een voorbeeld van een applicatie die veel geheugen gebruikt (en daar onvoorstelbaar inefficiënt mee omgaat). Je zou dit kunnen testen door bewerkingen los te laten op grote documenten van bijvoorbeeld 4GB uncompressed. Dit lijkt absurd veel maar ik heb er bij gewoon wat ontwerpen van pagina's op Tweakers regelmatig mee te maken. Simpele handelingen zoals het verplaatsen van wat layers kunnen erg lang duren als Photoshop de scratchfile moet gebruiken. Bij mij groeit die scratchfile soms naar meer dan 100GB.

Zelfs als je een test verzint waarin het effect tussen verschillende geheugencapaciteiten zichtbaar is wil dat niet zeggen dat het ook maar op enige manier representatief is voor de prestaties van Photoshop. Het hangt namelijk volledig af van de workload. Bij andere applicaties zal dat hetzelfde werken.

In de praktijk merk je snel genoeg of je regelmatig een tekort aan geheugen hebt. Het wordt dan tijd om te upgraden of bij de aanschaf van een volgend systeem een apparaat met meer geheugen uit te zoeken.

[Bosmonster]

Hangt er nogal vanaf wat je doet in Photoshop. Ik werk regelmatig in PSD's van rond de 1GB en dan is 8GB geheugen gewoon niet genoeg meer.

[Selmer]

Wat voor werk ben je dan mee bezig? Ben ik wel benieuwd naar. Heb zelf echter nooit 'last' gehad, omdat ik nu al een aantal jaren 16GB 1600MHz gebruik.

Werk soms wel met grote RAW files(zoals Tournaline ook terecht noemde) en dat merk je inderdaad ook wel in Photoshop. Echter blijft 1080p renderen heavy. 1440p, 2,7K en 4K wordt al minder leuk qua render tijden.

Maar over een paar jaar lach je gewoon om de rendertijden van vandaag de dag, die ontwikkeling gaat zo ontzettend snel. Wanneer komt er eigenlijk DDR4 RAM? Begin Q1/Q2 2015?

[Tourmaline]

Binnenkort. Na de vakantie/herfst.
De extreme 8 cores van intel zijn al aangekondigd en die gaan met ddr4 werken.

[Tourmaline]

Klopt, 3d en video rendering zijn inderdaad nog zwaarder. Alhoewel photoshop extended ook 3d heeft!

[Reactie gewijzigd door Tourmaline op 22 juli 2024 19:43]

[HokiPoki]

Hier ben ik het ook mee eens, heb het gevoel dat er vooral gekeken is naar het huis-tuin-en-keukengebruik van systemen.

"De invloed van de hoeveelheid geheugen in het dagelijks gebruik valt eerlijk gezegd wat tegen."

Dit had misschien beter kunnen zijn: De invloed van de hoeveelheid geheugen valt eerlijk gezegd wat tegen bij mainstream gebruik.
Maar dan rijst natuurlijk de vraag of de benchmarktools een goeie graadmeter zijn voor de prestaties van een systeem dat bijv. virtualisatie of after effects rendering. En daar heb ik te weinig kennis voor om over te oordelen .

[djunicron]

Naar mijn mening is dit inderdaad een beetje een "loze test". Niet dat het niet informatief is, of verkeerd uitgevoerd...

Maar wanneer heb je nou werkelijk in de praktijk 16GB ram of meer nodig? Niet voor mainstream gebruik. En goed, dan weten we nu dat als je wilt gaan gamen je liever óf strakke timing wilt hebben, óf gewoon een 2133mhz (+) strookje.

Maar voor virtualisatie, heb je een sloot geheugen nodig. En zoals wel al getest, voor grote photoshop / lightroom exports is het ook nuttig. Maar in mijn ervaring zijn voor virtualisatie en dat soort taken al snel andere bottlenecks te vinden. Dan gaat het echt niet uitmaken of je 32GB ram nou op 1600 cl9 of 2133 cl11 draait. Je opslag controller zit je vaak in de weg bijvoorbeeld. Ik heb zo een test setje win 2012 draaien in een dev bak, en daar is de 2x 840 pro SSD setup toch echt de bottleneck.

Wat betreft photoshop, pas bij extreem werk gaat deze echt wat doen met je ram. Maar goed, niet veel mensen zullen meer dan 5 a 6 uur per foto bezig zijn om dit soort gebruik te evenaren:
http://tweakers.net/ext/f/ajApvaDkoa6E4wztsQni7pY9/full.jpg
En dan kom je opeens achter wat andere jammerlijke dingen, zoals dat CS6 64bit b.v. niet meer dan 3GB vram en 16GB ram wil gebruiken van nature. (tijdens deze sessie heeft het namelijk ook nog 20GB op de scratchdisk in gebruik)

Maar één ding wat wel als een paal boven water staat: Meer ram in een systeem dan ooit nodig is, schaad de performance een klein beetje. Toen ik nog een VM-capable systeem nodig had, heb ik nog eens 16GB naast de 8 gezet in m'n privé machine, wat me in games al snel een 3-5% performance verlies gaf. Terwijl synthetische benches aangaven dat het geheugen in totaal 2% sneller was geworden. Ik vermoed zelf dat dit een stukje mismanagement is van Windows, of simpelweg omdat de Memcontroller in de CPU van Intel meer overhead draait.

[Anoniem: 58485]

Ik heb 16GB werkgeheugen, merendeels omdat ik het nodig heb.

Ik werk veel met multimedia, en merk dat zelfs 8GB aan de krappe kant was. Nu met 16GB is het vlotter werken met meer, maar in de regel iets trager.

Ik snap het verhaal van latencies in de review ook niet zo, vaak was het zo dat een snellere latencie het beter zou doen dan een hogere bandbreedte. Toms hardware gaf daar ook een review over.

Ik denk dat het te maken heeft met Mapping en combinatie met latency. Het kost ook wat meer tijd om uit een set geheugen van 16GB een bit op te zoeken dan een set van 8GB.

[Tourmaline]

Ga maar eens op een hoge resolutie designen met een paar lagen, kijk maar eens hoe snel je geheugengebruik in Photoshop omhoog schiet!

[djunicron]

Ehm, ja, dat bedoel ik toch ook te schrijven? Hoe denk je dat ik die screenshot anders voor elkaar heb gekregen.

Maar "een 38Mpix Raw file openen" (zoals verder hierboven genoemd) zou ik zelfs al geen huis tuin en keuken taak willen noemen. En een spandoek maat plaat van 10+ layers is ook niet wat de gemiddelde T.net bezoeker regelmatig maakt. En eerlijk gezegd heb ik ook weer niet heel veel files die 40-50GB aan Ram zouden willen hebben. Met m'n normale foto's zou ik eigenlijk met 12GB prima wegkomen. (en dan heb ik het over pano's bouwen uit 16mpix raw files) En daarbij is ook m'n geheugen niet de bottleneck.

Nou zit er wel een verschil in Photoshop geheugen reservering en harde invulling. Iets wat Adobe overigens sinds CS5 er goed voor elkaar heeft naar mijn mening.

[Anoniem: 399]

Maar dan rijst natuurlijk de vraag of de benchmarktools een goeie graadmeter zijn voor de prestaties van een systeem dat bijv. virtualisatie of after effects rendering. En daar heb ik te weinig kennis voor om over te oordelen .

Niemand, ook de Moor niet, zal ontkennen dat als je meer geheugen nodig hebt dan je hebt ingebouwd je PC vertraagt doordat het ding gaat zitten swappen. Maar dat is niet wat er getest wordt (en sowieso niet iets wat heden ten dage nog geen vraag zou kunnen zijn, absolute basiskennis...)

Wat er getest wordt is: heeft het zin om sneller (duurder) geheugen te gebruiken als je al genoeg had. En dat antwoord, wat trouwens niet geheel onverwacht was, is "nee".

Natuurlijk is dat wat anders dan "Als je dit soort afbeeldingen rendert, heb je dan meer dan 640K nodig."

[Reactie gewijzigd door Anoniem: 399 op 22 juli 2024 19:43]

[sfranken]

Bij virtualisatie moet je niet eens aankomen met 16GB (als je het serieus aanpakt dan). Begin bij een virtualisatieplatform maar rustig bij 32GB RAM..

[leuk_he]

Nee, niet mee eens. Benchmarks moeten het dagelijks gebruik meten. En een conclusie dat duur geheugen voor bepaalde toepassingen niet uitmaakt is ook belangrijk. (geen resultaat is ook een resultaat.)

[poor Leno]

Nee dat is zeker niet zo.. Wat heb je aan een test die alleen laat zien dat t niets uitmaakt?

Een goede test zou laten zien dat in sommige gevallen het niet uitmaakt en aan de andere kant weldegelijk uitmaakt als je bepaalde applicaties gebruikt.

Er staat nergens dat deze test enkel voor de gewone consument bedoeld is om geld te besparen oid. Dit is een test om RAM aan de tand te voelen. Benchmarks moeten ook de limieten tonen en mogelijkheden, niet alleen een dagelijks gemiddelde.

[Reactie gewijzigd door poor Leno op 22 juli 2024 19:43]

[boomr]

Dat zijn leuke tests om te zien en je gaat daar waarschijnlijk veel meer verschil tegenkomen dan bij de gekozen tests. Voordeel van deze tests is dat het duidelijk laat zien dat er voor dagelijks gebruik weinig verschil zit en dat sneller geheugen een grotere winst geeft dan meer!

[AMD_Aero]

Daar ben ik het met je eens.
Toch was ik verbaast over de strakke timing lagere performance.

Misschien ook nog een idee om de verschillende frequenties/latencies te testen d.m.v. er een ramdisk van te maken en dan de "rauwe" snelheid op meten. Niet meteen het nuttigste maar ben wel benieuwd hoeveel het hier zou in schillen.

[Dutch Lion]

Het zou goed zijn om te vermelden welk besturingssysteem er wordt gebruikt op de test systemen. Uit de gebruikte programma's kan ik wel opmaken dat dit Windows geweest is. Echter welke versie dan weer niet.

Het had helemaal leuk geweest als jullie misschien hadden kunnen kijken hoe verschillende besturingssystemen omgaan met meer/minder geheugen.

[sfranken]

Dat merk ik hier ook. Windows op mijn machine (8.1 64 bit) trekt leeg 1.1 GB van de 8 beschikbaar.

Boot ik naar Arch met Gnome 3.x en bekijk ik het dan zie ik opeens 900 MB, van de 8 GB beschikbaar.

Scheelt toch ~200MB

[Dreamvoid]

Trekt Windows werkelijk 1.1 GB (dat zou erg veel zijn), of zet hij 1.1 GB aan cached data in het RAM (dat zou juist erg goed geheugenmanagement zijn)?

[sfranken]

Geen idee, zoveel verstand heb ik niet van hoe Windows dat doet. Ik gebruik misschien 2 dagen in de maand eens een keer m'n Windows installatie (als ik dat al haal).

Als ik de taakmanager open in 8.1 dan zie ik bij RAM 1.1GB staan gebruikt van de 8, dus ga ik ervan uit dat hij hoe dan ook 1.1GB inneemt, hoe die dat doet is me een raadsel

[Wim-Bart]

Bij 16GB trekt Windows 8.1 ongeveer 2.2GB en op mijn 32GB systeem trekt 8.1 ook rond de 2.2GB. Met meer geheugen houd Windows ook meer in het geheugen.

[sfranken]

Ik vraag me af waarom. Ik had hier een dev machine te leen (van een maat) met ongeveer dezelfde hardware maar met 64GB RAM. Ook daar stond Arch op en ook die gebruikte ~900MB, zelfde als mijn Arch systeem.
Toegegeven, het compileren van LO 4.x ging wel een bak sneller

[Tout]

En Arch Linux met Fluxbox draait hier idle op 49MB Dat scheelt toch 851MB.

[Ch3cker]

Windows 8.1 is gebruikt bij deze tests, volledig gepatched.

[ObAt]

Meer geheugen kan heel veel verschil uitmaken. Ik heb als test een Java programma moeten schrijven die 25 miljoen getallen (die in een log bestand staan) moet sorteren op grote en frequentie, de applicatie mocht maximaal 30MB RAM (-Xmx30m) gebruiken. Met een heleboel optimalisaties was het te doen net binnen 1 minuut. Wanneer ik geen RAM limiet had (het programma gebruikte toen ongeveer 1gb aan RAM) was het zonder een enkele optimalisatie klaar binnen 15 seconden.

Zware programma's zoals Photoshop en 3D teken programma's zullen hetzelfde effect laten zien, als ze meer RAM kunnen gebruiken dan zijn ze merkbaar veel sneller. Het verwerken van een zware PSD kan veel sneller als er voldoende RAM geheugen beschikbaar is. Als de data eenmaal naar het geheugen is geladen kan de software er veel sneller bij dan bij een harde schijf (of zelfs SSD), dit wordt echter vaker vergeten. Veel goedkopere laptops worden (helaas) nog steeds met 4gb RAM geleverd (en 64bit software...), terwijl het RAM geheugen niet echt de meeste kosten zijn. Hier wil ik wel een paar tientjes extra voor investeren.

Server software zoals SQL databases leven even echt op RAM geheugen. Zie ook de trend http://en.wikipedia.org/wiki/In-memory_database

Edit: Het is inderdaad MegaByte (@skoozie). De CPU sorteert de getallen gewoon, dit is natuurlijk te optimaliseren maar het ging om het effect te laten zien van een beperkte hoeveelheid RAM geheugen.

[Reactie gewijzigd door ObAt op 22 juli 2024 19:43]

[skoozie]

voor iemand die programmeert vind ik het altijd vreemd om te lezen dat er 30 milibit RAM gebruikt wordt... Ik ga er van uit dat dit 30MegaByte is? omdat Megabit meestal op doorvoer slaat?

Ik vind de conclusie wel heel frappant, ik dacht de meeste snelheids winst in CAS en MHz te zien.
en als je een dedicated GPU hebt dat het echt helemaal niets meer uit maakt...
Er mogen van mij meervan dit soort testen komen. Leuk lees voer!

[Anoniem: 243272]

Op het eerste gezicht is dit een leuke test. Er is veel data verzameld, en het geeft een aardig beeld van de invloed van de geheugenkeuze op de geteste applicaties. Voor de consument dus prima.

Er valt echter wel wat af te dingen op een aantal van de testmethodes en / of de conclusies die aan bepaalde tests verbonden worden. Mijn belangrijkste kritiek is dat het variëren van een parameter die geen invloed heeft op de gemeten waarde alleen ruis op kan leveren als resultaat. Dit is goed te zien in de "Meer is beter?" test. Als geen van de benchmarks een meer dan 2 GB geheugen gebruikt, dan is de verwachting dat alle tests dezelfde uitkomst opleveren. De resultaten lijken dit te bevestigingen. (Bovendien lijkt het me niet handig voor een algemene benchmark om dermate veel geheugen te gebruiken, aangezien het swappen naar de harddisk alle andere performance aspecten die je zou kunnen willen meten overschaduwt.) Conclusies aan deze test verbinden is dus lastig tot onmogelijk.

De "sneller is beter" test meet het effect van geheugenbandbreedte en latency op de applicatie performance. Een hogere memory frequentie betekent hier dat er meer bandbreedte beschikbaar komt tegen een lagere latency (15 tot 20% extra bandbreedte afhankelijk van de vergeleken modules). Wederom lijkt een groot deel van de geteste applicaties niet gevoelig voor memory performance. Hieruit mag je dus concluderen dat deze applicaties (Cinebench R15 Single en Multi met name) al hun data netjes in de cache houden en vervolgens helemaal niets meer met het DDR doen. De resultaten voor die applicaties zijn dus waardeloos in alle tests.

De tegenintuïtieve uitslag van de "timings" test is al veelbesproken. Allereerst: het gebruikte DDR heeft geen Error Correcting Codes (ECC) feature. Het is dus NIET zo dat er meer errors gecorrigeerd moeten worden bij de lagere timings. Er worden überhaupt geen DDR errors gedetecteerd, laat staan gecorrigeerd. (Het zou me trouwens verbazen als de correctie in ECC memory extra latency oplevert, maar helaas ben ik daar niet zo in thuis.)

Het probleem met deze test is dat het een micro optimalisatie is die zelfs als de benchmarktijd 100% geheugengelimiteerd zou zijn vrijwel geen prestatiewinst oplevert. Hier volgen wat grove berekeningen:

De gewijzigde timings zijn CL, RCD, RP en RAS. Bij een page-miss in het DDR duurt het RP + RCD + CL cycles om de eerste data uit het geheugen te lezen, 24 of 27 clock cycles dus. Heb je dus alleen maar page misses, dan gaat de hoeveelheid beschikbare bandbreedte met minder dan 12.5% omhoog (er is wat constante overhead zoals die van refresh en het wisselen tussen reads en writes die niet verbetert. Ook heb ik de read/write-to-precharge (RTP of WL + WR) constraint niet meegenomen. Die zijn constant in beide tests, en verminderen dus de winst).

Een page-hit heeft een latency van CL cycles, 8 of 9 cycles dus. Het is het lastiger te zeggen hoe groot de bandbreedte winst is, aangezien er pipelining tussen verschillende requests is, en je dus niet 8 of 9 cycles hoeft te wachten tot je een volgend DDR request kunt starten. De effectieve bandbreedte winst is dus zeker minder dan 12.5%.

Maar goed: als je processor staat te wachten op deze data (alleen bij read-requests dus), heb je 1 of 3 cycles op de totale latency gewonnen. Wat is die total latency? Dat weet ik niet precies, maar de ordegrootte is redelijk af te schatten. Deze bron (https://www.inkling.com/r...5th/chapter-2/section-2-6) schat de L3 instructie cache miss latency van een I7 op 35 CPU cycles. Daarna moet er met het DDR gecommuniceerd worden (zeg 3 cycles heen, 3 cycles terug), dat is in totaal grofweg 12 ns op 3333 MHz. Plus de latency van het DDR (33.75 ns (27 cc, los) of 30 ns (24 cc, strak) voor misses, of 12.5 ns (9 cc, los) of 10 ns (8 cc, strak) voor hits) geeft een maximaal performance verschil van (12 + 12.5) / (12 + 10) --> 11 %, als je CPU niks anders aan het doen is dan wachten op read requests van het DDR. In werkelijkheid doet je CPU veel meer dan alleen wachten op data (namelijk rekenen), en is het percentage L3 misses bij normale programma's gemiddeld minder dan 5% (zie dezelfde bron weer). Totale winst op de executietijd van de benchmark is dan 11 % * 5% * % CPU tijd gespendeerd aan DDR requests. Dat is dus ongeveer 0.55 % winst. Voor een GPU ligt dat waarschijnlijk wat hoger (want minder grote / effectieve caches), maar het is hoe dan ook marginaal. (zie ook de prima reactie van xback die via een andere weg op ongeveer dezelfde conclusie uitkomt (xback in 'reviews: De grote Tweakers-geheugentest'))

Het zou me dan ook niets verbazen als deze hele test bestaat uit meetruis. De "liever los dan strak" conclusie lijkt me niet bewezen op basis van deze test.

TLDR: geen conclusies trekken uit een meting die alleen ruis oplevert is een goed idee.

[Reactie gewijzigd door Anoniem: 243272 op 22 juli 2024 19:43]

[Mathijs]

We hadden verwacht dat strakkere timings juist betere prestaties zouden opleveren, maar het tegendeel blijkt waar, tenminste in onze tests.

Wanneer je niet probeert TRAS ook zo laag mogelijk te draaien zie je zeker wel betere prestaties.
Dat het in dit geval niet zo is, komt omdat de row active time verloopt voor de row helemaal gelezen is.
Die moet dus weer helemaal opnieuw active gemaakt worden en dat kost meer tijd dan loose timings.

Om het juist te doen, stel je CL, TRCD en TRP zo laag mogelijk in waarbij het systeem dus stabiel draait, keer op keer post, etc.
Hierna ga je spelen met de row active time (TRAS) en na een aantal keer bijstellen en benchen, vind je de sweet spot, waarbij je geheugen de kortst mogelijke latency heeft, zonder dat het boek iedere keer wordt dicht geklapt terwijl de bladzijde nog niet helemaal gelezen is.
De theoretische waarde zoals aangegeven op een geheugenbank betreffende TRAS, is TRCD + (2 * CL), maar in de praktijk is een loose TRAS ten opzichte van CL en TRCD dus aan te raden.

Dus bouw die testsetup maar weer op, want nu is de conclusie waarschijnlijk onjuist.

[Reactie gewijzigd door Mathijs op 22 juli 2024 19:43]

[Frozen]

Eindelijk krijgen we weer eens een echte review. Tweakers.net doet hun naam weer eer aan!
Binnenkort ook een casefan vergelijking?

[H!GHGuY]

Gecondoleerd. "Timings tonen iets wat we niet verwachten. We waren echter te lui om uit te zoeken waarom". Dit noem ik niet echt getuigen van doorzetting en technische kennis. Ik had op meer gerekend.

Stel de review dan een week uit en ga op zoek naar de oorzaak (in de community, expertpanels of elders).

[Reactie gewijzigd door H!GHGuY op 22 juli 2024 19:43]

[Anoniem: 325202]

Misschien is het niet echt een onderzoek maar een bevestiging van wat de meesten al wisten. En dat is dat de toegevoegde waarde van geheugen echt minimaal is. Zelfs voor een APU blijkbaar.

[brugj03]

Je zit hier bij tweakers wat verwacht je nu eigenlijk.
Maar even serieus, het is best wel triest om dit soort dingen te lezen. Gewoon een kwestie van ergens geen zin in in hebben of DOM.bezig zijn.

Voor hardware reviews moet je trouwens allang niet meer hier zijn.
Dus nog wat leuke links:

www.hardocp.com
www.guru3d.com
www.anandtech.com

[Wilbert de Vries]

Binnenkort ook een casefan vergelijking?

Pssst: http://ic.tweakimg.net/ext/i/1395136069.png Goed genoeg?

[Frozen]

Psst, processorkoeler =/ casefan
Overigens was dit meer dan 1 maand geleden al bekend: http://gathering.tweakers...message/41760657#41760657

Maar wel hulde dat jullie weer goed bezig zijn daar in HQ!

[Anoniem: 63975]

Ik had wel wat meer info willen hebben over geheugen timings, wat 9-9-9-27 inhoud.

Geheugen heeft niet alleen een kloksnelheid, maar ook toegangstijden tot bits in de geheugenchips. Die worden uitgedrukt in latencies: het aantal klokcycli dat nodig is om een bepaalde handeling uit te voeren. Die handelingen om het geheugen te beschrijven of uit te lezen zijn opgedeeld in een aantal stappen, die ieder een latency hebben.

De latencies zijn achtereenvolgens de cas-latency, row address to column address delay, row precharge time en row active time. Met een kloksnelheid van 1600MHz, eigenlijk 800MHz, levert dat latencies van 1,25 nanoseconde per kloktik op.

Om de invloed van geheugentimings te beoordelen, stelden we de kloksnelheid van onze kitjes van 2x 4GB geheugen weer in op 1600MHz. Daarbij zetten we de latencies, ook bekend als geheugentimings, op 8-8-8-24 en 9-9-9-27.

Kan je zomaar die latency's wijzigen?

En hoe wordt de conclusie gevormd dat 1600MHz geheugen latencies van 1,25 nanoseconde per kloktik oplevert?

Openstaande vragen worden beantwoord @ http://www.hardwaresecret...erstanding-RAM-Timings/26

[Reactie gewijzigd door Anoniem: 63975 op 22 juli 2024 19:43]

[Master_duck]

Ja, je kan zo maar de Latency's wijzigingen. Hier mee vertel je eigenlijk wanneer het systeem het geheugen kan aansturen.
1600M / 2 = 800M (bus snelheid) 1/800M=1.25nS
En dan nog zou weten we niet waarom strakkere timing niet sneller is, zoals in dat artikel staat dat strakkere timing sneller moet zijn. 8 of 9 zit dik 10% verschil in maar dat zijn we niet. We zien wel dat het zelfs negatief effect heeft.
Mij verklaring:
Het geheugen kan deze timing niet aan ondanks the spec van de fabrikant. Er wordt een fout gemaakt. waardoor je dus opnieuw moet beginnen en daar zit het tijd / snelheid verlies in.

Je zou dit kunnen testen met de performance monitor in windows 7.
Add -> Memory -> fault per sec.
Waarschijnlijk zie je dan meer fouten voorbij komen bij strakkere timmings.

[Anoniem: 243272]

Je verklaring klopt niet. Je mag er vanuit gaan dat de specs van de fabrikant kloppen. Als je geheugen een fout maakt is dat (waarschijnlijk) catastrofaal, en er is niets in een normaal systeem (zonder ECC) dat dit kan detecteren. Er is dus GEEN mechanisme dan een lees of schrijfactie herhaalt als er iets mis gaat, er is zelfs geen detectie van fouten.

De entry in de performance monitor gaat over hard faults, voor zover ik kan zien zijn dat page-faults die naar je swap doorverwezen worden.

[MacGrumpy]

fault per second betekend niet dat je geheugen fouten aan het maken is. (1)

Je ziet geen speedup ziet van 'strakkere timings' omdat dit een heel klein element in de hele keten is. Er zitten o.a. verschillende caches tussen en ook is de vraag of hier het geheugen de grootste bijdrage aan het bottleneck is. Amdahl's law zal er waarschijnlijk voor zorgen dat er geen zichtbaar verschil is. (2)


1. http://answers.microsoft....7e-e011-9b4b-68b599b31bf5
2. https://en.wikipedia.org/wiki/Amdahl%27s_law

[Reactie gewijzigd door MacGrumpy op 22 juli 2024 19:43]

[robvanwijk]

Maar "geen verschil" is niet wat er gebeurt; strakkere timings maken de benchmark meetbaar langzamer. Net als vele anderen vind ik het ook jammer dat dit verschijnsel alleen vastgesteld wordt; een verklaring zou nog veel interessanter zijn (helaas heb ik zelf ook geen idee waar het aan zou kunnen liggen).

[brugj03]

Bij tweakers word zover ik weet alleen melding van dingen gemaakt, het uitzoeken van oorzaak en gevolg valt niet binnen het kader.
Reden te meer om even verder te kijken naar de betere hardware sites.
Bijv.

guru3d.com
hardocp.com
anandtech.com