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 , , 90 reacties
Bron: TBreak

Omdat er legio reviews over processorsnelheden en videokaartprestaties te vinden zijn, besloot TBreak even na te gaan of meer geheugen wel altijd betere prestaties betekent. Voor het benchmarken werd gebruik gemaakt van een Ferrari 3200-laptop die standaard over twee modules van 256MB beschikt. De processor is een Athlon64 2800+ en het scherm wordt aangestuurd door een Radeon 9700 met 128MB werkgeheugen. De tests werden uitgevoerd met een hoeveelheid van 256MB, 512MB en 1GB RAM-geheugen. In de eerste test werd gebruikgemaakt van PC Mark en blijkt de invloed van de hoeveelheid geheugen helemaal te verwaarlozen. Met een maximale stijging van veertien punten zal men dus geen merkbare prestatieverbetering hebben als het op deze test aankomt.

Verschillende geheugenmodulesZowel in de integer- als float-tests van Sandra 2004 zien we dit fenomeen terugkeren, met zelfs een prestatiedaling bij het toevoegen van extra geheugenmodules. Ook andere benchmarks als 3D Mark 2005 en Aquamark 3 lieten geen relevante prestatiewijzigingen zien. Tot zover echter de synthetische tests. Wanneer gemeten werd in de praktijk, met echte games, verbeterden de prestaties namelijk wel. Zo haalde men met Counter-Strike: Source vier procent meer frames per seconde met 1GB RAM-geheugen, en verbeterden de prestaties in Doom 3 zelfs met 113 procent.

Far Cry deed het iets gematigder en haalde 41 procent meer frames per seconde en UT 2004 leverde een prestatiewinst op vergelijkbaar met Counter-Strike. Ook in andere software, waaronder Photoshop, Nero, Office en Mozilla werden prestatieverbeteringen tot 42 procent gemeten. De reviewer besluit dan ook dat 512MB werkgeheugen zeker niet overdreven is. Gebruikers die veel met grote bestanden werken zullen zelfs tevreden zijn met 1GB RAM, maar de invloed op de prestaties is bij elke applicatie anders, zodat men elke situatie apart moet beoordelen op geheugengebruik. Zo daalden de prestaties in 3D Studio met 31 procent bij een geheugenhoeveelheid van 1GB, vergeleken met de standaard aanwezige 256MB.

Moderatie-faq Wijzig weergave

Reacties (90)

Mijn insziens moeten ze toch ook eens benchen
voor de multitaskende medemens. Wanneer je
je photoshop open hebt met wat grote bestanden geladen,
een editor, een firefox, messenger en ga zo maar door
wordt geheugen als maar belangrijker. Als je dan
met 256 mb zit wordt het HD-ratelen geblazen ;)

greetz
Precies, vooral dat laatste is van belang.

Bij een laptop is de HDD veel eerder de beperkende factor. Als ik hier dikke apps open heb dan merk ik dat meteen op mijn laptop. Het geheugen zit vol, en de laptop begint te swappen. Met meer werkgeheugen kun je het virtueel geheugen kleiner maken, zodat er meer gebruik wordt gemaakt van het snellere RAM geheugen.

Nadeel is alleen, dat RAM bij mijn weten meer energie vreet, en dat daardoor de accuduur van de laptop achteruit gaat.

De conclusie van deze test vind ik dus simpeleg logisch. Er wordt minder gebruik gemaakt van het virtueel geheugen, en meer van het RAM geheugen, omdat er meer in past. Daardoor worden de prestaties beter.

De vraag blijft echter wat nodig is, die extra snelheid of de langere accuduur. Persoonlijk wacht ik dan liever ietsje langer op de pieken en dat ik dan mijn laptop langer kan gebruiken. En dat geld waarschijnlijk voor de meeste laptoppers, want dat ding koop je immers om mobiel te zijn. Wat ik wel kan aanraden is om zeker wel 512MB te kopen, dat prestatieverschil is aanzienlijk vergeleken met 256MB. Er wordt dan stukken minder geswapped, en dat bevordert de prestaties flink. (Windows XP krijgt die 256MB namelijk zonder moeite vol)
Met meer werkgeheugen kun je het virtueel geheugen kleiner maken, zodat er meer gebruik wordt gemaakt van het snellere RAM geheugen.
Meer werkgeheugen betekent doorgaans ook een grotere page file, als je het tenminste volgens MS richtlijnen instelt. Er wordt pas geswapped als je fysieke geheugen vol is, dus dit kun je dan ook gerust doen, als de vrije schijfruimte het toe laat...
Die MS richtlijnen zijn al 10 jaar oud of zo, wat was het nu weer? 1,5 x het werkgeheugen = virtueel geheugen? Dit gaat tegenwoordig echter volledig niet meer op, als je 1GB RAM of meer hebt kan je je virtueel geheugen juist afzetten voor betere performance, of op een vaste waarde van een paar honderd MB's.
@Ranzy

