mboost-dp1
unknown
Nu er jeg ikke så kendt på hardware delen, hvor står betydning har cache på processoreren? og hvor stor forskel gør det hvis den er 3 gange så stor?
#3 Jo mere cachen kan "huske" desto mindre skal den hente oplysninger andre steder fra.
Det svarer lidt til den almindelige ram du har i maskinen, hvor computeren bliver betydeligt langsommere hvis alt ram er opbrugt og den er nødt til at swappe ned i virtuel ram på din harddisk som jo er meget langsommere end ram'en.
Det svarer lidt til den almindelige ram du har i maskinen, hvor computeren bliver betydeligt langsommere hvis alt ram er opbrugt og den er nødt til at swappe ned i virtuel ram på din harddisk som jo er meget langsommere end ram'en.
#3
Det er en oversigt over det mest brugte data der hentes fra hukommelsen (og indirekte fra harddisken), som derved kan hentes hurtigt. Det gør i rigtigt mange tilfælde dine beregninger 300-400% hurtigere, da det sikrer at cpu'en ikke så ofte skal vente på data fra hukommelsen.
Som hastigheden af cpu'er er idag, bevæger et signal sig ca. 1 cm på sin signalvej per. clockfrekvens, derfor er det nødvendig med et nærlager, og desto højere frekvens, desto vigtigere er størrelsen.
Det er en oversigt over det mest brugte data der hentes fra hukommelsen (og indirekte fra harddisken), som derved kan hentes hurtigt. Det gør i rigtigt mange tilfælde dine beregninger 300-400% hurtigere, da det sikrer at cpu'en ikke så ofte skal vente på data fra hukommelsen.
Som hastigheden af cpu'er er idag, bevæger et signal sig ca. 1 cm på sin signalvej per. clockfrekvens, derfor er det nødvendig med et nærlager, og desto højere frekvens, desto vigtigere er størrelsen.
Hvis cachen bliver stor, så tager den også længere tid at søge i. Jeg mindes at have set benchmarks, hvor en meget lille stump kode blev langsommere af at køre på en cpu med mere cache. Kan dog ikke huske hvor.
#2 Ja, det hjalp jo gevaldigt da man lagde maskinen på en PC-arkitektur... :)
#4 ja, det er bare ikke helt ligeså enkelt som vores almindelig hukommelseslager.
Det der ligger i memory, er de programmer der er aktive. Der er så nogen af programmerne der cacher - altså læser mere op, end der er brug for, så når det skal bruges, så kan man læse det direkte fra RAM, istedet for at bruge den langsomme harddisk.
I princippet er det det samme med cache. Man ligger så meget i cache sommuligt, så når CPU'en skal bruge instruktioner, skal den ikke hente dem fra den langsomme RAM, men an hente den fra cache.
Problemet med cache, og det gør sig egentlig gældene, for både RAM-cache, og CPU-cache, det er, at man handler på en formodning om at det her skal bruges. Det betyder at man gennem temmelig avancerede algoritmer laver en sandsynlighedsanalyse, og ligger så det klart, som man forventer der bliver brug for. Hvis man derimod gætter forkert, så kan man cleare sin cache og starte forfra.
Derfor vil en giant mega cache ikke nødvendigvis hjælpe helt vildt - det kommer meget an på hvor forudsigeligt det er, det man skal processe.
Når al det så er sagt, skal det siges at til mange opgaver, er deres gætte-algoritme ekstrem nøjagtig.
Og som en ekstra pind til dit spørgsmål, så vil du se at prisforskellen og ydelsesforskellen på CPU'er ofte ligger i mængden af on-die cache, så at kalde cache ubetydeligt er direkte dumt.
#4 ja, det er bare ikke helt ligeså enkelt som vores almindelig hukommelseslager.
Det der ligger i memory, er de programmer der er aktive. Der er så nogen af programmerne der cacher - altså læser mere op, end der er brug for, så når det skal bruges, så kan man læse det direkte fra RAM, istedet for at bruge den langsomme harddisk.
I princippet er det det samme med cache. Man ligger så meget i cache sommuligt, så når CPU'en skal bruge instruktioner, skal den ikke hente dem fra den langsomme RAM, men an hente den fra cache.
Problemet med cache, og det gør sig egentlig gældene, for både RAM-cache, og CPU-cache, det er, at man handler på en formodning om at det her skal bruges. Det betyder at man gennem temmelig avancerede algoritmer laver en sandsynlighedsanalyse, og ligger så det klart, som man forventer der bliver brug for. Hvis man derimod gætter forkert, så kan man cleare sin cache og starte forfra.
Derfor vil en giant mega cache ikke nødvendigvis hjælpe helt vildt - det kommer meget an på hvor forudsigeligt det er, det man skal processe.
Når al det så er sagt, skal det siges at til mange opgaver, er deres gætte-algoritme ekstrem nøjagtig.
Og som en ekstra pind til dit spørgsmål, så vil du se at prisforskellen og ydelsesforskellen på CPU'er ofte ligger i mængden af on-die cache, så at kalde cache ubetydeligt er direkte dumt.
Er ikke 100% inde i det der emne, kan man sådan nogenlunde sige at det ser sådan ud?:
Harddisk -> RAM -> cache -> processor
|------>------|----->---/---->-----/
Måske en liidt grim tegning, men håber i forstår pointen.
#6 - rasmuslp
Når du skriver 'stor' mener du så fysisk stor eller i byte?
Harddisk -> RAM -> cache -> processor
|------>------|----->---/---->-----/
Måske en liidt grim tegning, men håber i forstår pointen.
#6 - rasmuslp
Når du skriver 'stor' mener du så fysisk stor eller i byte?
#10
Det er en cache mellem CPU og RAM. Der findes andre cacher, som optimerer andre områder, f.eks. diskcache - og den er der endda flere slags af ;-) Men hele ideen i en cache er at få en proces til at gå hurtigere, om det så er disk adgang, ram adgang, textures i et spil, etc.
Og mht #6, så er mener han stor i antal bytes.
Det er en cache mellem CPU og RAM. Der findes andre cacher, som optimerer andre områder, f.eks. diskcache - og den er der endda flere slags af ;-) Men hele ideen i en cache er at få en proces til at gå hurtigere, om det så er disk adgang, ram adgang, textures i et spil, etc.
Og mht #6, så er mener han stor i antal bytes.
#9
Det som nyheden går på, er ikke at man først nu er begyndt at bruge dram til cache, men at IBM har lavet væsentlige fremskridt i at integrere dram i processorer.
I princippet er edram ikke en type ram i sig selv, men snarere en fællesbetegnelse for en mange forskellige typer dram der bruges til samme formål.
Personligt gad jeg godt at vide præcist hvor meget langsommere deres nye ram er, og om det er tiltænkt L1, L2 eller L3 cache.
Det som nyheden går på, er ikke at man først nu er begyndt at bruge dram til cache, men at IBM har lavet væsentlige fremskridt i at integrere dram i processorer.
I princippet er edram ikke en type ram i sig selv, men snarere en fællesbetegnelse for en mange forskellige typer dram der bruges til samme formål.
Personligt gad jeg godt at vide præcist hvor meget langsommere deres nye ram er, og om det er tiltænkt L1, L2 eller L3 cache.
#8
Søgetiden har skam bestemt noget at sige.
Kig bare på amds 65nm cpu vs deres 90nm design
I deres 65nm gjorde de plads til 2mb cache pr core(ca) (dog uden de implementerede denne ekstra cache - kommer senere..), hvilket har gjort at 65nm vs 90nm udgaven er op til adskellige frames (op til 5% langsomere!) vs deres 90nm ellers identiske makker.
Søgetid har skam noget at sige.
Også derfor amd har valgt at lave deres l2 cache unik, vs intels level2 som er shared.
En shared er måske størrer, men tilgangstiden stiger så også tilsvarende.
At amd så laver shared l3 cache i k8l, er så en anden snak .)
Søgetiden har skam bestemt noget at sige.
Kig bare på amds 65nm cpu vs deres 90nm design
I deres 65nm gjorde de plads til 2mb cache pr core(ca) (dog uden de implementerede denne ekstra cache - kommer senere..), hvilket har gjort at 65nm vs 90nm udgaven er op til adskellige frames (op til 5% langsomere!) vs deres 90nm ellers identiske makker.
Søgetid har skam noget at sige.
Også derfor amd har valgt at lave deres l2 cache unik, vs intels level2 som er shared.
En shared er måske størrer, men tilgangstiden stiger så også tilsvarende.
At amd så laver shared l3 cache i k8l, er så en anden snak .)
#10 I princippet er din tegning egentlig korrekt nok, men som jeg forsøgte skrive i mit indlæg, sker der en masse suboptimering, der gør billedet endnu mere uklart.
Cache er meget enkelt en buffer, som man kan ligge data i, som man regner med bliver brugt.
Man bruger cache alle mulige steder, som #11 også er inde på.
Den suboptimering jeg snakker om, er f.eks. en database-engine, der typisk vil ligge så meget af indeks i RAM, og måske vil lave en analyse af det mest brugte data, der så også kan blive hevet op i RAM.
Det er derfor man ofte ser en database-service bruge så meget hukommelse. Det er egentlig ikke fordi selve DB-engine kræver de enorme ressourcer, det er simpelthen optimering.
Man kan jo ligeså godt trække data op, som man regner med skal bruges, på et tidspunkt hvor maskinen alligevel står og idler.
OS gør det også - hvilket ofte giver et fejlagtigt billed af hvad OS kræver for at køre. En Vista hjemme hos mig, trækker out-of-the-box ca 700MB, og det er netop en masse caching.
Cache i harddisk, er iøvrigt ofte for at man kan sende klumper af data, så man bringer antallet af interrupts ned til et minimum. Idag har vi også halvintelligente controllere, der tager yderligere en del af arbejdet for CPU'en, igen så vi kan skærer ned på antallet af interrupts.
Hvis du vil læse om cache, er Wiki som sædvanlig meget behjælpsom - her...
Cache er meget enkelt en buffer, som man kan ligge data i, som man regner med bliver brugt.
Man bruger cache alle mulige steder, som #11 også er inde på.
Den suboptimering jeg snakker om, er f.eks. en database-engine, der typisk vil ligge så meget af indeks i RAM, og måske vil lave en analyse af det mest brugte data, der så også kan blive hevet op i RAM.
Det er derfor man ofte ser en database-service bruge så meget hukommelse. Det er egentlig ikke fordi selve DB-engine kræver de enorme ressourcer, det er simpelthen optimering.
Man kan jo ligeså godt trække data op, som man regner med skal bruges, på et tidspunkt hvor maskinen alligevel står og idler.
OS gør det også - hvilket ofte giver et fejlagtigt billed af hvad OS kræver for at køre. En Vista hjemme hos mig, trækker out-of-the-box ca 700MB, og det er netop en masse caching.
Cache i harddisk, er iøvrigt ofte for at man kan sende klumper af data, så man bringer antallet af interrupts ned til et minimum. Idag har vi også halvintelligente controllere, der tager yderligere en del af arbejdet for CPU'en, igen så vi kan skærer ned på antallet af interrupts.
Hvis du vil læse om cache, er Wiki som sædvanlig meget behjælpsom - her...
I tillæg til #14:
Vista har jo netop også en ready-fetch mekanisme (eller hvad den nu heder), som gør at maskiner med lille hukommelse (læs MAKS 512mb), kan bruge USB drev m.m. til at lagre disse slags programer på, således harddisken ikke skal bruges så meget (i form af dens swap fil).
Det er da netop smart at os/programmerne kan forudsige hvad der er nok bliver behov for i fremtiden, og således prøver at gøre dette klar.
At dette så også bare sker nede i selve cpuerne (tjek evt. p4 for stjerne eksemplet), hvori deres lange pipeline netop gør at de bliver nød til en lang stykke af vejen, gætte sig til hvad der skal bruges i fremtiden.
Vista har jo netop også en ready-fetch mekanisme (eller hvad den nu heder), som gør at maskiner med lille hukommelse (læs MAKS 512mb), kan bruge USB drev m.m. til at lagre disse slags programer på, således harddisken ikke skal bruges så meget (i form af dens swap fil).
Det er da netop smart at os/programmerne kan forudsige hvad der er nok bliver behov for i fremtiden, og således prøver at gøre dette klar.
At dette så også bare sker nede i selve cpuerne (tjek evt. p4 for stjerne eksemplet), hvori deres lange pipeline netop gør at de bliver nød til en lang stykke af vejen, gætte sig til hvad der skal bruges i fremtiden.
#12 - Det er jo netop det. Jeg tror at de fleste ASIC producenter som tilbyder eDRAM, angiver meget lavere latency for deres eDRAM ifht almindelig eDRAM. "Nyheden" er jo ikke værd at læse uden lidt mere indhold. eDRAM som cache og andre højhastigheds buffere er og bliver en gammel nyhed.
Kopieret fra ARS:
IBM says that it has a 65nm prototype eDRAM running with 1.5ns latency and 2ns random cycle time—speeds that are competitive with current SRAM.
Svjv, så har andre producenter ligget omkring 4-5 ns ved deres 90nm tech.
Man bliver sgi overrasket over niveauet heromkring.
Kopieret fra ARS:
IBM says that it has a 65nm prototype eDRAM running with 1.5ns latency and 2ns random cycle time—speeds that are competitive with current SRAM.
Svjv, så har andre producenter ligget omkring 4-5 ns ved deres 90nm tech.
Man bliver sgi overrasket over niveauet heromkring.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund