Skrivet av Accipiter46:
Om spelet inte använder allt RAM som finns kommer inte mer att göra någon märkbar skillnad.
Visst skulle man kunna tänka sig ett spel som fyllde RAM med texturer för att snabba upp laddningstider, men vad jag vet finns inte det. Paketet hade dock en ssd vilket gör stor skillnad i detta sammanhang.
Spel behöver inte göra det aktivt om dem inte vill för Windows, och nästan alla andra operativ system, gör det självmant på alla filer. Så ett sådant system finns definitivt i verk. Fördelen däremot om spel själva gör det är om de kör arkiverade/komprimerade filer och kan då lagra dem uppackade på RAM minnet medans windows endast lagrar fil datan. Man märker enorm skillnad mellan cache och icke cache lagrad data på HDDs och viss skillnad även på SSD. Läs mitt test nedan för att få reda på hur mycket man kan teoretiskt tjäna.
Skrivet av Tomika:
@philipborg:
Kortare laddningstider? Spelet allokerar förmodligen minnet så pass snabbt ändå trotts i kombination med SSD som finns i hans kundkorg så kommer 16GB ram VS 8GB ram göra en skillnad på någon bråkdels sekund.
Helt meningslöst är det inte med cachad data. Slängde ihop en snabb test applikation där jag kunde jämföra med och utan windows automatiska cache funktion, här är min rapport. (Gjorde inte detta för att motbevisa enbart, jag har länge undrat hur effektivt det faktiskt är så passade på att testa.)
Windows Cache Test
Test rigg:
Testprogrammets design:
Jag börjar med att skriva en 4GB (ej 4GiB) stor fil med slumpartad data på min SSD. Jag tömmer sedan windows cache, även känt som standby minne. När det är gjort så läser jag filen sekventiellt, alltså från början till slut. Efter det så körs ytterligare tio identiska läsningar utav samma fil utan att ha någon cache på applikations nivå utöver vanliga stream buffrar. Detta tillåter mig att mäta hur effektiv windows cache är i jämförelse med en modern SSD.
Resultat:
Första laddningen tog 11231ms medans dem resterande tio låg runt 1070ms. Dem resterande tio laddade alltså cirka 10.5 gånger så snabbt.
Rå test data:
Märkte nu att jag namngivit dem lite tokigt. Första körningen är SSD och 1-10 med tillåtelse utav Windows Cache.
Initial run took ~11s or 11231ms
Test 1 out of 10.
Run 1 took ~1s or exactly 1077ms.
Run 1 was 10.43 times as fast as the initial run.
Test 2 out of 10.
Run 2 took ~1s or exactly 1055ms.
Run 2 was 10.65 times as fast as the initial run.
Test 3 out of 10.
Run 3 took ~1s or exactly 1066ms.
Run 3 was 10.54 times as fast as the initial run.
Test 4 out of 10.
Run 4 took ~1s or exactly 1099ms.
Run 4 was 10.22 times as fast as the initial run.
Test 5 out of 10.
Run 5 took ~1s or exactly 1084ms.
Run 5 was 10.36 times as fast as the initial run.
Test 6 out of 10.
Run 6 took ~1s or exactly 1090ms.
Run 6 was 10.3 times as fast as the initial run.
Test 7 out of 10.
Run 7 took ~1s or exactly 1056ms.
Run 7 was 10.64 times as fast as the initial run.
Test 8 out of 10.
Run 8 took ~1s or exactly 1068ms.
Run 8 was 10.52 times as fast as the initial run.
Test 9 out of 10.
Run 9 took ~1s or exactly 1068ms.
Run 9 was 10.52 times as fast as the initial run.
Test 10 out of 10.
Run 10 took ~1s or exactly 1080ms.
Run 10 was 10.4 times as fast as the initial run.
Dold text
Slutsats och diskussion:
Utav detta kan jag definitivt konstatera att även på en modern SSD så är vinsterna stora med standby RAM för cache. Det är även värt att nämna att under första körningen så belastades SSD'n till 100% vilket tyder på att testet inte har några större flaskhalsar i sig.
Värt att tänka på däremot är att när många program laddar så gör dem mer med filerna än att bara ladda in dem i minnet vilket möjligen skulle kunna hindra en sådana här gynnsamma resultat. Alla program som laddar data hade däremot sett skillnad. När det kommer till spel är variationen troligast väldigt stor.
Detta testet var sekventiellt, ett verkligt scenario hade sett en mer varierande last. IOPS intensiva laddningar hade nog sätt ännu större nytta på Windows Cache då de är designade för låga latenser och verkligen inte sekventiella laddningar. Sedan vet jag inte hur effektiv Windows Cache är med IOPS och om den möjligen skulle kunna hålla tillbaka resultaten lite. Den hade däremot fortfarande varit överlägsen en SSD. Värt att notera även är att den SSD'n som rekommenderades är väldigt mycket sämre än t.ex. 840 evo i IOPS intensiva situationer och hade sett en väldigt stor vinst där med cache.
Kör man HDD så är vinsterna enorma med detta, som natt och dag. Troligen hade TS fått skaffa en (extern) HDD i framtiden då 120GB kommer man inte långt med. Nu har han däremot inte specificerat vad han ska spela (såvitt jag har läst) så går inte att säga något med säkerhet.
Windows är däremot lite mer avancerat än hur jag tvingade den att agera i detta testet. Kör man på en HDD, gäller ej SSD, så kommer windows ladda filerna innan man ens har påbörjat processen att ladda dem. Windows analyserar dina och dina programs fil vanor och försöker optimera vilka filer som är inladdade. Ser den att du startar program X som behöver filer Y och Z, så kommer den försöka ladda Y och Z innan program X har efterfrågat dem. Denna funktionen SuperFetch om ni vill läsa mer om den.
I dem flesta situationer så kommer hastigheten i den första körningen troligen vara rätt kass ändå, men andra körningen så ser man stora vinster. Detta gör att ett spel t.ex. kommer starta rätt segt, men bytet/omladdning utav en bana kommer gå väldigt mycket snabbare. Det behöver inte heller vara samma område då dem flesta spel delar assets mellan flera banor, speciellt karaktärer och dylik.
Möjliga felkällor:
Jag orkade inte stänga av windows skriv cache men jag väntade så länge jag orkade på att den skulle tömma sig efter jag skrev 4GB data filen. Denna felfaktorn skulle möjligen kunna gynna referenstestet, alltså det första testet då den möjligen skulle kunna utnyttja cache till viss del ändå även om målet är att testa utan cache. Programmet jag använder för att tömma cache tömmer inte skriv cachen som jag är rätt säker kan för användas cachad laddning.
Hade uppe väldigt många program under testet och körde inte heller datorn under felsäkert läge.
Helt singel trådat vilket troligen hämmade RAM minnena mest, speciellt då dem är quad channel. Dem flesta programs laddnings kod är däremot singel trådade vilket gör detta i dem flesta situationer mer realistiskt men visar att det finns definitivt mer kraft att hämta ur RAM cache.
Använder Java och inte något snabbare så som C/C++ i detta test, den som hade tjänat på det hade varit RAM minnena.
SSD disken används som OS disk, vilket däremot är situationen för dem flesta, så det är verkligen realistiskt.
Slutord
Jag skrev detta programmet själv så det finns en risk att jag har gjort något tokigt, men såvitt jag kan se så ser allting bra ut. Det hade även varit intressant att göra ett IOPS intensivt test, men här får man iaf en insikt hur mycket "tomt" RAM kan hjälpa en snabba upp fil laddningar.
Har ni några frågor/åsikter om utförandet eller mitt resultat så får ni gärna fråga. Kanske borde gjort detta till en egen tråd för att inte vara för off topic för ts. men isf gör jag det då. Kanske kan göra en IOPS intensiv version av programmet då även, samt en GUI. Hoppas det iaf var lite intressant läsning.
Är väldigt trött i skrivande stund, så förvänta er många stavfel.
Extra, HDD test
Kom på efter jag skrivit detta att jag lika gärna kunde göra samma test på en HDD. HDD'n i fråga är en Hitachi HDS723020BLA642 som snurrar i 7200RPM med 2TB lagring. Disken är inte tom vilket egentligen är lämpligt iom en disks fysiska utformning men fortfarande intressant. Disken är halft fylld, så inte innersta lagret på disken iaf. En halvfylld disk kan däremot anses mer realistisk.
Gör detta kort, fil laddning 1-10 var ungefär 80 gånger så snabb. HDD's starkaste sida är till och med sekventiell läsning, tänk om detta hade varit IOPS intensivt.
Här är utdatan för HDD:
Initial run took ~87s or 86734ms
Test 1 out of 10.
Run 1 took ~1s or exactly 1094ms.
Run 1 was 79.28 times as fast as the initial run.
Test 2 out of 10.
Run 2 took ~1s or exactly 1122ms.
Run 2 was 77.3 times as fast as the initial run.
Test 3 out of 10.
Run 3 took ~1s or exactly 1102ms.
Run 3 was 78.71 times as fast as the initial run.
Test 4 out of 10.
Run 4 took ~1s or exactly 1101ms.
Run 4 was 78.78 times as fast as the initial run.
Test 5 out of 10.
Run 5 took ~1s or exactly 1105ms.
Run 5 was 78.49 times as fast as the initial run.
Test 6 out of 10.
Run 6 took ~1s or exactly 1143ms.
Run 6 was 75.88 times as fast as the initial run.
Test 7 out of 10.
Run 7 took ~1s or exactly 1159ms.
Run 7 was 74.84 times as fast as the initial run.
Test 8 out of 10.
Run 8 took ~1s or exactly 1137ms.
Run 8 was 76.28 times as fast as the initial run.
Test 9 out of 10.
Run 9 took ~1s or exactly 1091ms.
Run 9 was 79.5 times as fast as the initial run.
Test 10 out of 10.
Run 10 took ~1s or exactly 1092ms.
Run 10 was 79.43 times as fast as the initial run.
Dold text
EDIT: OBS, säger inte att TS ska ha 16GB, säger bara att det inte är meningslöst och det finns vinster för laddningstider, även om dem varierar i grad beroende på programmet.