Nee! Niet afzetten, ga maar eens googlen op het wel of niet afzetten van je pagefile. Het wordt namelijk voor meer gebruikt dan alleen het swappen van geheugen. Het is wel zo dat op een gegeven moment de 1,5x zo groot niet meer van toepassing is. Elke service/applicatie binnen Windows kan namelijk nooit meer dan 3Gb (op enkele speciefiek op AWE gebaseerde technieken geschreven applicaties na dan) gebruiken. Op het moment dat je server/werkstation gaat staan swappen, heb je gewoon te weining geheugen en zou je er goed aan doen geheugen bij te zetten.
Nee! Niet afzetten, ga maar eens googlen op het wel of niet afzetten van je pagefile.
Gewoon doen als je 1/2 of 1 gbyte RAM hebt. Als je een foutmelding krijgt dat er toch te weinig RAM is, kun je de pagefile altijd weer aanzetten.
Idd, ik heb hem dan ook aan staan op een vaste waarde van 300MB, wat volgens velen de beste manier is. Photoshop deed moeilijk dacht ik toen ik hem volledig af zette, maar voor de rest toch geen problemen mee gehad hoor...
@Olaf van der Spek
Niet afzetten is gewoon aantoonbaar beter. Dus je kan eigenwijs zijn en het afzetten, maar het blijft beter om het niet af te zetten.
Ook ik heb mijn hoofd daar aan gestoten, maar als jij ook graag je hoofd stoot, vooral doen! ;)
[In reactie op Ranzy:] Variabele grootte op een partitie alleen voor de swap file is nog beter.
Een partitie alleen voor de swapfile is de grootste onzin die er bestaat. (Waarschijnlijk veroorzaakt doordat linux speciale swappartities kan maken)

De regel is heel simpel:
Een swapfile zet je neer op de meeste gebruikte partitie op de minst gebruikte schijf. (Dit geldt altijd en voor elk OS!)

Verder moet je zorgen dat een swapfile niet varieert in grootte zodat ie niet gefragmenteerd raakt. Je zorgt dus dat de minimum grootte groot genoeg is voor de normale werkzaamheden. Je mag dan verder wel de maximale grootte variabel maken om te zorgen dat je niet te weinig swapruimte hebt als een programma het bij uitzondering een keertje nodig heeft.
OlafvdS wrote:
Gewoon doen als je 1/2 of 1 gbyte RAM hebt. Als je een foutmelding krijgt dat er toch te weinig RAM is, kun je de pagefile altijd weer aanzetten.
Jaja, doe maar hoor. Niet op letten dat je dan geheid foutmeldingen krijgt (blauwe schermen zijn ook mogelijk) natuurlijk, dan is de grap weg.
Als je niet elke keer dat j een spel start wilt moeten rebooten om je swapfile aan te zetten, freeze hem dan op 512 MB of 1GB. Ondanks het feit dat er 2 GB in m'n PC zit wordt daar gewoon geswapt als ik vanuit Doom middels alt-tab even naar Nero spring om de volgende DVD te gaan branden, zeker als er ook nog een DivXje geript wordt op d achtergrond. Die swapfile is feitleijk vereist om Windows goed te laten lopen.

Als je heel veel RAM hebt (of er minder aso mee om gaat dan ik) kun je wel een ramdrive maken waar je dan weer je swapfile op probeert te zetten, misschien. dát is wél heel snel :)
Een ramdrive waar je een swapfile op zet is nog grotere onzin dan het uitzetten van een swapfile. En het is per definitie nooit sneller.

Door een ramdrive te maken heb je minder Ram vrij waardoor je eerder moet swappen.
Dat swappen gaat dan wel snel op een ramdrive, maar is altijd nog trager dan niet hoeven swappen.

Dat blijkt in de praktijk moeilijk te begrijpen, dus ik zal er een voorbeeld bij doen:
Stel mijn applicatie heeft 1GB nodig.
- Ik heb 1GB RAM beschikbaar dus er wordt niet geswapt en mijn applicatie loopt goed.
- Ik heb 512MB beschikbaar en een 512MB ramdrive gemaakt. Mijn applicatie heeft 1GB nodig, dus er moet 512MB worden geswapt. Dat swappen is een boel extra handelingen, dus ik heb nu mijn applicatie trager gemaakt door die ramdrive. (Niet veel, maar wel wat, en sneller is het dus zeker niet)

Nu gebruikt mijn applicatie 1,5GB.
- Ik heb 1GB ram, dus wordt er 512MB naar disk geswapt. Applicatie wordt erg traag.
- Ik heb 512MB ram beschikbaar en 512MB gebruikt als swap. Vervolgens wordt er dus 512MB naar disk geswapt. Applicatie wordt net zo traag als bovenstaand.

Conclusie, mijn ramdrive heeft geen enkel positief effect.

Een swapfile op ram heeft alleen zin als je het op een solidstate disk zet. Op die manier kan je dan de 4GB ram limiet van je OS wat omzeilen als je 32bit processors gebruikt.
De regel is heel simpel:
Een swapfile zet je neer op de meeste gebruikte partitie op de minst gebruikte schijf. (Dit geldt altijd en voor elk OS!)
Behalve voor Linux, FreeBSD, NetBSD, MacOSX, HP-UX, Solaris, etc. Maar verder voor elk OS inderdaad.

Unix-achtige systemen hebben een aparte swappartitie, met een "filesysteem" (wat dus geen filesysteem is omdat er geen files op kunnen) speciaal geoptimaliseerd om snel te swappen. Wel logisch natuurlijk, waarom zou je een "gewoon" filesysteem gebruiken om te swappen? Verder kun je bij Unix ook beter 2 kleine swappartities op 2 verschillende schijven pakken, dan 1 grote op 1 schijf. Is namelijk sneller.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/vm-tuni ng.html
Het geld net zo hard voor Linux. Die swappartitie is verouderde troep die je niet meer moet gebruiken.

Aangezien je swapfile maar 1 file is, is de invloed van je filesysteem op de prestaties van je swapfile peanuts. (Zowiezo is daar erg weinig aan prestatie in te winnen. Tenzij het normale filesystem van linux etc bagger is, maar dat is niet het geval) De enige positieve invloed die je er van zou kunnen krijgen wordt bovendien volledig teniet gedaan doordat je een extra partitie creeert waardoor je moet switchen van partitie voordat je je swapfile kunt aanspreken.

Ook bij unix geldt dat je je swapfile op de minst gebruikte schijf moet zetten. Dat is ook totaal niet moeilijk om te begrijpen. Als een schijf niet gebruikt wordt, dan is het benaderen van een swapfile op zo'n schijf vele vele en VEEEELE malen sneller dan het benaderen van een swapfile op een schijf die al voor andere dingen gebruikt wordt.

Als je dus 1 schijf hebt die bijna niet gebruikt wordt en eentje die wel gebruikt wordt, dan zet je dus je swapfile op die schijf die bijna niet gebruikt wordt. Dat is veel en veel sneller dan wanneer je een kleine swappartitie op die beide schijven zet.
Alleen wanneer je 3 schijven hebt waarvan er 2 bijna niet gebruikt worden, DAN heeft het zin 2 swapfiles op die 2 niet gebruikte schijven te zetten.

Dat heeft verder geen bal te maken met het filesystem of het OS. Het is gewoon het simpele feit dat een schijf maar 1 ding tegelijk kan doen en als je 2 schijven hebt, dan kan je dus in totaal 2 dingen tegelijk doen. Dus bv schrijven voor je applicatie en swappen tegelijkertijd.
Iedere optimalisatie die je in het OS of filesystem kan doen valt daarbij vergeleken volledig in het niet!

Helaas zijn er veel misverstanden over lokaties van swapfiles, terwijl het echt niet moeilijk is om te begrijpen. Maar omdat tegenwoordig geheugen zo goedkoop is bekommert toch niemand zich meer over swapfiles, dus al die misverstanden zullen nog wel jarenlang blijven.

Overigens is dat positieve effect van het gebruiken van een weinig gebruikte schijf zo groot dat zelfs als die schijf veeel langzamer is dan je "werk"schijf, dat de zaak dan uiteindelijk nog veel sneller is.
(Ooit in een ver verleden toen OS/2 nog modern was en geheugen duur, in de praktijk ervaren. Dat was een goede methode om oude kleine schijven nog nuttig in te zetten)
Windows XP krijgt die 256MB namelijk zonder moeite vol

Valt wel mee hoor, XP pakt niet veel meer dan 60-70 MB, de rest is filecache die gewoon dynamisch verkleind wordt als er meer geheugen nodig is en vergroot als er veel geheugen vrij is. Tel de kernel processes + essentiele service processes maar bij elkaar op, dan weet je wat er daadwerkelijk gebruikt wordt.
Valt wel mee hoor, XP pakt niet veel meer dan 60-70 MB, de rest is filecache
Met 128 mb RAM en een standaard XP install valt anders niet echt lekker te werken, dus zo zuinig is XP ook weer niet.
256 mb is zeer handig en voor een niet budget systeem zou ik zeker voor minimaal 512 mb gaan.
Anders zit je gewoon drie jaar met een gehandicapte computer.
Applicaties zijn grote geheugenvreters. Je moet natuurlijk niet iTunes ofzo gaan draaien als je maar 128 MB hebt (dat neemt alleen al 50+ MB in met alle achtergrond services), gooi er een virusscanner en firewall bij en je raakt al heel snel door je fysieke geheugen heen. Maar het OS los doet echt niet zo heel veel.
Bij mij nu (XP SP2, 256 MB):
kernel: 27 MB
OS services processes: 28 MB
cache: 40 MB
dat is 95 MB. zodra je nu notepad start hangt je pc direct omdat hij dan moet gaan swappen als je uitgaat van 128 MB
Persoonlijk wacht ik dan liever ietsje langer op de pieken en dat ik dan mijn laptop langer kan gebruiken.
Waar wacht je dan op ? Om je laptop langer te kunnen gebruiken ? Ik denk dat het allebei niets uitmaakt, snellerre laptop en sneller werken dan een langzame laptop waarbij je moet wachten maakt volgens mij niets uit voor de levensduur van je accu. Het duurd alleen wat langer.

Ik werk persoonlijk liever door. Dan ben ik wel sneller klaar. :)
waarschijnlijk is zijn treinreis langer dan zijn accu vol kan houden, dus doet hij het wat langzamer en lijkt het in de trein toch of hij druk bezig is :P
Nadeel is alleen, dat RAM bij mijn weten meer energie vreet, en dat daardoor de accuduur van de laptop achteruit gaat.
Volgens mij wordt dit meer dan gecompenseerd doordat de HD minder draaiuren heeft.
Nou, er zijn ook steeds meer laptoppers (waaronder ikzelf) die de laptop gewoon als desktopvervanging gebruiken. Lekker makkelijk even in de woonkamer met de PC werken en daarna weer in de boekenkast zetten. Geef mij maar veel geheugen, heb ik meer aan dan aan de accu.
Niet alle RAM gebruikt veel stroom hor.
DRAM wel omdat ze alle data steeds weer moet herschrijven om te bewaren.
Dat proces kost veel energie.
Is dit niet een beetje een open deur? Btw, het is helemaal niet zo gek dat die integer/fp berekeningen niet sneller gaan. De winst die je boekt door meer geheugen in je kist te stoppen is dat er minder geswapt hoeft te worden, toch? Ik ben niet zo bekend met die testprogramma's, maar dit lijkt me nou niet echt een test die honderden megabytes geheugen sleurpt.

(Ok, die interger/fp berekeningen _zouden_ langzamer kunnen gaan omdat de paginatabellen etc groter in ingewikkelder worden als je meer geheugen neemt)

edit: typo
Deze uitslagen zijn niet zo verwonderlijk. Het hele swapfile verhaal valt buiten dit verschijnsel (mensen overschatten de invloed daarvan op de normale prestaties enorm). De grote winst haal je op de filecache en dll cache: Windows stemt de grootte hiervan af op de hoeveelheid geheugen (elk ander modern OS doet het ook zo) en vult dit ook dynamisch aan. Benchmarks werken altijd bewust buiten deze geoptimaliseerde filecache om, om betrouwbare metingen te verkrijgen.

Daardoor is het volledig logisch dat benchmarks geen verschil meten, en applicaties, die wel gebruik kunnen maken van dit verbeterd geheugengebruik, er significant op vooruit gaan.
Hoe kunnen die prestaties in godsnaam zo zakken met meer geheugen ter beschikking ????
Hoe kunnen die prestaties in godsnaam zo zakken met meer geheugen ter beschikking
Over het algemeen geldt dat als je meer geheugen hebt, dan moet je ook meer geheugen beheren. Aangezien de snelheid gelijk blijft, betekent 2 keer zo veel geheugen ook 2 keer zo veel beheerstijd.

Normaal merk je daar niet veel van omdat het toch snel genoeg gaat en geoptimaliseerd is. En je wint door het kwijtraken van swap wat vele malen trager is.

Sommige programma's gebruiken echter hun eigen systemen van geheugen-beheer, bijvoorbeeld om met veel data om te kunnen gaat en toch minimaal te swappen. Sommige van deze algoritmes of implementaties zijn afhankelijk van het hoeveelheid geheugen en werken het best bij een bepaalde hoeveelheid geheugen. Meer of minder geheugen heeft dan een negatieve invloed op de prestaties.

