GUIDE: Dette er RAM (Ekstra)

[sore]

RAM er en nødvendig komponent i en hver PC, men vet du egentlig hvorfor?

GUIDE: Dette er RAM (Ekstra)

[Psykonaut]

Er ikke RAM-disker utsatt for korrupsjon? Spesiellt om man bruker slike vanlige brikker uten feilkorreksjon (ECC).

[96abrevs]

Er ikke RAM-disker utsatt for korrupsjon? Spesiellt om man bruker slike vanlige brikker uten feilkorreksjon (ECC).

 

Nå er jeg overhode ingen ekspert på data, så du får ha meg unnskyldt om spørsmålet mitt lyder dumt. Hva mener du med korrupsjon her ...?

[kwrl]

Nå har jeg ikke lest artikkelen, pga jeg ikke er ekstra-kunde, men teksten "Takket være disse brikkene er maskinen din lynrask" gir vel et noe feilaktig inntrykk av ting.

 

Det skal selvsagt sies at RAM yter milevis bedre enn SSDer osv, så for all del, maskinen hadde vært tregere uten. Men det skal sies at en av de store utfordringene innen hardware er at ytelsen til RAM ikke utvikler seg like fort som f.eks ytelsen til CPUer, mer presist så sliter man med å senke aksesstidene til RAM. For de som vil sjekke det ut så kalles problemstillingen "the memory gap". Det er veldig mye av utviklingen av nye prosessorer som går med til å kompensere for relativt høy aksesstid til RAM.

[almeli]

 

Nå er jeg overhode ingen ekspert på data, så du får ha meg unnskyldt om spørsmålet mitt lyder dumt. Hva mener du med korrupsjon her ...?

http://en.wikipedia.org/wiki/Data_corruption

[96abrevs]

Nå er jeg overhode ingen ekspert på data, så du får ha meg unnskyldt om spørsmålet mitt lyder dumt. Hva mener du med korrupsjon her ...?

http://en.wikipedia.org/wiki/Data_corruption

 

Se det. Man lærer noe nytt hver dag. Jeg har alltid forbundet ordet korrupsjon med bestikkelser o.l.

 

Ellers kunne jeg jo brukt innsiden av huet og googlet det selv

[efikkan]

Størrelsen og farten til primærminnet gjør at det egner seg ypperlig til midlertidig lagringsplass for kritiske deler av operativsystemet, kjørende programmer og filer som er i bruk. Når du starter et operativsystem eller et program, blir hele eller deler av programmet lastet inn i primærminnet for kjapp tilgang. All informasjon som endres går via cachene til prosessoren, og informasjon som endres hyppig blir liggende der over tid. Når du lukker programmet eller slår av datamaskinen blir informasjonen skrevet tilbake til sekundærminnet, da all informasjon i primærminnet går tapt når strømmen forsvinner.

Ganske upresist og dere blander flere kort her.

 

Svært mange misforstår hva lagringspyramiden representerer. Den viser ikke et samlet adresseringsområde, men ulike fysiske minnetyper. I PCer har CPUen ett område som er direkte adresserbart. Dette består for det meste av RAM, pluss noe BIOS-kode, CPU-firmware, og BIOS-IO(øverst i adresseringsrom). RAM-delen her kan da består av alt fra cache til fysisk RAM og eventuell swap på disk, så den adresserbare "RAMen" er abstrahert og spredt over disse stegene i pyramiden*. Men bruk av CPU-registre holdes separat, og generell bruk av disker og SSDer kan ikke adresseres på denne måten. For aksess til lagring må CPUen sende forespørsler til kontrolleren, i motsetning til direkte adresseoppslag som gjøres i RAM.

 

Dermed blir det feil å tenke på alle lagringsformene som én sammehengende pyramide. Jeg husker selv at en av lærebøkene på NTNU forklarte at ting ble lagret i pyramiden av viktighet, hvor de viktigste dataene ble lagret i registre og cache. Det er helt feil. Data befinner seg kun i registre under operasjoner i CPUen, og befinner seg ellers i RAM/cache/(swap). Data må eksplisitt leses/skrives for at det skal overføres mellom minne og lagringsmedier.

 

* Swap-delen av "minnet" aksesseres ikke direkte av CPUen, men er implementert i operativsystemets kjerne.

 

Mye av årsaken til forvirring skyldes nok at swap blir brukt som utvidet minne, og at deler av minne brukes som cache for lagringsenheter. I dagens operativsystemer har vi altså to "pyramider", det ene over "RAM" og det andre over "lagring". Selv om disse kan overlappe i fysisk forstand så behandles alltid disse logisk som isolerte enheter. Det er aldri slik at maskinen skriver RAM tilbake til disk ved lukking av programmer eller maskinen, det er en misforståelse.

 

Caching av disker og SSD i RAM er noe vi alle har og nyter godt av. I Windows brukes gjerne en bestemt andel av RAM til cache, mens Linux typisk bruker alt som er tilgjengelig til enhver tid. Denne cachen gjør at de data som nylig ble brukt ligger klart i RAM og blir lastet lynraskt. Det betyr også at maskiner med mer RAM får bedre utnyttelse av denne cachen. De fleste benchmark-programmer som tester f.eks. ren SSD-ytelse er designet så de unngår operativsystemets innebygde caching-funksjoner. Dermed kan tester ofte gi et feil inntrykk av hvor stor ytelsesforskjell ulik maskinvare vil ha i praktisk bruk. De brukerne som bruker maskinene sine til jobbing og som kjører de sammenhengene over lengre tid vil ha nytte av så mye RAM som de kan ta seg råd til. Da vil som regel programmer og mye av filene ligge klart i RAM og være ekstremt mye raskere enn noen SSD. Da betyr det lite om den ene SSDen er 20MB/s raskere enn den andre. Dermed kan noen ganger mer RAM være en bedre investering enn en dyrere SSD. Begrensningen til denne cachen er hvorvidt de samme filene lastes flere ganger. Men det er alltid et godt råd å ha en del mer RAM enn du trenger til programmene som skal kjøre.

 

