Test: L2-størrelse på AMD = lite viktig

[Del]

Det er sant, egentlig gir jo DC bare enda ett nivå med interconnect hastighet. Ideen med NUMA er å lokalisere minnet, dvs. ha kjapp tilgang til minne lokalt for CPU'ene, og prøve å distribuere minnet optimalt etter behovet til de forskjellige nodene (minimere trafikk mellom noder). Helt parallelt prinsipp har man på en standard linux klynge hvor hver node har to CPU'er som kommuniserer kjapt, mens inter-node kommunikasjonen er mye tregere. I tillegg kan man operere med ett nivå over (spesielt på store klynger) hvor man rangerer (relaterer er vel et bedre ord, det trenger neppe å være en trestruktur) noder etter hvor kjapp kommunikasjonen er dem i mellom. På store klynger kan begge nivåene være viktige for å oppnå god skalering ved veldig store problem, så i utgangspunktet kan det jo tenkes at det er en del å hente på å innføre ett nivå under, interconnect for kjerner på en DC chip.

 

Et annet moment jeg ikke tenkte på sist er det faktum at klynger gjerne har flere brukere/jobber gående parallelt, ofte bruker ikke jobbene mer enn 1-4 kjerner. Jobber som bruker to kjerner kjøres selvfølgelig på samme node hvis mulig (hver node har typisk to CPU'er), jobber som bruker 4 kjerner kjører på to noder, tilsvarende vil man ved DC løsningen til Opteron potensielt hente ut mye ved å kjøre 2-core jobber på samme chip.

 

På OS nivå mener jeg klyngeløsninger som kjører linux allerede har den funksjonaliteten du etterspør, selv om kanskje ikke alle klynger rundt omkring har implementert det.

Endret 12. oktober 2005 av Del

[Anders Jensen]

På OS nivå mener jeg klyngeløsninger som kjører linux allerede har den funksjonaliteten du etterspør, selv om kanskje ikke alle klynger rundt omkring har implementert det.

For klynger er nok det i ferd med å bli veldig vanlig ja. det blir likevel litt anderledes å få det implementert på NUMA maskin fordi topologien i maskinen ikke er like synlig på OS nivå som topologien til en klynge er.

[exin89]

Problemet med denne L1 Trace cachen (som Intel kaller det) er at det er dyrt/vanskelig å stappe store mengder av den inn i en prosessor.

4822924[/snapback]

Er da dette det samme som å si at, iogmed at det er dyrt/vanskelig, at det dermed ikke er så store mengder L1, slik at L1 blir full og at CPU'en da begyner å slite og henger hele pcn.

 

Har i hvertfall et roblem som er i nærheten av det på min pc, altså lite av L1 og pcn henger seg uten grunn, selv om jeg ikke kjører mye på en gang. (det er ikke virus/spyware som henger pc'n)

har P4 2.4, HK: ASUS P4B533-V 512MB PC2100 Crucial minne.

[blackbrrd]

Eh... Hvis PC'n din henger seg så har det ikke med at L1 cachen er full, det er nok heller at maskinen din må swappe til disk, eller gjøre andre tunge operasjoner..

[el-asso]

Er en vesentlig forskjell på L1 cache i Pentium 4 og A64 du har glemt. Pentium 4 lagrer ferdig dekodete instruksjoner i L1-i (instruksjons cache). Dette gjør at den slipper å dekode instruksjoner som alt finnes i L1. A64 må dekode alle instruksjoner, selv de som kommer fra L1 cache.

 

Problemet med denne L1 Trace cachen (som Intel kaller det) er at det er dyrt/vanskelig å stappe store mengder av den inn i en prosessor.

4822924[/snapback]

Det er også dyrt å metatagge instruksjonene i L1 som AMD gjør (K7 og K8).

Det spiller vel liten rolle for de totale kostnadene om L1/trace cache består av ferdig dekodede instruksjoner i form av uops eller om de dekodede instruksjonene befinner seg i ett annet register på kjernen.

 

Trace Cache kommer ikke i tillegg til L1, men i stedet for den delen som AMD bruker til ukodede (men predekodede) instruksjoner.

[Pirka]

En liten annen forskjell kan være at han har lagt inn BF2 på Raptoren, mens jeg har den på en vanlig disk. (Har raptoren som systemdisk begge 2)

Der ligger nok 90% av loadetiden.

4826078[/snapback]

 

 

Hmmm ... er disse BF2 baner så sinsykt store på antal mb ??'

Vannlig hdd kan lese sån 30-40mb i sec så hvorfår tar det over 30sec får å lese en bane ??

 

PS: Hos meg ligger det på ca: 30-40sec med WDC 250gig og 16mb cache.

[Gjest Slettet-XHLacM]

Hva er L1, L2 og Cache (-minne?) for noe? Har alltid lurt på det.

[gullf1sk]

Whoa, gravedigging :O

[unundindur]

Glimrende tråd!

 

Takk for insatsen.

[Spragleknas]

(...)Jeg håper vi får se Mobile Sempron i butikkene - det kan bety gode muligheter for fattigmannsklokking! (...)

4822713[/snapback]

 

Fremdeles ingen å se... kun Turion.

[Kenneth Solfjeld]

*nevermind*****

Endret 18. juni 2006 av Vultur Gryphus

[OnetroM]

Veldig informativ tråd, men så vidt jeg har fått med meg så gjelder den kun en-kjerne CPU'er.

Har cachen mer, mindre eller lik betydning for nye CPU'er med dualcore?

Sitter og lurer litt på to 939 cpuer, X2 4600+ eller X2 4800+

Sistnevnte har 2MB cache og koster endel mer. Hvor mye ytelsesforskjell er det og ikke minst hvilke typer applikasjoner vil dette ha størst betydning?

[Manx]

Har ett godt eksempel her. Min bror og jeg har ett meget ligt oppsett når det kommer til PCen.

 

Begge har Asus A8N-SLI Deluxe

Corsair PC4400 - 4x512

 

Jeg har en 3800+ (kjøpt i mars, og rett før winchester, venice og san diego kom)

 

Brodern har 4000+ kjøpt med feriepenger, tror det er venice han har. Forskjellen utad er egentlig 512 kb L2 mot 1 MB.

 

Når brett lastes inn i Battlefield 2 bruker jeg ca 45 sekunder, han ca 20-25 sekunder. Noe som er en ganske stor forskjell

 

En liten annen forskjell kan være at han har lagt inn BF2 på Raptoren, mens jeg har den på en vanlig disk. (Har raptoren som systemdisk begge 2)

4825984[/snapback]

 

Feil og feil, det er en San Diego og BF2 er ikke installert på raptoren (ja jeg vet det snart er et år siden )

[Lampen]

hva gjør en cpu bra? er det frekvensen cache. eller gh. kan noen forklare