Bijvoorbeeld: ze claimen standaard 90% van je geheugen en hun geheugen-beheer-tijd gaat exponentieel met het hoeveelheid geheugen als dit meer is dan 300MB.
Ehhh, exponentieel lijkt me niet hoor. Dan zou je dus met 1 GB een factor 2^8 = 256 langzamer zijn dan met 128 MB (en dat dan nog met het kleinste basisgetal namelijk 2). Zelfs als het kwadratisch toe zou nemen dan heb je nog 8^2 = 64... ga er maar vanuit dat een praktisch geheugenbeheer algoritme lineaire tijd of n*log(n) tijd neemt.
2^n zou betekenen dat computers nooit merkbaar sneller worden, immers is dan de stijging van processorkracht evenredig met de tijd die het geheugenbeheer kost (dubbel zoveel geheugen kost dubbel zoveel tijd).
exponentieel lijkt me niet hoor
Het was maar een dom voorbeeld van een domme implementatie. ;) Zoals ik al aangaf gaat het geheugenbeheer normalitair lineair. Er zijn echter algoritmes die proberen de hoeveelheid geheugen proberen te minimaliseren ten koste van de beheerstijd. Dit om bijvoorbeeld swappen te voorkomen. Deze zijn in den regel niet lineair en zouden zelfs een kwadratische of ergere factor kunnen bevatten. Onder een bepaalde hoeveelheid geheugen spelen andere factoren nog een rol die af kunnen nemen met toename van het hoeveelheid geheugen. Na het optimum kan onze enge factor echter de zaak flink vertragen. Een slimmere implementatie houdt hier rekening mee, maar dat is niet simpel.
Je bedoelt denk ik de resultaten van 3D Studio.
Dat zinnetje is een beetje misleidend, er had moeten staan 'dus stegen de prestaties', of 'dus daalde de doorlooptijd' of zo. De prestaties werden nl. wel degelijk beter.
ik denk dat het hier juist fout gaat ergens in de bench
http://www.tbreak.com/reviews/article.php?cat=cpu&id=350&pagenumber=7
staat dat de prestaties terug uit gaan. bij mij is juist de ervaring dat bij 3d max of a-cad dat meer geheugen altijd positief uitpakt zeker wanneer je renders trekt een systeem met 256mb ram rendert tot wel 4x zo traag en soms bij vray weigert ie zelfs om te renderen wegens een gebrek aan geheugen. ik vind dan deze benches ook wel een beetje onduidelijk omdat er niet precies wordt verteld in welke resolutie men werkt, welke versie en waardoor de prestatie verschillen optreden.
Onder het grafiekje waarnaar je linkt staat
Again, we see a noticable improvment in 3D Studio
Ik geef toe dat als je alleen naar de grafiek kijkt, dat je eerste indruk is dat 1Gb het juist slechter doet. Onduidelijke benches inderdaad.
Tja, wat moet je daar nou opzeggen.
Dat het al lang bekend is bij de gamers?

Vooral bij degenen die mmog spelen? Daar komt het vaak voor dat mensen zelfs 2 versies van het programma tegelijk hebben runnen, dus dan zit je zelfs snel boven de 1gb.
Ook zijn er steeds meer mensen die een spel aan hebben en op de achtergrond andere programma\\\\\\\'s of een 2e spel. Klinkt misschien gek voor sommigen, maar gebeurt best vaak in de praktijk.
Voor de hydra spelers in mmog wereld is 1gb ram standaard.

Maar serieus, wanneer stoppen ze nou is met alleen tests met fps shooters? Die zijn tegenwoordig niet meer de meest eisende programma\\\\\\\'s. Maar ja, mmog is lastig te testen, want dan moet je een abonnement hebben.
voor gamers lijkt het volgens de test net amper te boeien !

ok 256MB is te weinig. dat was al bekend.
maar het verschil tussen 512 en 1024 MB is bijna te verwaarlozen.

het scheelt net 1%

Ik had verwacht dat het meer zou zijn. (heb net 512Mb extra besteld om oa doom3 en halfLife beter te kunnen spelen)
Hou er wel rekening mee dat dit gemiddelde framerates zijn! Dus in de 'makkelijke' stukken van het spel is 512MB inderdaad ruim voldoende, en zal 1GB niets uitmaken. Het zijn juist de 'moeilijke' stukken (veel tegenstanders, textures, etc...) waar die 1GB meer dan die 1% verbetering zal boeken.

Ik heb geen 1GB, maar ik denk dat waar je met 512 zo nu en dan je framerates merkbaar zal zien zakken, zakken de framerates bij 1GB véél minder. Dat dat gemiddeld in 1% verbetering resulteert, doet waarschijnlijk weinig recht aan de merkbare verbetering.
Dat zal nog wel meevallen. Al die textures moeten immers in de videokaart verwerkt worden. En daar is 512MB en 1GB niet bepaald de standaard. De videokaart is de limiterende factor wat betreft de hoeveelheid textures die gebruikt worden.

Als je textures niet meer in je videokaart passen, DAN keldert de prestatie inderdaad ineen.
Is het niet zo dat extra geheugen alleen voor snelheids verbetring zorgt als het geheugen ook gebruikt word.

Oftwel, als je op je PC bijv. 200 mb in gebruik hebt (zie taskmanager) en je hebt er 256 mb in zitten wat je upgrade naar 512 dan is het toch logisch dat je geen snelheids verbetering hebt.

Een game wat veel geheugen nodig heeft zal wel een prestatie verbetering laten zien (hoeft niet te swappen). Beetje raar om dit te benschmarken, ook zonder benchark is de uitkomst vrij eenvoudig te beredeneren.