Nå har jeg ikke lest artikkelen, pga jeg ikke er ekstra-kunde, men teksten "Takket være disse brikkene er maskinen din lynrask" gir vel et noe feilaktig inntrykk av ting.

 

Det skal selvsagt sies at RAM yter milevis bedre enn SSDer osv, så for all del, maskinen hadde vært tregere uten. Men det skal sies at en av de store utfordringene innen hardware er at ytelsen til RAM ikke utvikler seg like fort som f.eks ytelsen til CPUer, mer presist så sliter man med å senke aksesstidene til RAM. For de som vil sjekke det ut så kalles problemstillingen "the memory gap". Det er veldig mye av utviklingen av nye prosessorer som går med til å kompensere for relativt høy aksesstid til RAM.

Viktigheten av tilgangstid på RAM er veldig bruksavhengig. F.eks. skjermkort velger å prioritere minne med ennå høyere båndbredde og lenger aksesstid. I CPUer er problematikken med aksesstid stort sett løst med cache og gode algoritmer for prefetching.

[kwrl]

Prefetching løser ikke problemet, det dekker over det. Selvsagt er dagens prefetchingalgoritmer gode og gir både relativt god accuracy og coverage, men å si at problematikken rundt memory gap er løst blir vel å dra ting litt langt. Hvis man laget datamaskiner uten å tenke på strømforbruk og varmeutvikling så kunne jeg vært enig i at det løste problemet. Prefetching benytter den økte båndbredden tilgjengelig for å hente data som kanskje er nyttige, altså har man mye data som går over bussen uten at det nødvendigvis er de riktige dataene. Det er da altså en del energi som brukes på det som i realiteten bare er cache pollution.

 

Det skal vel også nevnes at cache mer eller mindre utelukkende eksisterer for å kompensere for aksesstiden til RAM. Alt som er på en CPU tar plassen til noe annet, sånn er det bare. Så hvis det ikke var for at vi trengte relativt mye areal som brukes på (som regel) tre nivåer med cache, så kunne vi brukt det arealet til noe annet. Ledig areal => Pollack's rule => mer ytelse.

 

Nå skal jeg innrømme at jeg vet relativt lite om GPUer men det er vel tenkelig at flyten av data er enklere å predikere og at derfor prefetching gjør det bedre i den sammenheng enn på CPUer. Dermed vil det gi mening å prioritere båndbredde og prefetching over aksesstid.

 

Så joda, vi har måter å kompensere for det, men det er så absolutt en stor utfordring fremdeles.

[efikkan]

Det finnes en rekke "regler" for hvordan CPU-ytelse skal skalere i forhold til transistortall, og det alle disse reglene har til felles er at de alle er 100% oksemøkk. Slike teorier er utviklet at folk som ikke forstår at det er arkitekturene som gir bedre ytelse. Enhver som har følgt med på CPU-ytelsen det siste tiåret vil se at slike teorier er verdiløse. I den senere tid har faktisk AMD klart å gi dårligere ytelse med flere transistorer... Det er tullete å antyde at CPUene kunne automatisk hatt bedre ytelse med å bruke cache-arealet til mer komplekse kjerner, CPUene er så komplekse som de har klart å lage de til nå.

 

Grunnen til at vi har støtt på en vegg i minneresponstid er enkelt og greit den fysiske distansen på lederne og forsinkelser pga. kapasitans i kretsene. Dette er problemer som ikke uten videre kan løses med flere transistorer. Bare arealet for en enkelt CPU-kjerne er stort nok til at forsinkelser blir et problem. Det er enkelt å tenke at vi kan korte ned avstander ved å legge kretser i flere lag, men dette gir igjen høyere varmeutvikling og produksjonstid.

[kwrl]

Pollack's rule snakker selvfølgelig om en generell tendens, det at det finnes unntak er ikke ekstremt overraskende. Tror forøvrig Fred Pollack, i likhet med andre med noen tiår i Intel har litt peiling på arkitekturer.

 

Du bruker forøvrig ordet "arkitektur" som om det var noe magisk som ikke ble påvirket av fysiske begrensninger. Hvis man skal lage en bedre arkitektur så må man veldig ofte legge til noe. Det sier seg selv at hvis man skal legge til noe og ikke har mer plass, så er det noe som må ut eller krympes.

 

OoOE fungerer dårlig uten et re-order buffer, superscalare prosessorer gjør det ikke særlig bra uten logikk for å identifisere ledige funksjonelle enheter, prosessorer med flere kjerner gjør det dårlig uten logikk for cache coherence, og listen går videre. De virkelig store fremskrittene gjort på arkitekturnivå i CISC-maskiner har stort sett lagt til ny logikk, altså mer som trenger areal.

 

Jeg har forøvrig heller ikke påstått noe om årsaken til at utviklingen av aksesstiden har vært dårlig, jeg har bare konstatert at den er det.