Bob Ibsen

Høyere klokkefrekvens kompenserer for slakkere timings, og vice versa. Å få både pose og sekk er sjelden - noen kompromisser må man nesten inngå. Du har ingenting å bekymre deg for. Socket 939 har dualchannel, noe som ytterligere bidrar til at man er godt berget, selv med value-RAM. Som sagt er CPU-klokke mye viktigere enn minneytelse, men selv der skal det ganske store sprang til for at det blir merkbart i f.eks. krevende spill. En FX-57 synes jeg er et meget dårlig kjøp, for den saks skyld. Man får jo en dualcore for mye mindre, og forskjellen fra lavere, betydelig rimeligere modeller er ikke verdt prisen for de aller aller fleste.

med andre ord så prøver dere og fortelle oss at dem selger "defekte" x2 4400+ med stempel som x2 3800+? Så hvis jeg skal gå til innkjøp av en 3800+ så vil jeg vite at dette er en svak prossesor?

Ehmm, la meg utdype... Det er vanlig at prosessorer ender opp med delvis defekt cache, og da bruker produsentene å deaktivere noe av denne (halvparten), og selge dem som lavere modeller. Prosessorene er akkurat like gode, bortsett fra at cachemengden ikke blir som opprinnelig planlagt. Ingenting å bekymre seg for, utover at mengden ikke blir den samme. Hvor mange eksemplarer av 3800+ som opprinnelig var produsert med 2x1MB, er jeg dog ikke sikker på.

X2 4000+ tror jeg neppe vi får se med det første. AMD er nok avhengige av å opprettholde en viss balansegang mellom modellene, og en lansering av 4000 (med 2x1MB L2) ville nok resultert i at de ble sittende igjen med et fjell av X2-prosessorer med 2x512kB. De er avhengige av å kvitte seg med kjernene som har delvis defekte cacher, og en lansering av 4000 ville nok langt på vei satt en stopper for det.

Da kan man vel heller spørre seg hvorfor prisforskjellen mellom 2x512kB og 2x1MB er så liten?

Først og fremst....

Om jeg skulle uttrykke min ærlige mening om denne nye BIOSen, i usensurert form, ville det nok ført til utestengelse på livstid...

Når man først skal utgi noe.... er det mulig å bomme kraftigere? Dette ville vært hårreisende selv etter beta-målestokk. Noe så tvers igjennom ubrukelig som denne nye BIOSen trodde jeg ikke det skulle være mulig å få til. De nye dividerne er helt på jordet. 150 - og 183-dividerene hadde jeg ventet å få. Istedet er det 216, 233 og 250, og minst en av dem satte minnet til CPU/20 ! Alle gangene jeg gikk inn i memtest var både CPU og minneklokke helt på jordet i forhold til valgte innstillinger. DDR200 ble resultatet ved flere anledninger...

HTT går automatisk til 216 uansett pokker hva man gjør. Det eneste positive er at enkelte øvrige minnetimings nå faktisk blir hva man setter i BIOS, og at det er noen nye funksjoner. Men dette er bare helt utrolig. Jeg er sjeleglad for at jeg i det minste fikk flashet tilbake til 711-versjonen, som i forhold er en sann velsignelse.

Jeg er visst ikke den første som plages med denne:

http://www.dfi-street.com/forum/showthread.php?t=24371

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være,  L1 er da mer en raskt nok?

Jeg vet ikke om den er raskt nok, men så bare på muligheten for en ennå raskere cache. Siden hastigheten på cache synker med økende størrelse (...)

Kan du utdype hvordan størrelsen isolert sett reduserer hastigheten?

Kanskje et økende behov med 64bit OS og programvare siden 64bit kode tar rundt 20% ekstra plass og lagringsplassen i registrene "halveres" ved bruk av 64bit kode. (Mulig jeg tar feil på det siste her, men jeg slenger det ut likevel).

64-bits OS og kode vil jo aktivere 64-bit "long mode" slik at GPRs fulle bredde kan utnyttes. Jeg ser ikke hvordan det skal bli verre enn hva som er ståa for de fleste idag, hvor man ikke får utnyttet hele bredden (i Legacy Mode). Både instruksjonslengde og registerlengde vil jo "blåses opp" like mye, og følgelig gå opp i opp?

Så vidt jeg vet er det ingen forskjell, bortsett fra REG og socket. Disse blir så langt jeg kan se blåkopier av X2, bare at Opteron kommer i laveffekt-utgaver i tillegg. Om de vil kjøres paralellt på både 939 og 940 er jeg ikke sikker på ( litt forvirrende, dette her )

http://forum.hardware.no/index.php?showtopic=455946&hl=

New Kid: Vi må vite hvilket system du tenker på - eller blir det bare famling i mørket...

Takk for påminnelsen! Jeg er blitt så lei av å sjekke at det har blitt så som så i det siste. Angående vDIMM er det praktisk talt dokumentert at forskjellen mellom 3,1 og 3,2 er VELDIG liten, kanskje 0,03 elns.

Skal se om jeg gidder prøve den snart...

Endre: Det du sier om sammenhengen mellom REG-support og mulighet for større mengde er på ingen måte feil. Når man ser på tidligere revisjoner av Opteron vs. desktop er det tydelig at dette utgjør forskjellen - socket 939-prosessorer av f.eks. CG-revisjonen kunne neppe ha klart å drive en tilsvarende minnemengde på pålitelig vis.

Men la meg minne om at kontrollerens kvalitet i betydelig grad kan veie opp for manglende REG-support - og her ser det ut til å ha skjedd mye siden lanseringen av Athlon64.

En socket 939-CPU av E-revisjonen klarer faktisk 4GB uten problemer - til og med i "skam-klokket" tilstand.

Dette er 4x1GB unregistered Crucial Ballistix Z503:

Angående old-school vs. "new-school" Winbond-minne har jeg en anelse om at forskjellen er noe overdrevet. Produksjonsprosessen er forskjellig mellom BH og CH, mens 5 -eller 6-tallet i gamle dager anga sorteringen. Men bare fordi dagens BH-chiper ikke lenger kvalitetssorteres av Winbond er det ikke dermed sagt at de automatisk er dårligere enn old-school. Ikke misforstå - jeg har selv fire stykk nye TwinMOS SP 3500 - og de varierer mye i kvalitet fra den beste til den dårligste. Jeg mener å huske at ArcticOC erfarte noe lignende med sine - den ene gikk til 250, og den nest beste bare til 230 eller deromkring...

Poenget mitt er at så lenge hver enkelt minneprodusent er nøye med kvalitetssorteringen, ser jeg ikke hva som skal gjøre ny BH-5 dårligere enn de gamle - dette er Mushkin RedLine PC4000 og OCZ VX PC4000 gode eksempler på. En annen ting jeg vil nevne er at 32MB-chiper (som altså begrenser modul-størrelsen til 512MB) taper mer og mer terreng sammenlignet med f.eks. Micron -5B D (64MB), etterhvert som større mengde blir viktigere...

Med forbehold om at det kan være andre faktorer jeg har gått glipp av (ang. old-school Winbond)

Selv om det ikke er det som sies her så er det viktig å ha klart for seg at en økning av antall frames innenfor en gitt cache-størrelse øker sjansene for "conflict" (bare i tilfellet noen trodde det var en enkel løsning å øke antall  frames).

Klart, så lenge størrelsen er konstant, vil jo flere frames uunngåelig føre til redusert associativity, som gir lavere tilgangstid, men høyere conflict-rate. Har du forresten noe å tilføye angående søketid? Er det flere ting som må tas i betraktning?

I følge en eldre artikkel av "Hannibal" jeg leste var vel 4 - 8-way ass. det han anså som optimalt (tar forbehold om at jeg husker feil).

Det kommer fra samme artikkel, men her tipper jeg at han mente om begge nivåene skulle ha noenlunde lik associativity - dvs metoden som Intel har for vane å bruke. For eksempel har Prescott og Dothan 8-way over "hele fjøla". AMDs løsning er jo temmelig annerledes i og med at L1 er 2-way, som er meget lavt, og L2 bruker 16-way, som er høyt.

In general, it turns out that when you factor in current technological conditions (i.e. the speed of tag RAM, the range of sizes that most caches fall into, etc.) some level of associativity less than or equal to eight-way turn out to be optimal for most caches. Any more than eight-way associativity and the cache's latency is increased so much that the decrease in miss rate isn't worth it. Any less than two-way associativity and the number of collisions often increase the miss rate to the point that the decrease in latency isn't worth it.

Graf fra wikipedia:

Simen1: Skjønner ikke helt hva behovet for ett nytt hurtigere L0 cachenivå skal være,  L1 er da mer en raskt nok?

Tenkte egentlig på det samme, og mine idéer om økt linjestørrelse, eventuelt økt associativity går jo litt i motsatt retning. At L1-latency er på tre sykluser har jeg lest så mange steder at jeg nærmest regner det som "opplest og vedtatt"

Takk for det Vel, det kjipe er at jo mer jeg leser, jo lengre blir lista over de tingene jeg må innse at jeg ikke kan... At noe kan være så sammensatt og komplekst er nesten skummelt. Enda er jo cache bare en liten del av CPU-arkitektur generelt...

Bob Ibsen: Tror du det hadde gitt noe mening om AMD innførte et nytt cachenivå mellom L1 og kjernen? Jeg tenker da at dagens L1 er ganske treg fordi den er så stor. Kunne det gjort seg med f.eks en liten (8 kiB?) inclusive instruksjonscache med ferdigdekode instruksjoner?

Ferdigkodede instruksjoner - mener du et lager for microOps, dvs noe à la Intels trace cache, bare at oversetteren skulle vært mellom L1 og vår forestilte "L0"?

Størrelse er en ting, men AMDs lave associativity gir jo en fordel med tanke på antallet tags som må sammenlignes per søk. AMD oppgir L1-latency til tre sykluser, som er i samsvar med målinger jeg har sett. Lav associativity i kombinasjon med den store mengden gir naturlig nok mange frames/sets, men jeg har ikke trodd at dette påvirker søketiden. John Stokes på Ars får det heller ikke til å høres slik ut:

Furthermore, since all the sets consist of exactly four blocks, no matter how big the cache gets we'll only ever have to search through four frames (or one set) to find any given block. This means that as the cache gets larger and the number of sets it can accommodate increases, the more efficient the tag searches get. Think about it. In a cache with three sets, only 1/3 of the cache (or one set) needs to be searched for a given block. In a cache with four sets, only 1/4 of the cache is searched. In a cache with 100, four-block sets, only 1/100 of the cache needs to be searched. So the relative search efficiency scales with the cache size.

Hva han mener er altså at økt størrelse og dermed flere frames i seg selv ikke påvirker søketiden, så lenge associativity er uforandret. K8 har jo samme tilgangstider på alle L2-størrelser, noe som tyder på det samme. Men jeg ser riktignok ikke helt bort ifra at dette kunne vært annerledes hvis f.eks. Sempron var ment for å ha 256 kB L2 fra bunnen av. Altså istedenfor at de større, delvis defekte cachene til en viss grad blir deaktiverte - når hele mengden i utgangspunktet var ment å være aktiv.

Jeg har lurt på om en økning av linjestørrelsen fra 64 til 128 byte, eventuelt en økning i L1-associativity fra 2-way til 4-way kunne gitt en positiv effekt. Tanken bak det er naturlig nok å redusere conflict-rate. Etter overgangen til 64-bits vil det jo bli flere lange instruksjoner/data, og det vil følgelig bli "trangere om plassen".

Hvis det er slik at en liten "L0" kunne implementeres til lavere tilgangstid, kan du jo være inne på noe. Om jeg tolker deg rett angående plassering av oversetter og lagring av ferdigbehandlede instruksjoner, måtte vel den ekstra cachen vært inkluderende i forhold til L1. Slik at instruksjonene ikke måtte oversettes tilbake igjen ved evictions (det er ihvertfall hva jeg ser for meg).

En annen ting: Kunne det vært en idé å innføre et nytt L3 cache-nivå i form av en "ekstern" DRAM-brikke på Operon-serien. F.eks implementert som en MCM (Multi Chip Module) med en spesialdesignet DRAM-brikke under lokket på CPUen. F.eks en med 1024bit bussbredde og et rask DDR3-minne på f.eks 16-32 MiB. ?

Hvordan stiller egentlig den raskeste DRAMen seg i forhold til SRAM?