Edit: typo's
Niet direct, Windows gebruikt een bepaalde hoeveelheid geheugen naargelang het beschikbare geheugen. Indien je dus van 256 naar 512 upgrade zal windows bijvoorbeeld na de upgrade een 260MB gebruiken. Het is al langer geweten dat teveel geheugen ook niet goed is maar zoals de benchmarken uitwijzen verschilt dat per programma en kan je er dus eigenlijk niet echt op letten bij aankoop van een pc. Tenzij je je pc voor 1 of 2 programma's zou gebruiken natuurlijk.

Toch vindt ik het raar dat 3D studio max met 1GB minder goedp resteert dan met 256MB...
Toch vindt ik het raar dat 3D studio max met 1GB minder goedp resteert dan met 256MB...
dat ligt waarschijnlijk aan windows en niet aan 3d studio. Windows legt namelijk een swap file aan ter groote van 1.5 keer het physieke geheugen. 3d studio zal die waarschijnlijk dan ook gaan gebruiken als beschikbaar geheugen. dus windows gaat nu ipv 256 + 384mb wel 1gb + 1.5gb aan geheugen beheren en dus voor 1.5gb aan swap, en swap is gewoon traag.
Dat zou niets hoeven uitmaken. Het feit dat er meer swap ruimte beschikbaar is heeft vrijwel niets met de snelheid ervan te maken. Bij overschreiding van die hoeveelheid zou je juist pas snelheidsverschillen moeten gaan zien, eigenlijk in voordeel van de grotere ruimte. Dit omdat voor de kleinere ruimte er dan compressie optreedt, wat iets meer tijd in zou moeten nemen.

Verder vind ik het ook vreemd. Ik heb juist altijd gehoord dat meer geheugen juist erg van belang is binnen 3d en andere grafische pakketen.
Als het goed is weet 3D studio helemaal niet hoe groot de swapfile van windows is.
Het krijgt van windows 2GB virtueel geheugen en het moet zich verder niet bemoeien met hoe windows dat beheert.
@Michali

Dit ligt er maar net aan wat je binnen dat 3D of grafische pakket aan het doen bent.
Zodra je met hoge resoluties textures en shadows maps bezig gaat, dan schiet je geheugen gebruik omhoog. (Ben daardoor thuis al een keer tegen de 2GB limiet aangelopen met een 3D pakket)

Maar als je met 3D vector tekeningen bezig bent, dan zal het geheugengebruik minimaal zijn.
Het krijgt van windows 2GB virtueel geheugen en het moet zich verder niet bemoeien met hoe windows dat beheert.
Zo simpel is het ook weer niet. Als er te weinig RAM is, kan een app beter zelf data weggooien en het desnoods later weer laden dan wachten totdat Windows die data uitpaged.
Zo simpel is het wel.
Maar jij begint ineens over iets anders te praten. RAM is wat anders dan virtueel geheugen.

We hadden het over een applicatie die kijkt naar de grootte van de swapfile (oftewel de hoeveelheid virtueel geheugen)

Uiteraard is het verstandig als een applicatie kijkt hoeveel RAM er is, om te zorgen dat er niet geswapt wordt. Maar dat heeft niets met de grootte van de swapfile of de hoeveelheid virtueel geheugen te maken.
Miniem in dat geval.

Wat wel gebeurd met meer geheugen, is dat er meer harde schijf cache gebruikt zal worden (tijdelijk in geheugen op slaan van veel gebruikte dingen op je schijf). Dit zal het starten van applicaties en bestand toegang licht verbeteren.
Bij het starten van een applicatie helpt cache je niet. De applicatie staat immers nog niet in de cache.

Cache helpt je alleen als je een bestand dat je kort tevoren open hebt gehad opnieuw opent.

Dus een applicatie opnieuw starten kan veel sneller gaan.
Ja,
Dit komt simpelgezegd doordat Windows het geheugen beheerd, en dus geheugen zal vrijmaken wanneer het tekort begint te komen. Wanneer het dus nooit tekort komt, zal Windows alles in het geheugen laten, wat dus soms wel beduidend sneller doorwerkt.

(correct me if I'm wrong, of vul het aan waar nodig?)
Dat verhaal klopt niet helemaal omdat dan veel dingen in de swapfile gaan. Heb zelf 1GB aan ram en merk t wel, maar ik heb ook vaak vanalles en nog wat openstaan zoals browser, messenger, mirc en niet te vergeten de firewall en virusscanner, want dat zijn enorme resourcevreters.
En dan niet te vergeten spelletjes, die krijgen steeds meer honger naar geheugen en dan is 1GB echt geen luxe.
...en dan is 1GB echt geen luxe.
laten we het maar op geen overbodige luxe houden :Y)
En wat is daar dan handig aan? Het heeft namelijk geen enkel praktisch nut, anders dan dat je wat harddisk ruimte uitspaart.

En dat is nou niet bepaald zo'n geweldige reden.