Jeg regner ihvertfall med at selv den beste DRAM vil være mye tregere, men det er jo ikke dermed sagt at en slik buffer ikke kunne hatt noe for seg. Hele minnehierarkiet kan jo ses på som en "pyramide" hvor de øverste nivåene er de minste og raskeste, og hvor ytelsen reduseres/størrelsen økes når det legges til flere nivåer. Så lenge hvert nivå er et fornuftig kompromiss mellom ytelse og størrelse kan det jo være hensiktsmessig å plusse på med flere (ihvertfall inntil et visst punkt). Størrelsen du foreslår vil nok være en fornuftig mellomting mellom L2 og RAM. Derfor kunne det nok gi ytelsesgevinst, selv om den naturligvis ville vært tregere enn den "ekte" cachen. Hvorvidt dette ville la seg gjennomføre av hensyn til areal og økonomi har jeg ingen anelse om - det regner jeg med at du allerede har fundert litt over... Men ytelsesmessig vil jeg som nevnt ikke utelukke at det kunne ha noe for seg.

Uansett vil vel det meste vi diskuterer her kreve et omfattende redesign av arkitekturene, slik at det ikke bare kan "klaskes på" det eksisterende designet...

Det var ihvertfall fint å få litt å tygge på

Dette med coherency protocols er jeg ikke særlig inne på, men som du sier vil det nok være gyldig for en eventuell L3-cache i tillegg til L1, L2 og RAM. All minnetrafikk må så langt jeg kan forstå "overvåkes" i dualcore-design, uansett hvilke nivåer det er snakk om.

Angående nåtidens AMD/Intel mobile/desktop-prosessorer forekommer ikke bruk av hverken fully associative eller direct-mapped cache schemes. Alle design benytter altså mellomting av disse (n-way). Husk at fully associative krever at absolutt alle tags sammenlignes ved hvert eneste søk, noe som er lite effektivt. Hva angår fleksibilitet er dette den beste løsningen, men denne fordelen er ikke nok til å veie opp for økt latency. En annen ulempe er kravene til interconnects på kryss og tvers.

Direct-mapped gir lavest mulig søketid, fordi alle minneadresser er underordnet én bestemt blokk i cachen - dermed er det bare nødvendig å søke den ene framen for data. Problemet er at dette kan medføre ekstra flytting imellom cachene, i tillegg til dårligere plassutnyttelse. Cachelinjene vil "kollidere" med hverandre - såkalt conflict-rate hvis f.eks. et working set ikke får plass i en enkelt frame (i en direct-mapped cache vil det altså være like mange frames som antall blocks).

AMD K7 og K8 befinner seg nærmere disse to ytterpunktene enn Intel. AMD benytter 2-way set associativity for L1, og 16-way for L2.

Denne grafen sammenligner conflict rate forbundet med forskjellig associativity. Isolert sett ser vi at fully associative ligger best an, men denne fremstillingen tar altså ikke hensyn til søketid.

Selv bruker jeg BH-5-minne på ganske høy spenning

Hvilken type? Evt hvor kan jeg kjøpe?

Disse brikkene. De gir mye per krone, men mine fire brikker varierer ganske sterkt i kvalitet, og de fås ikke i matchede dualchannel-sett. Hvis du ikke kan gi høy spenning er nok ikke dette minnet for deg.

Egentlig vil jeg anbefale 2x1GB, fordi du da er sikret kapasitetsmessig i en stund fremover, og fordi det ikke blir særlig dyrere enn tilsvarende bra 2x512-brikker.

Patriot 2GB

EvenSteven: Tilgangstidene du har er høye sammenlignet med AMD-systemer, men det er det lite å gjøre med. Dessuten bør man ikke opphenge seg for mye i slike målinger - både Intel og AMD har sine fordeler og ulemper, og benytter forskjellige metoder for å nå samme mål (=høy ytelse).

RAM med høy klokkerating og slakkere timings kan godt bestå av akkurat samme innmaten, og følgelig oppføre seg så og si likt. Intel-systemer tjener mer på høy klokke enn på stramme timings. AMD liker stramme timings, men høy klokke er naturlig nok også en liten fordel.

Ikke for å hakke, men mener jeg så en test på xtremesystems.org om at denne "myten" er feil.

Mener du første eller andre "ledd" av innlegget mitt?

Timings er ikke akkurat alfa og omega i noen tilfeller, men egne tester viser nærmest skremmende liten forskjell på P4-systemer. At Intel for lengst er gått over til DDR2, som jo har mye høyere tilgangstider, er også er sterk indikasjon på at timings er mindre vesentlig for deres plattformer.

fin tråd

Takk!

Dette har sine logiske grunner...

 

La oss si at du har et program på 800kbyte... Når du kjører programmet så hopper du fram og tilbake i programmet hele tida og må derfor ha tilgang til 800kb data..

 

Hvis du har 512kb L2 cache (og 128 L1 cache) så er dette akkurat for lite til at du kan ha det i L2 cachen. Har du 1mb L2 cache, så holder det...

 

Data som modeller/terreng osv er gjerne for store for L2 cachen samme hva, så hvis cpu'n er smart nok så blir ikke disse liggende i L2 cachen på bekostning av mer ofte brukt data som f.eks instrukser.

 

Jeg tenker at de fleste programmer har ett "ytelseshopp". Dvs at ytelsen øker jevnt og trutt med mengden L2 cache helt til en essensiel del av programmet passer helt inn i L2 cachen og ytelsen øker markert. Deretter fortsetter ytelsen å øke med mengden L2 cache, men såvidt merkbart ettersom hoveddelen av programmet nå ligger i L2 cachen.

Joda, alt har sin logiske forklaring, men jeg ville fortsatt trodd at forskjellen mellom 128kB og 512kB skulle være større, fordi en større andel av de mest nødvendige dataene selvsagt kan caches med 512kB. Således burde det jo bli færre minne-henvendelser, selv om ikke hele programmet får plass i cachen. Dette handler nok om data snarere enn instruksjoner, fordi data i de fleste tilfeller vil ha mye lavere reuse-rate enn instruksjoner. At minneytelse har større betydning i spill enn i mange andre applikasjoner tyder også på dette.

L1 har jo også en dedikert Instruksjons-cache, og i akkurat denne sammenhengen ser jeg uansett ikke at L2-størrelsen skal hjelpe nevneverdig, fordi en evicted instruksjon trolig blir forespurt igjen før den må flyttes ned fra L2 til RAM i de fleste tilfeller. Instruksjoner/data som er hyppig brukt er også de som vil få høyest prioritet, da en vanlig replacement policy er LRU (Least Recently Used) - altså at blokken som sist var i bruk blir nedprioritert når cachen må rydde plass til nye data. Poenget med caching er egentlig at man tar høyde for at dataene skal bli brukt igjen, slik at prosessoren får mye raskere tilgang til dem neste gang. Data som bare skal brukes en gang (f.eks. en musikkfil som spilles fra begynnelse til slutt) kalles da for cache polluter. Mye data blir cachet til liten nytte, og det samme fenomenet gjelder for spilling. Selvsagt ikke i fullt så stor grad men fortsatt nevneverdig, fordi data hele tiden må skiftes ut, og flyttes frem og tilbake. Maskinen "vet" ikke hva du har tenkt å gjøre - spilling er som regel en lite forutsigbar oppgave når det gjelder f.eks. hvilke modeller som trengs. Om du svinger til høyre eller venstre i et bilspill kan ikke prosessoren vite på forhånd, men det kan få store konsekvenser for hvilke data som trengs. Instruksjonene, blant annet for manøvrering og fysikkberegning, vil myegodt gå igjen uavhengig av det.

Filmkoding er et eksempel på en særdeles forutsigbar oppgave, hvor både working set passer i L1-I, og datastrømmen kan hentes i en forutbestemt og uforanderlig rekkefølge. Testen viser jo også praktisk talt null forskjell når det gjelder disse applikasjonene.

Når det gjelder L1-cachen på AMD-prosessorer er det ikke fysisk plass som er den fremste begrensningen sammenlignet med andre prosessorer, men at de har lav associativity. Dette gjør at bare to blokker i RAM kan hentes til samme L1-sett til enhver tid - absolutt alle minneaddresser har bare to fastsatte blokker de kan caches i (16 for L2). Dette gjøres for å holde søketiden på et lavt nivå - jo flere blokker hvert sett består av, jo mer må søkes igjennom for hver forespørsel. Men at hver minneadresse har to tilhørende cacheblokker betyr selvsagt ikke at alle adressene må kjempe om de samme to cacheblokkene. Derimot kan det medføre endel flytting imellom cachene fordi det gir flere såkalte conflict misses - når disse inntreffer hjelper det ikke om resten av nivået (hypotetisk sett) er helt ribbet for data. Dette handler også om hvordan "ren" og veltilpasset programvaren er.