Windows (en andere OS-en) gaan veel verstandiger met swapfiles om dan mensen denken.
ik vind alleen het idee van Swap = 2*RAM beetje achterhaald voor >=512MB .. 256MB swap is meestal toch wel voldoende.
Het is nu niet meer of minder achterhaald dan een aantal jaren geleden.

Het probleem is gewoon dat het OS niet kan bepalen wat de beste waarde is. Dat moet je zelf doen.

Het enige waar je voor het installatie programma voor het OS vanuit zou kunnen gaan, is dat iemand een zinvolle hoeveelheid ram in zijn machine zet.

Als iemand heel veel ram heeft, dan zal ie dat wel doen omdat ie applicaties heeft die heel veel ram gebruiken. En dan is het ook logisch dat je een grotere swapfile gebruikt voor het geval die applicaties eens wat meer gebruiken dan je gedacht had. In die zin is het dus logisch om de swapfile een bepaald percentage van je geheugen te maken.

Die redenatie is door de jaren heen dezelfde gebleven. (overigens gebruikt windows volgens mij 1,5 * Ram)

Alleen zie je nu dat ram zo goedkoop is geworden dat mensen idiote hoeveelheden ram in hun machine stoppen. Mensen die nooit boven de 512MB uit zullen komen, die 1GB ram hebben.
Tja, dan kun je rustig 12MB als swapfile instellen.
ben ik het nou helemaal mee eens B-)
Ik vind het onderwerp geheugen in windows xp sowieso vaag. Want kloppen de geheugen toewijzigingen in taskmanager wel? Ik gebruik regelmatig adobe illustrator, photoshop en indesign tegelijkertijd (in het geheugen dan). Toen ik nog 512MB had was mijn harddisk flink bezig met ratelen, en na de upgrade naar 1GB wil ie nog steeds veel swappen. Windows is dan ook wel een virtual memory OS, maar snap soms niet waarom er _altijd_ geheugen weggeswapped wordt ook al heb je 4GB aan geheugen in je pc zitten bij wijze van spreken.
Bij 3d rendering is de optimalisatie heel anders. De render engines worden zo klein mogelijk gehouden zodat die in de processor cache past waardoor het renderen veel sneller gaat. Dus als je meer geheugen hebt wordt daar niet of nauwelijks gebruik van gemaakt, hooguit om grote texture maps te cachen. Dus deze test gaat eerder over hoe Windows met geheugen omgaat bij verschillende apps. Hoe microsoft dat geimplementeerd heeft wat de verdeelsleutel is voor geheugen/swapfile en bij welk geheugen gebruik die weer anders is etc weet ik niet.
bij grote hoeveelheden RAM-geheugen raadt zelfs Mirosoft aan om aan het tweakern te gaan om het maximale uit je systeem te halen. Windows (XP) is als desktopbesturingssysteem opgebouwd en houdt omwile van allerlei redenen een hoop geheugen op "reserve". Als je echt veel ehugen hebt (>1GB) wordt dei reserve soms wat overdreven, en heb je eigenlijk liever dat Je RAM efficiënter benut wordt...
Ik raad je aan een op 't forum te zoeken; er zijn immers een hoop interessante dingen te vinden over het windows geheuen beheer :)
Je zou eens moeten kijken naar de Virtual Memory toewijzing in taskmanager. Dat geeft een heel ander beeld...
...voor zover de test 'meer is beter?' Maar nu de vraag wat sneller is: 512MB snel geheugen of 1024mB valueram? Aangezien dit vaak evenveel kost (zo'n ¤140)

Helemaal als je een Athlon 64 gaat overklokken. Dan gaan de prestaties in zijn geheel omhoog als je CPU en mem opschroeft. Alleen hoe ver kom je met valueram en hoe ver kom je met Winbond BH5 of Samsung tccd chipjes. En weegt de winst van 1GB op tegen het verlies in CPU snelheid. Zeker als je in je achterhoofd houdt dat een pc nog een paar jaar meemoet en de benodigde hoeveelheid geheugen alleen maar toe zal nemen.
Het is heel simpel, over het algemeen als je je een beetje verdiept in de applicaties en games die jijzelf draait, kan je wel ontdekken hoeveel geheugen dit inneemt, als je dus zoals ik (veel photoshop, 3d studio en max resoluties en details in spellen) Heb je veel baat bij MEGA veel intern geheugen. Hoewel ik spellen tot nu toe nog nooit meer dan 1024mb heb zien vreten willen dergelijke apps als photoshop en 3ds wel zeer ver gaan met het geheugengebruik... Ik zou veel baat hebben bij 4gig intern. En dan maken snelle of trage geheugentimings nauwelijks nog echt uit. Ik ben als echte tweaker helemaal niet zo weg van supergetimed geheugen, ik vind dat nutteloos (mwhaha, das niet halemaal waar overigens)
We weten allemaal wel dat het verschil met "te kort aan geheugen" en "genoeg geheugen" ongeveer 100% verschil in snelheid maakt waarbij het eerste niet alleen trager is, maar ook zeer irritant. En "snel getimed geheugen" tegenover "traag getimed geheugen" verschilt hoogstens enkele procenten, niet echt schokkende verschillen.

Ik kan een goed voorbeeld van mezelf geven, ik heb momenteel duidelijk tekort aan mijn 512mb geheugenreep. Dit is ook nog eens een traag getimede 3-3-3-11 reep @ 440Mhz op NForce2 met Sempron @ 10x220MHz (2200MHz). Niet eens dual-channel kun je nagaan...
Ik heb er duidelijk geen zak aan om deze reep te vervangen door een 512MB exemplaar die timings van 2-2-2-11 zou kunnen. Dan kan ik veel beter twee goedkope 512mb's halen of 2x1024, dan ben ik namelijk van het geswap af, en dat maakt een wereld van verschil!
Die extra timing-performance is voor de echte die-hards met te veel geld :)
Maar ik kan niet ontkennen dat ik me daar jarenlang zelf ook blind op heb gestaard, op die timings, maar ik ben gelukkig ook weer wat bedachtzamer geworden :P
Daar ben ik het helemaal met je eens. 'Been there, done that'. Timings boeien idd niet zo.