(dette med associativity finner jeg temmelig vanskelig å forklare)...

Edit: innlegget er noe "justert"

Opteron 175 2.2 GHz 2x1MB Cache 1way (dc)

Opteron 170 2.0 GHz 2x1MB Cache 1way (dc)

Opteron 165 1.8 GHz 2x1MB Cache 1way (dc)

Disse prosessorene vil komme til socket 939 i tillegg.

Da må du nok lese noen generelle BIOS-guider. Under "overklokking generelt" er det en sticky som går igjennom en rekke BIOS-innstillinger. Du bør nok også benytte manualen til ditt hovedkort. Om kjøling er nødvendig på disse brikkene er jeg ikke sikker på, men vil regne med at det er fordelaktig. Selv bruker jeg BH-5-minne på ganske høy spenning, og benytter en 120mm stillegående vifte til kjøling.

Minneklokke er ikke på langt nær så viktig som CPU-klokke, men det har litt å si.

Da jeg skrev 300 MHz mente jeg "grunn-frekvensen" - alle DDR-moduler har to signaloverføringer per klokkesyklus - slik at 200 MHz ofte omtales som 400 MHz effektivt (DDR400). 300 MHz tilsvarer altså DDR600.

Begge alternativene du linker til krever høy spenning for å kunne yte sitt beste - helst oppimot 3,5 volt (i noen tilfeller mer). Hva klarer hovedkortet ditt?

Brikkene vil kreve aktiv kjøling på slike spenninger. TwinMOS-brikkene gir mye for pengene, men de er ærlig talt ikke prima vare (har fire selv).

Har du først bestemt deg for å kjøpe 2GB vil jeg uansett anbefale 2x1GB på det sterkeste.

Patriot 2GB

Crucial Value

Crucial Ballistix PC4000

Patriot er billig og bra. De nederste brikkene er etter all sannsynlighet de beste 1GB-brikkene per idag (se her).

De midterste er billig-utgaver, men i prinsippet samme minne, bare av lavere sortering.

BTW, forumet har egen kategori for overklokking.

Minnebrikkers egenskaper avhenger først og fremst av hvilke chiper de er sammensatt av, og indirekte sett hvilken plattform de brukes på.

De brikkene der har enten Samsung TCC5 eller TCCD (fysisk sett samme chiper, men TCCD er den høyeste kvalitets-sorteringen). Disse passer best til AMD64-systemer, og kjennetegnes av høyt klokkepotensiale, moderate krav til spenning, og ikke minst meget bra fleksibilitet. Med det mener jeg at de både klarer stramme timings (2-2-2-6) på standard klokke, og høyere klokke hvis man øker timingene til f.eks. 2,5-3-3-8 (over 300 MHz på det meste). TCCD har jeg sett på over 250 MHz med 2-2-2-6-timings, men det er ikke akkurat hverdagskost.

Hvis du ikke skal overklokke, og har et AMD64-system vil nok 2-2-2-6 på 2,7-2,8 volt gå greit.

RAM med høy klokkerating og slakkere timings kan godt bestå av akkurat samme innmaten, og følgelig oppføre seg så og si likt. Intel-systemer tjener mer på høy klokke enn på stramme timings. AMD liker stramme timings, men høy klokke er naturlig nok også en liten fordel.

Jeg ser ingen grunn til å velge 32-bits-prosessor.

Ikke jeg heller. Både fordi prisforskjellen er minimal, og fordi 64-bits-utgavene er av nyere (=bedre) revisjoner.

Jeg anbefaler også AMD - de er jevnt over endel bedre til spilling.

200 MHz klokkefrekvens vil nok ha litt større betydning i de fleste tilfeller, så 3800 vil kanskje yte bittelitt bedre på standard klokke. 3700 er dog San Diego, som nok gjennomsnittlig overklokker endel bedre enn Venice. Den er vel litt rimeligere og?

Jeg har laget en tråd som forklarer grunnleggende cachebegreper, og sammenligner forskjellige størrelser:

http://forum.hardware.no/index.php?showtopic=468318&hl=