Maar wat als je een leuke Winchester A64 van 1800 MHz kunt overklokken tot 2,6-2,7 GHz en deze overklok afhankelijk is van je geheugen? Je kunt namelijk de multiplier niet omhoog doen om te overklokken.

En ik heb gemerkt dat van je mem flink overklokken, ook al hou je de kloksnelheid van de cpu gelijk, je systeem wel aardig wat soepeler loopt. En dan je cpu voltage flink knijpen: lekker zuinig en stil en dan toch sneller dan standaard (stabiel uiteraard).

En merkgeheugen is helemaal een must. Vroeger vaak steeds vastlopers gehad met dat goedkope noname geheugen.
conculsie:
512 is over het algemeen nog wel genoeg.
jammer dat ze niet verschillende soorten hebben geprobeerd.

helaas heb ik niet de conclusie van het artikel kunnen lezen want ik krijg deze error :

Miraserver Error: There has been an invalid database query. MySQL said:
Can't connect to MySQL server on 'localhost' (10048)

gelukkig ligt het niet aan het geheugen maar aan de programeur :)

@countess

volgens de test maakt het zonder de mod weinig uit.

UT2004
Product Score
Graph
Difference
1GB 96.39 +4%
512MB 96.35 +4%
256MB 93.02 0%
tja, wat ze dus niet hebben getest is zoals countess al aangeeft, de laadt tijd.. bv bij Battlefield 1942 van 256 naar 786 werd bij mij de laadtijd gehalveert.. dus het scheelt wel degelijk veel..
hangt er van af.
ik heb nu 512mb maar red ochestra (UT2k4 mod) laad erg langzaam en hakkeld in het begin van een nieuwe map echt vreselijk, daarnaa is alles prima.
maar iedereen met 1GB heeft daar dus geen last van en de laad tijden zijn ook een stuk korter. (verdere specs zijn vergelijkbaar)

edit @ edit van eenmadcat:
ik zeg toch ook dat het verder prima is
ik had het over de laad tijden van de game niet om de in-game framerates, want die is gewoon prima.

het is dus niet zo dat 1GB nuttenloos is. scheeld namelijk een hoop geswap, slijt je HD ook minder.

overbodig? ik geef alleen aan dat wat ze hier getest hebben niet het hele verhaal verteld.
Ik lees op mijn pc nu met alleen firefox open en winamp etc, de normale stuff is 213mb bij mij.
Vandaag lag mijn piek op 581mb (bij het spelen van WoW).
Ofwel voor (nieuwe) spellen is een gig geheugen geen overbodige luxe, ik heb op het moment 768mb dus ik zit net goed :)
@ Sharky
Als je al meer kan inladen van te voren en dus niet later erbij hoeft te halen heeft dat een prestatie verbetering.
Simpel gezegt hoe meer een spel aan objecten die hij in het geheugen moet/wil stoppen zal beter presteren met meer geheugen.
Doom3 wil zo te zien veel "pre-loaden", wat samenhangt met de grote prestatie stijging
(wat ook verklaart waarom het ook zo gigantisch lang duurt om een level te laden :r )
Na het opstarten is het geheugengebruik bij mij 22 MB, met firewall, printerserver, ftp server, netwerk, internet, en login scherm draaiend. Na inloggen en alle standaard programma's (agenda, MSN, file browser, etc) geladen: 70 MB. Met ook nog eens Firefox, een GIMP sessie en wat videobewerking spul eroverheen: 130 MB.

Aan die 256 MB heeft mn Linux bakkie voorlopig meer dan zat...

:+

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