det undrer mig en smule at de ikke smider en 3Ghz version på gaden med det samme, da den jo findes til AM2+. Det burde da ikke være så svært. men det er måske ikke der det primære salg ligger..
--
The silence after a storm!...Plextor has spoken

#1 Phenom II X4 920 kommer også i en am3 model
--
Bundkort: ASrock A780G CPU: AMD X4 9850 Black Edition 2.5GHz @ 2.9GHz Grafikkort: Sapphire Radeon HD 4870 512 GDDR5 RAM: A-Data 2x2GB+2*1 800 MHz

Ja det er jeg klar over, men som jeg skrev kommer den jo ikke på gaden med det samme. læs lige mit indlæg igen.
--
The silence after a storm!...Plextor has spoken

#3 sorry
--
Bundkort: ASrock A780G CPU: AMD X4 9850 Black Edition 2.5GHz @ 2.9GHz Grafikkort: Sapphire Radeon HD 4870 512 GDDR5 RAM: A-Data 2x2GB+2*1 800 MHz

Nu er det jo ingen hemmelighed at cpu salget generelt går lidt trægt for tiden og lagrene er større end de burde. Og da AM3 modellerne jo er fuldgode erstatninger for AM2 (de kan køre DDR2 ram osv) kunne det jo tænkes at AMD gerne vil have solgt de allerede producerede AM2'er før de konkurrende AM3'ere slippes løs (skal vi gætte på at de ikke laver AM2 længere).
--

720 Black Edition til 11-1200kr ser da i øvrigt pænt attraktiv ud. Så er det da ved at være slut med at anbefale 8400/8500...
--

#6 enig.http://hwt.dk[...]
--
Veritas Vos Liberabit GA MA790GP-DS4H/PhenomX49950BE@3400 24/7@3200mhz/ Radeon4870(top bios)/2x2GBMushkinRedlinePC8500

men hvornår udkommer de lidt større modeller som 910 og 925? de skulle i hvert fald også udkomme her i februar
--
| Intel Pentium 4 3,2GHz | MSI P4N Diamnond SLI | Asus 8800GTS 320Mb | Kingston 2Gb DDR2 PC2-5300 CL5 | Maxtor DiamondMax 10 200GB SATA | Chill 450W |

ja jeg var også lige på nippet til at købe en E8400 men det bliver der da ikke noget af.. de phenomII klarer sig rigtig godt i tests, i nogle få tests slåt de in i7core og ofte spiller de lige op når det gælder grafiske ting som spil.. og prisen er jo i en helt anden verden når man medregner bundkort...
--

#9 Phenom II klarer sig så godt i spil kontra Core i7 af den simple grund, at CPU'en ikke betyder det store i spil, og ydelsen er i stedet bestemt af grafikkortet. Det illustreres meget godt i AnandTech's test, hvor noget så kedeligt som en E8400 budget CPU er den hurtigste af alle deres testede processorer i det nye Fallout 3 spil. E8400 slår ren faktisk AMD's hurtigste X4 940 model i tre ud af fire spil og slår både X4 810 samt X3 720 i alle spil. Man får meget lidt spil ydelse ved at bruge sine penge på processoren.
--
Mvh. Thomas Christensen

Anandtechs test setup er desværre (som altid) lidt uigennemskueligt mht ramhastighed osv. Og E8400 gør det naturligvis primært godt pga sin høje clock og ikke bare fordi cpu'en er ligegyldig - det kunne bare være rart med nogle game tests, der også inkluderer minimum framerates (har jeg ikke kunne finde), så man kan se hvor meget den evt falder igennem der. Der er jo efterhånden en del spil med rimelig dualcore support, men udover 2 er det (som vi kan se i disse tests) meget begrænset.
--

CK ja det er muligt. men samme anandtech kommer også med denne udtalelse i forbindelse med et andet spil Anandtech(PII=smoother gameplay):" Now that we have discussed the numbers, what about game play experience? As we alluded to earlier, the Intel platforms had problems with minimum frame rates throughout testing, not just in the benchmarks, but also during game play in various levels and on-line. We have not nailed it down yet, but we have noticed this problem consistently. In the meantime, the Phenom II X4 940 had rock solid frame rates and offered the smoothest game play experience" "After playing through the several levels on each platform, we thought the Phenom II 940 offered a better overall gaming experience in this title than the Intel Q9550 based on smoother game play. It is difficult to quantify without a video capture, but player movement and weapon control just seemed to be more precise." så måske er det ikke ALTID ligegyldigt
--

#11 den her test som min quote i #12 er taget fra er der minimum framerates med http://www.anandtech.com[...]
--
Veritas Vos Liberabit GA MA790GP-DS4H/PhenomX49950BE@3400 24/7@3200mhz/ Radeon4870(top bios)/2x2GBMushkinRedlinePC8500

#12: det er noget lidt andet (som jeg er lidt skeptisk overfor, heller ikke noget der bakkes op i deres grafer (*)) - nu tænkte jeg mere på 2 kerner vs 3+ kerners minimum framerate i dagens spil. (*) absolut minimum framerate er et lidt problematisk begreb, da det for nemt bliver påvirket af tilfældige flukturationer (kunne være en windows service fik en sjov ide under et run fx) - man burde hellere bruge noget median-low agtigt..
--

#14 ja ok. men det er jo egentligt lidt sjovt at den tests på Anand, der siger en stor test site lige pludselig noget, som UTALLIGE AMD brugerer har fået rigtig mange hug for igennem tiden,nemlig smoothness :) de skriver selv at det ikke er noget de kan måle men det er noget de kan føle og at det burde have været optaget med et kamera:)
--
Veritas Vos Liberabit GA MA790GP-DS4H/PhenomX49950BE@3400 24/7@3200mhz/ Radeon4870(top bios)/2x2GBMushkinRedlinePC8500

Nå nu læste jeg guru3D's test og jeg må sige at den X3 den imponerer godt nok. 3.7 ghz på en billig luftkøler og den sparker numse til det meste i spil også i7. godt nok kun med en lille smule i høje opløsninger,men sjovt nok er det i alle spillene.
--
Veritas Vos Liberabit GA MA790GP-DS4H/PhenomX49950BE@3400 24/7@3200mhz/ Radeon4870(top bios)/2x2GBMushkinRedlinePC8500

#6 og #16 Enig. X3 720 ser altså ud til at være en ganske fin tilbud. Den er billig, og konkurrer prismæssigt rimelig godt imod Intels dual cores. Den har ulåst multiplier. Overclocker godt. Kompatibel med 2 platformer. Og så er det altså fint nok at have en ekstra cpu kerne fri når de fleste spil understøtter 2 kerner. Så kan ens virus program for eksempel køre i baggrunden (hvis den gider det) uden at det det generer det spil du er ved at køre.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#5 HenrikM - Logikken er rigtig nok, men årsagen til, at vi ikke får hurtigere modeller er noget simplere end som så, for der er ikke noget AMD hellere ville end at lancere hurtigere modeller. Problemet er blot, at der er tale om en ny batch af en ny revision, hvor de eksisterende stammer fra den første, samt at der kun er en pulje at tage fra. Så er spørgsmålet derfor, hvorfor lancere flere modeller, hvis det så betyder, at den ene bliver lidt sparsom i sit udbud og samtidig trænger den første DDR2 batch. De vil ikke få flere penge ud af det, kun ændre hvilken chip de tager 190-220 USD. #11 HenrikM ”Og E8400 gør det naturligvis primært godt pga sin høje clock og ikke bare fordi cpu'en er ligegyldig - det kunne bare være rart med nogle game tests, der også inkluderer minimum framerates (har jeg ikke kunne finde), så man kan se hvor meget den evt falder igennem der. Der er jo efterhånden en del spil med rimelig dualcore support, men udover 2 er det (som vi kan se i disse tests) meget begrænset.” Lige præcist, E8400 gør det så godt pga. spil ikke er så skide afhængig af CPU'en, dvs. det ikke er CPU'ens udregningsevne, men evnen til at kaste data til GPU'en, som afgør det på denne front. Det langt mere simple design med cachen i fokus gør, at en ældre CPU slår alle de nye processorer. Det er værd at bemærke, at E8400 rent faktisk slår Core i7 på TRODS af, at sidstnævnte har flere MHz (3.2 Ghz Core i7 vs. 3.0 Ghz Core 2) samt at Phenom II med samme frekvens er langsommere. Det er altså ikke frekvensen, som er den afgørende faktor, det er derimod cachen, og det sker pga. ydelsen ikke er særlig afhængig af deres regneevne og de faktorer, som vil rent faktisk betaler for, når vi f.eks. køber en Core i7 og i lidt mindre grad Phenom II. Jeg vil naturligvis ikke argumentere for, at den er bedre til gaming, for enhver ved, at den utilregnelige faktor med baggrundsprogrammer eller overhead til dual grafikkort vil favorisere de ekstra kerner og nye arkitekturer, men det er et glimrende eksempel på, hvor lidt spil trods alt er afhængig af processoren. #12/13 MadsE – Præcist, og det er nøjagtig der problematikken ligger. For hvad er forbruget og formålet. Min argumentation er, at CPU'ens rolle bliver overhypet, og jeg kan hver dag se, at tonsvis af brugere spenderer alt for mange penge på processoren uden egentlig at få noget ud af det. For nogle ligger denne grænse imellem Phenom II og Core i7, og for andre ligger den imellem en dual kerne og en quad kerne. Alt for mange går bare skridtet for langt op, og altså over det punkt, hvor deres penge er spildt. Kører du med to grafikkort, vel og mærke to hurtige af slagsen, kommer der lidt CPU overhead på, hvilket naturligvis hæver kravet – det kunne være fra behovet for en quad kontra dual kerne, Phenom II triple kontra dual kerne Core 2, en Phenom II kontra Core 2 eller for så vidt Core i7 kontra Phenom II. #14 HenrikM - Jeg er som bekendt ikke den store fan af minimums frameraten, da brugbarheden ofte er meget lav, og at opfattelsen af den er direkte forkert. Dels svinger den meget, selv med timedemo brug som er den mest stabile og gentagelige proces vi har, og ser vi bort fra disse afvigelser, så siger den ikke nødvendigvis skide meget om den laveste ydelse. Den siger blot, at for EN eneste frame ud af de 2000-4000 frames en timedemo består af, kom ydelsen så langt ned. Den siger ikke noget om, hvor lang tid dette var eller hvor ofte det var. Det er her, brugbarheden af [H]'s benchmarks kommer til udtryk. Lige mht. til det med en baggrundsopgave, så er det ikke et relevant kritikpunkt for benchmarks, da man som hardware side slår alt fra (hvilket i sig selv også reducerer afhængigheden af CPU'en for lige at få den krølle med). Der er ingen anti vira installeret, ingen UAC, ingen auto defrag, ingen ekstra services, ingen Neo, ingen deamon tool eller hvad folk nu har kørende i baggrunden.
--
Mvh. Thomas Christensen

Er der nogen der har forsøgt sig med varians som parameter i stedet for minimum framerate? http://da.wikipedia.org[...] Det kan nemt beregnes ud fra en sekvens af FPS mål taget med regelmæssige mellemrum, og beskriver ret præcist mængden af fluktuationer, uden at en enkelt dårlig måling trækker det katastrofalt skævt.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Hvorfor er det egentlig at AMD ikke smider flere MB i cache på deres cpu'er?
--
GPU: Nvidia Geforce 8800 GT (OC) CPU: AMD Phenom X4 9950 Black Edition PSU: Corsair 520 wattage. Bundkort: Gigabyte GA-MA790X-DS4.

#20 I7 og Phenom arbejder meget på samme måde - Der er ikke behov for mere cache:) Jo højere bus hastighed, og jo hurtigere ram = desto lavere behov for cache. Både I7, og Phenom har en effektiv bushastighed som er højere end cpu'ens hastighed. I7 og Phenom II har begge over 8mb cache og det er nok.(cache er dyrt) Håber det forklarede:)
--

#21 tak :) Men det vil vel så sige at det er lidt ligesom normale ram?
--
GPU: Nvidia Geforce 8800 GT (OC) CPU: AMD Phenom X4 9950 Black Edition PSU: Corsair 520 wattage. Bundkort: Gigabyte GA-MA790X-DS4.

ja, bare 1:1 med cpuens hastighed. cache skaber i øvrigt mere varme da det kræver mere strøm.
--
The silence after a storm!...Plextor has spoken

#22 Ja cache er meget hurtige ram:)
--
Mvh. Dnope(Passwordet er blevet ændret på: http://hol.dk[...] ) Jeg handler ikke hos SHG og Topdata.

Og alligevel ser det jo egentlig ud til at X3'eren egentlig godt kan lide den ekstra cache som den ene afbrudte kerne jo giver.
--
Veritas Vos Liberabit GA MA790GP-DS4H/PhenomX49950BE@3400 24/7@3200mhz/ Radeon4870(top bios)/2x2GBMushkinRedlinePC8500

#21 Dnope ”I7 og Phenom arbejder meget på samme måde - Der er ikke behov for mere cache:) Jo højere bus hastighed, og jo hurtigere ram = desto lavere behov for cache.” Forpulet bullshit fra ende til anden!!! Den eksterne båndbredde, som du af uransagelige årsager benytter "bus frekvensen" til at argumentere ud fra, betyder i praksis INTET for cache behovet (hvis du vil hæve IQ'en bare en smule, så indse ligeledes, at det handler om båndbredden, ikke frekvensen for HT linkene). Det siger sig selv, at hurtigere clock cyklusser til hukommelsen IKKE kan kompensere for straffen ved at spilde adskillige hundrede clock cyklusser for at tilgå hukommelsen. Det er nonsens, og er simpel logik, hvis man bare har den fjerneste ide af, hvordan CPU'en kommunikere. Tilgår du L2 cachen bruger du 5-25 clock cyklusser på at vente for data, og stiger data mængden så CPU'en bliver nød til at tilgå L3 cachen kan du tilføje ekstra 25-80 clock cyklusser CPU'en venter på data. Er cachen fortsat for lille, og CPU'en ikke finder sin data i cachen skal den ikke længere vente 3-100 clock cyklusser (L1 cachen er naturligvis hurtigere end L2, derfor det lavere minimum), men først vente de 3-100 clock cyklusser PLUS et par hundrede clock cyklusser for at tilgå hukommelsen og finde den relevante data/instruktion. Når du hæver frekvensen til hukommelsen forbedrer du kun ventetiden med ganske få clock cyklusser. Diverse timings bliver defineret i forhold til frekvensen, men effekten af en højere frekvens er lavere end stigningen, og det siger sig selv, at en 10-20% forbedring eller sågar fordobling af frekvensen og de flere hundrede spilde clock cyklusser vi snakker om, ikke har den fjerneste effekt kontra cachen. Det er altså noget værre sludder at påstå, HT frekvensen begrænser behovet for cache. Der er mange andre faktorer, som kan have denne effekt, men HT hastigheden er ikke en af dem. ”Både I7, og Phenom har en effektiv bushastighed som er højere end cpu'ens hastighed.” At frekvensen på HT linket er højere end CPU'ens interne frekvens har ligeledes ingen betydning i denne forbindelse. Det svarer lidt til at sige, at kraftværkets evne til at sende strøm ikke bliver forsinket af, at signalet transporteres hurtigere i ledningerne ud til forbrugerne. Det relevante her er, at signalet skal igennem diverse eksterne led samt igennem et længere net – og derfor tager lang tid om at nå ud til forbrugerne, uanset om selve signalet transporteres hurtigere eksternt end internt. Det relevante er ikke frekvensen CPU'en prøver at hente data med, men hvor lang tid dette tager at få fat i den ønskede data, og for hukommelsens vedkommende er det flere hundrede clock cyklusser. Det giver altså ingen mening at sætte CPU'ens interne frekvens overfor HT linkets frekvens. Det er to vidt forskellige størrelser. Core i7 gør ligesom Phenom II, og alle de foregående processorer for den sags skyld, enormt meget for at undgå at skulle gå til hukommelsen, og ligeledes at reducere behovet for cache, men ingen af dem har med hukommelsen at gøre.
--
Mvh. Thomas Christensen

#20 The-Silverflame ”Hvorfor er det egentlig at AMD ikke smider flere MB i cache på deres cpu'er?” Simpelt, cache koster enormt meget på transistor budgettet, og giver kun begrænset ydelse igen i forhold til transistor antallet. Fordoblet du cachen, forbedres ydelsen med ca. 5% og op til 10-15% i hukommelse intensive applikationer. Cachen udgør ca. 50% af chippen, så fordobler du den uden andre ændringer bliver din chip altså 50% dyrere at producere, men ydelsesforbedringen ligger omkring de 5%. Når Intel konsekvent har højere cache i deres processorer skyldes det, at de per definition har råd til et større transistor budget end AMD. De er ca. et år foran mht. proces udviklingen, og det er derfor en del af deres luksus i udviklingen af nye processorer. Man kan groft sagt sige, at AMD skal være smartere og bedre, da de skal have mere ud af mindre, eller acceptere, at de bruger flere penge på at producere samme ydelse. Det er desværre en af de problemstillinger, som AMD har må tage højde for, og har konkurreret på de sidst mange år. Derfor bygger AMD også en cache, som ikke indeholder samme data/instruktioner i de forskellige cache niveauer. Det bruger de noget logik på at løse, hvorimod Intel med deres større transistor budget og cache i stedet sparer disse transistorer og bruger dem på redundant data. Man skal dog ikke lægge for meget i dette mht. ydelse og hvad der er bedst, men det er et udsagn for, at de har forskellige kort at spille med, og derfor laver forskellige tradeoff's.
--
Mvh. Thomas Christensen

#21 Jeg er ganske enig med CK her. Hurtig ram gør en meget tung omkostning markant billigere ... (fordi man sparer rigtig mange CPU clock-cykler, men cache-misses er stadig mega-dyre ...) Og i øvrigt synes Intels kun 2 cachelevels - med delt L2 - at være noget bedre end AMDs relativ lille L2 (dediceret) cache og den sharede L3.
--

#26 "Den eksterne båndbredde, som du af uransagelige årsager benytter "bus frekvensen" til at argumentere ud fra, betyder i praksis INTET for cache behovet (hvis du vil hæve IQ'en bare en smule, så indse ligeledes, at det handler om båndbredden, ikke frekvensen for HT linkene)." Jeg skrev "bus hastighed" ikke "bus frekvensen" - Det her er dejligt at sige til dig: Bevis det! Mens du prøver at bevise det, kan det være du får hævet din IQ lidt:) Så jeg kan kun sige til dig som du sagde til mig: Forpulet bullshit fra ende til anden!!! Hehe.. Det var faktisk rart:) Måske du skulle finde et andet ordforråd, for du får det lige tilbage i dit eget hoved igen:)
--

#28 "Og i øvrigt synes Intels kun 2 cachelevels - med delt L2 - at være noget bedre end AMDs relativ lille L2 (dediceret) cache og den sharede L3." Måske jeg ved det ikke, det har jeg ikke styr på:) Kan tydeligt huske de gamle Celeron med 128mb L2 cache:) Hurtigere ram hjalp på det, ikke at det blev perfekt - Men bestemt bedre:)
--
Mvh. Dnope(Passwordet er blevet ændret på: http://hol.dk[...] ) Jeg handler ikke hos SHG og Topdata.

#25 Ja det 'føles' sådan - hvad end årsagen er:)
--

#31 Hurtige ram er skam heller ikke dårligt ... Man kan 'tjene' mere end hundrede clock-cykler i uheldige situationer .... men det er 'desværre' situationer hvor cache-styrringen (eller måske branch-prediction) har fejlet - og nu står CPU'en så og skal ud i rammen - og det er under alle omstændigheder rigtig dyrt.
--

#32 Tror jeg gerne:) Jeg ser det sådan her(Ikke sikkert det er rigtigt): Hvad med når cpu'en ikke kan nå at få data nok i cachen, på grund af langsom ram og lille cache? Så sløver det enormt. Hvis man så har en høj effektiv bushastighed, som kan overføre en masse data + noget hurtig ram der kan levere data - så må det jo hjælpe en del af netop den årsag. Er du sikker på det ikke er wait stats der er 'dyre' - For der er jo en del wait stats ud til rammen og det koster meget ved jeg:) Mvh. Danni
--

#28 Core 2s cache system var egentlig praktisk talt bedre end phenom 1s. Men med i7 ser det dog ud til at Intel er enig med AMD, phenoms cache system er vejen frem på længere sigt.
--
Gæstebruger, opret dit eget login og få din egen signatur.

"Hvad med når cpu'en ikke kan nå at få data nok i cachen, på grund af langsom ram og lille cache? Så sløver det enormt. Hvis man så har en høj effektiv bushastighed, som kan overføre en masse data + noget hurtig ram der kan levere data - så må det jo hjælpe en del af netop den årsag." Nej, nej og atter nej. Sådan fungerer det bare ikke. CPU siger ikke til hukommelsen, at den skal overføre data/instruktioner fra hukommelse til L3 cache, L3 til L2 eller L2 til L1 før den får brug for data. Det fungere på den omvendte måde, dvs. at CPU'en har brug for data, og tjekker først L1, så L2, så L3 og derefter hukommelsen. For hvert led er der så en masse spildtid, og spildtiden stiger ret drastisk for hvert led vi hopper tilbage i kæden. Efter den HAR brugt den pågældende data, falder dine data/instruktioner så igennem de forskellige niveauer. Når hurtige RAM og tilgang til hukommelsen ikke betyder noget kontra cache, så skyldes det som beskrevet, at der er en masse stop på vejen som er bestemt på forhånd. For at benytte et billede de fleste kan følge med i, så fungerer det lidt ligesom en motor vej med 20-30 kryds, hvor du holder for rødt lys hver gang, og det gør du i 1-10 clock cyklusser. Hvis man nogensinde har undret sig over, hvad det utalt af forskellige timings, som man kan rode med i BIOS'en gør, så er det netop disse stop, som er nødvendige for at tilgå hukommelsen. Når du har disse konstante og predefinerede stop, så betyder frekvensen på hukommelsen ikke det store. Når du har omkring 100 clock cyklusser du bare smider ud af vinduet pga. du tilgår hukommelsen kontra måske 3-15 for L1/L2 cachen, så betyder det altså absolut intet om frekvensen er den ene eller anden. Det er med andre ord noget løgnagtig pjat at påstå, HT hastigheden samt hukommelses frekvensen har nogen som helst påvirkning på behovet for cache.
--
Mvh. Thomas Christensen

#35 "Nej, nej og atter nej. Sådan fungerer det bare ikke. CPU siger ikke til hukommelsen, at den skal overføre data/instruktioner fra hukommelse til L3 cache, L3 til L2 eller L2 til L1 før den får brug for data. Det fungere på den omvendte måde, dvs. at CPU'en har brug for data, og tjekker først L1, så L2, så L3 og derefter hukommelsen. For hvert led er der så en masse spildtid, og spildtiden stiger ret drastisk for hvert led vi hopper tilbage i kæden. Efter den HAR brugt den pågældende data, falder dine data/instruktioner så igennem de forskellige niveauer. Når hurtige RAM og tilgang til hukommelsen ikke betyder noget kontra cache, så skyldes det som beskrevet, at der er en masse stop på vejen som er bestemt på forhånd. For at benytte et billede de fleste kan følge med i, så fungerer det lidt ligesom en motor vej med 20-30 kryds, hvor du holder for rødt lys hver gang, og det gør du i 1-10 clock cyklusser." Alt det ved jeg godt. og jeg ved også det her: "Når du har omkring 100 clock cyklusser du bare smider ud af vinduet pga. du tilgår hukommelsen kontra måske 3-15 for L1/L2 cachen" Og så er vi ikke enige om mere. "Det er med andre ord noget løgnagtig pjat at påstå, HT hastigheden samt hukommelses frekvensen har nogen som helst påvirkning på behovet for cache." den effektive bushastighed og hukommelses hastigheden(rettelse) - men bevis det
--

#35 HT bruges slet ikke til at kommunikere med rammen, med mindre man har et dual/quad cpu bundkort og en cpu skal tilgå hukommelsen tilknyttet den anden cpu. Det er de færreste hjemmepc'ere der har 2 cpu'er. Og ja, cpuen cacher det den har læst ind fra ram for at undgå at skulle læse det ind en gang til. Men omvendt vil cpuen også forsøge at læse data ind fra ram før den får brug for det. Dette er prefetch. Cpuen kan dog ikke læse mere data ind end der er cache tilrådighed. Hukommelsesfrekvensen (båndbredden) er også en begrænsende faktor idet jo lavere båndbredde, desto mindre data er der tid til at prefetche. Så cpuen både henter data selv aktivt, men også i baggrunden via prefetch. Prefetch sløver på ingen måde cpuen hvis ellers cpuen kan overleve alene på cachen imens prefetch foregår. Derfor koster det ofte (afhængig af kvaliteten af prefetcheren) kun cache latency at tilgå mainhukommelse (ram) man ikke har tilgået tidligere.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#37 Dig er jeg enig med:) Men undtagelse måske af et par clock cykels, men ellers ja:)
--

#37 Det kommer meget anden på om prefetch'en arbejder uafhængit af selve cpu'en og det ved jeg ikke:) Rart at se en der er så meget inde i det:)
--

#37 endelig en der ved noget om uProcessor arkitektur!
--
The silence after a storm!...Plextor has spoken

#40 Ja sjællent man ser nogen på nettet som rigtigt ved noget, må håbe vi høre mere til Galmok:)
--
Mvh. Dnope(Passwordet er blevet ændret på: http://hol.dk[...] ) Jeg handler ikke hos SHG og Topdata.

#36 hvorfor skal du ikke bevise dine udsagn? der er jo ikke meget diskusion i bare at komme med en "bevis det"... ud over det så mener jeg at CK har ret.... en anden lille ting... prøv at måle afstanden fra den fjerneste ramklods til cpu'en. find ud af hvor hurtigt elektroner bevæger sig i kobber. så burde man finde ud af at hastighed på rammen, ikke betyder en flyvende fis... så længe vi snakker de små mængder der kan være i cpu'ens cache.. har prøvet at regne lidt på det, er ca tal.. men fasit ville blive højere hvis alle tal var de rigtige: lysets hastighed ca: 300e6 m/sek afstanden til den fjerneste ram blok ca 10cm. cpu'ens hastiged 3GHz så tiden for at komme ud til rammen må være: 10cm/(300e6m/sek) = 333,3e-12s hvis cpu'en kan lave handling per clock cyklus, så tager en cyklus: 1/3GHz = 333,3e-15s så kan vi nu finde ud af hvor mange clock cykler cpu'en med garenti skal vente.. 333,3e-12/333e-15 = 1000 og eftersom dataen skal begge veje, så snakker vi 2000 clock cykler. så... rammens interne hastighed betyder ikke en fis, for der er allerede alt for langt der ud... rammens hastighed er kun interessant, når man skal flytte store mængder data. (ret mig endeligt hvis jeg har lavet en regne bøf :-) )
--

#Dnope så fordi der er en der kan argumentere på CKs niveau og ved noget om hvordan tingene virker er han en guru, mens CK er intetvidende? Yderst subjektiv selektering, for at tilpasse din egen virkelighed! Du fløjter jo let og elefant hen over hans argumenter uden så meget at kommentere dem, med garanti fordi du ikke trumfe dem. Hvis du yderligere ligger mærke til det giver #37 dig ikke ret, han retter blot CK i nogle udtalelser.
--

#42 Hvad mener du en GHz er ? 10^15 s^-1 ? Den er 10^9 s^-1
--

Jeg er allerede (lidt) inde på det i #32 men erkender dog stadig lidt uvidenhed på området ... #35 Nej, nej og atter nej. Sådan fungerer det bare ikke. CPU siger ikke til hukommelsen, at den skal overføre data/instruktioner fra hukommelse til L3 cache, L3 til L2 eller L2 til L1 før den får brug for data. Som også 37 korrigere (jeg skulle ellers lige til at spørge dig om hvad du mente prefetch betød inden jeg læste #37) #36 Alt det ved jeg godt. Så ved du også ting, som er forkerte og alligevel giver du #37 ret i sine rettelser. ----------------------------------------- Men fortsat fra #32 så ville det jo være enkelt at planlægge hvilke data man skulle cache, hvis programmet var en lang snor. Problemet er bare, at programmer indholder branches (i forbindelse med if og while). På assembler-niveau kan man få noget ala cmp ecx, addr jne somewhere Typisk kan somewhere ligge lige i nærheden og så er der ingen problemer, men hvis somewhere ligger langt så bliver man nødt til at gætte på hvilke instruktioner man skal gøre klar til. Det er det, der kaldes branch-prediction. Man har systemer, der gætter rigtigt i ca 90%+ af tilfældene... Som jeg forstår det kan man endda finde på at udføre instruktionerne med mulighed for at gå tilbage. (Jeg vil dog ikke helt hænges op på det). Dvs en program counter er ikke helt hvad den var i gamle dage, hvor man var nået til præcis den instruktion uden at vide hvad der skulle ske bagefter. #43 Hvad med at byde ind med noget fornuftigt ? Når CK tager fejl (som her) skælder du ikke ud, og det behøver du vel heller ikke gøre i andre tilfælde.
--

#42 hvorfor skal du ikke bevise dine udsagn? der er jo ikke meget diskusion i bare at komme med en "bevis det"... Hvorfor skulle han ikke det - kan da ikke være mig der skal bevise det hver gang:) Tit udtaler han sig jo om noget han ikke har ret i uden beviser.
--
Mvh. Dnope(Passwordet er blevet ændret på: http://hol.dk[...] ) Jeg handler ikke hos SHG og Topdata.

#45 Ja, for lige meget om det tager lad os sige 50 clockcykels før rammens data kommer hen til selve cpu'en(Hvis data køre direkte til cpu'en, uden at ligge og vente i cache først), så skal de data hentes fra rammen før eller siden alligevel og jo hurtigere jo bedre. Jeg er det ude hvor jeg ikke har forstand på det - Men prefetch er måske ikke en del af 'selve' cpu/FPU/Memmory contorller osv.. Men forvirringen kan nemt blive stor for er cpu'en hele den klods der sidder i bundkortet eller er den en del af det der sidder inden i:)
--

Fortsættelse til #45 Problemerne opstår så hvis man gættede forkert i branch-prediction .... måske har man ikke engang instruktionen man skulle have end ikke i cache. (Derudover kan man også komme ud for at man kalder en fast adresse, f.eks vha en funktionspointer)
--

#47 Tilføjelse: Ja, jeg ved godt at CPU'en er den del af kernen... Men ja.. Håber du forstår hvad jeg mener - Det er ret blandet om vi snakker om CPU'en eller CPU'en.... og det gør det bestemt ikke bedre jeg tit lige læser hurtigt hen over en text:P
--

#44 ahh ja, selvfølgelig... der var så en fejl.... men googlede lidt og fandt frem til elektroners hastighed i kobber http://www.hamacher.dk[...] som åbenbart er markant lavere end lysets hastighed, hvis vi går udfra at tallene er rigtige kan man lige prøve at regne lidt igen. EDIT: fejl i hastigheden, kommer med en rettelse senere!!! elektroners hastighed i kobber: 7.4e-5 m/sek afstanden til den fjerneste ram blok ca 10cm. cpu'ens hastiged 3GHz så tiden for at komme ud til rammen må være: 10cm/(m/7.4e-5 m/sek) = 135.2e-9s hvis cpu'en kan lave handling per clock cyklus, så tager en cyklus: 1/3GHz = 333e-12 så kan vi nu finde ud af hvor mange clock cykler cpu'en med garenti skal vente.. 135.2e-9/333e-12 = 405 og eftersom dataen skal begge veje, så snakker vi min 810 clock cykler. et bedre tal, men stadig lidt højt.
--

#50 Heinrich måske har du ret( gider ikke regne det efter) Men det er helt normalt at bare det at udføre en kommando i cpu tager over 5 clock cykler(Var det i game dage i alle fald:P Så selvom vi snakker 800 clock cykler er det stadigt ikke så lang tid, og når rammen først er begyndt at overføre så stopper den jo ikke igen før den skal. 1000 clock cykels er på en 3ghz cpu 1/3000000 sekundt og det er jo ikke ret lang tid - i den tid skal der ikke så meget cache til for at cpu'en har noget at arbejde med, og efter den tid er gået kommer data jo 'væltende' ind til cpu'en(Cachen... ja... :)
--
Mvh. Dnope(Passwordet er blevet ændret på: http://hol.dk[...] ) Jeg handler ikke hos SHG og Topdata.

#50 Har ikke checket regnestykket men du skal ikke have lov til at redde selvmålet ;) Strømens hastighed er ca 2/3 af lysets: http://en.wikipedia.org[...] :P Men cache-miss er stadig dyre, men hurtigere ram hjælper både ved prefetch og ved cache-miss, men omkostningen er under alle omstændigheder stor ved cache-miss ... dog skal man normalt ikke smide alt for mange penge i rammen ...
--

udbredelseshastigheden på print er ca. 210,000,000 m/s, og regnestykket giver 1,43 clock cycluser for de 10 cm ved en 3GHz processor. Så det er med andre ord slet ikke her flaskehalsen optræder. Men prøv at sammenligne med access-time på RAM, så snakker vi *mange* cycles før der sker noget - cycles hvor processoren står og laver ingenting. Det giver sig selv at hvis du ingen cache har, så skal du vente ved hver eneste instruktion du skal udføre. Med en cache reduceres denne tid, hvis data ligger i cachen, og det gør de ofte, for når man henter ind i cachen henter man en hel linie af gangen (typisk 16-64 byte, semi-tilfældigt fordelt omkring den pågældende addresse). Det giver også sig selv at ligegyldigt hvilken båndbredde du har på dine ram, så er tiden det tager at læse en cache-line ind (vi snakker kun 16-64byte) ikke domineret af læse-tiden, men af access-tiden. Det er det CK forsøger at forklare.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#53 Nu korrigerede jeg i #52, men samtidig er det ikke det jeg læser CK forklare. Det CK skriver (og som er rigtigt) er at hurtig ram kan ikke erstatte cache. Men faktisk er en af grundene til at man ofte ikke behøver hurtig ram er at CPU'en finder ud af hvad den skal bruge (eller prøver at finde ud af hvad den skal bruge) på forkant. (Det man kalder 'rettidig omhu'). Derved hjælper hurtig ram kun a) når der kommer cache-miss b) hvis et program bruger rammen så intenst at den ikke kan følge med og der derfor ikke er tid til forberedelse. Typisk ligger spil 'ikke' i kategori b, og som CK er inde på koster cache-miss i forvejen dyrt. Dog reducerer hurtig ram dog stadig denne store omkostning. (Ikke at den indhenter i for vejen tabte cykler) I forhold til ram-priser vil jeg dog ikke tale mod Dnopes 8500CL5 (til Phenom II).
--

#37 Galmok ”HT bruges slet ikke til at kommunikere med rammen” Korrekt, men det er lidt ligegyldigt, da adgangen til hukommelsen er defineret af HT hastigheden. AMD har nemlig siden deres Hammer arkitektur blev introduceret fastsat frekvensen til hukommelsen efter northbridgen, som er et resultat af HT hastigheden. Så når vi snakker om frekvensen til hukommelsen, er HT frekvensen altså relevant. ”Så cpuen både henter data selv aktivt, men også i baggrunden via prefetch.” Jo jo, men hvad er udgangspunktet? Det er netop at vi er i en situation, hvor hastigheden til hukommelsen bliver stillet overfor behovet for cache, og dermed bliver straffet for IKKE at have instruktionerne/dataen lokalt. Vi kan altså ikke bruge cache logikken (hverken proaktivt eller tidligere gemt data – sidstnævnte har vi udelukket i situationen og førstnævnte var der ikke plads til grundet cache vs. frekvens eksemplet), så udgangspunktet er derfor at CPU'en skal hente det fra hukommelsen. #47 + 51 Dnope2 ”for lige meget om det tager lad os sige 50 clockcykels før rammens data kommer hen til selve cpu'en(Hvis data køre direkte til cpu'en, uden at ligge og vente i cache først), så skal de data hentes fra rammen før eller siden alligevel og jo hurtigere jo bedre.” ”Så selvom vi snakker 800 clock cykler er det stadigt ikke så lang tid...” Suk, nu tager det hverken 50 eller 800 clock cyklusser at tilgå hukommelsen, og at du benytter to så vidt forskellige tal for samme situation i to efterfølgende indlæg beviser blot, at du bare skriver for at irritere og lave lidt sjov med andre, men for endnu en gang at ignorere dit forsøg på at lave ravage samt tage pis på andre, og i stedet tage dit indlæg seriøst, så er de 50 clock cyklusser du nævner på ingen måde sigende for hukommelsen. Det er nærmere sigende for L3 cachen, som ligger indenfor denne ramme. System hukommelsen ligger og svinger omkring de 100 clock cyklusser. ”...og når rammen først er begyndt at overføre så stopper den jo ikke igen før den skal.” Det er en stor misforståelse. Størstedelen af tiden arbejder CPU'en med forskellige opgaver, og ikke i situationer, hvor den kontinuerligt henter en sammenhængende mængde data. Evnen til sekventielt at hente og udregne instruktion/data er CPU'ens største styrke, og dette afspejler sig naturligvis af brugen (skal nok undlade at tage GPU'en ind her, men den arbejder lige modsat: store mængder data som ”streames”, parallelitet og båndbredde frem for ventetid). Dvs. i langt de fleste situationer, vil den ikke fortsætte uhindret efter den har ventet 90-120 clock cyklusser på hukommelsen, da den skal i gang med en ny opgave. Tankegangen er dog for en gang skyld naturlig nok, og kan for så vidt også forekomme, men det er mere undtagelsen, som bekræfter reglen, da CPU'en som regel ikke streamer store mængder data fra hukommelsen, men i stedet har brug for lyn hurtig adgang til hukommelsen fordelt over mange uafhængige filer. Det er netop derfor, at vi ikke ser nogen nævneværdig forbedring når Core i7 benytter sine 3 memory controllere kontra 2 (+50% ekstra båndbredde) samt at AMD ikke rigtig høster noget ved skiftet til DDR3 (samme er og var desuden gældende for Intel skulle man være i tvivl). Den ekstra båndbredde er ikke så vigtig, og ret ligegyldig på desktop markedet, da CPU'en er mere afhængig af ventetiden – og specielt på desktop markedet. Anyway når den har ventet 90-120 clock cyklusser på en given instruktion/data, går den som udgangspunkt tilbage til nulpunktet, og ikke videre fra fra Crysis-hukommelsesdata1 til Crysis-hukommelsesdata2 uden ventetid. CPU'en skal vide det på forhånd, den fortsætter ikke bare når den har fået fat i en given data/instruktion. Husk på, at den hele tiden henter data i hukommelsen. Hvis den har brug for en ekstra data/instruktion fra hukommelsen efter den første request, skal den altså enten vente igen eller være i en situation, hvor der i koden er taget højde for dette, så CPU'en nemmere kan gætte sig til dette mønster og dermed forberede den. Det er derfor, at cachen er så vigtig - ikke mindst at holde ventetiden nede samt forbedre CPU'ens branch prediction trods den i forvejen ligger på 99+%. Det er netop derfor, at det er noget forkvaklet vrøvl at påstå, at HT frekvensen samt hukommelsen har nogen som helst betydning for cache behovet!
--

Sidst redigeret

#55 "Suk, nu tager det hverken 50 eller 800 clock cyklusser at tilgå hukommelsen, og at du benytter to så vidt forskellige tal for samme situation i to efterfølgende indlæg beviser blot, at du bare skriver for at irritere og lave lidt sjov med andre, men for endnu en gang at ignorere dit forsøg på at lave ravage samt tage pis på andre, og i stedet tage dit indlæg seriøst, så er de 50 clock cyklusser du nævner på ingen måde sigende for hukommelsen. Det er nærmere sigende for L3 cachen, som ligger indenfor denne ramme. System hukommelsen ligger og svinger omkring de 100 clock cyklusser." Det er muligt det ligger og svinger omkring de 100 Clock cyklusser, aner det ikke. "Det er netop derfor, at det er noget forkvaklet vrøvl at påstå, at HT frekvensen samt hukommelsen har nogen som helst betydning for cache behovet!" Hvem har snakket om HT frekvensen? ligger du ord i folks mund igen, eller er det bare en simpel løgn?:) En der ikke kender mig sagde til mig i forbindelse med crucial-kid, når de tager fejl skal du ikke være for hård ved dem, værd over for dem som du vil ha' de er over for dig... Jeg svarede at jeg altid forsøger at være over for andre som jeg vil ha' de skal være over for mig selv... Men bare roligt, Crucial-kid indrømmer aldrig han tager fejl - Prøv at tjække trådene... :) En ting er en masse teorier.. Jeg ved sådan nogenlunde hvordan det fungere i teorien - Men! Her er vi ude hvor jeg ikke kan begynde at gå i detaljer, da jeg ikke ved nok om emnet - Dog ved jeg hvad der sker i praksis og så kan du jo snakke herfra og ind i næste år... god fornøjelse:) Dog! Lad være med at lyve om folk eller putte ord i deres mund, så skriver jeg igen at du muligvis er bevist om du lyver og det er med god grund:)
--

"Hvem har snakket om HT frekvensen?" Ser vi bort fra de utallige af gange, hvor du har fremhævet HT frekvensen som en counter til intel's cache, så kunne vi da prøve med et indlæg i denne tråd: "I7 og Phenom arbejder meget på samme måde - Der er ikke behov for mere cache:) Jo højere bus hastighed, og jo hurtigere ram = desto lavere behov for cache. Både I7, og Phenom har en effektiv bushastighed som er højere end cpu'ens hastighed." Skal vi så ændre dette til, at bushastigheden er noget helt tredje, og endnu mere vanvittigt for at få ideen om, at system båndbredden og hukommelsesfrekvensen reducerer behovet for cachen, kan gå op? Prøv at læs den sætning du har skrevet der. Enhver kan jo se, at det er nonsens skrevet for at fjerne fokus fra en af Core 2's styrker. Større RAM båndbredde og hurtigere svartid fra system hukommelsen har reelt ingen effekt kontra behovet for cache. Det har i stedet cachens opbygning.
--
Mvh. Thomas Christensen

#55: Korrekt, men det er lidt ligegyldigt, da adgangen til hukommelsen er defineret af HT hastigheden. Hovedclocken i cpuen ganges op med en faktor for at give den ønskede hypertransport clock. Hovedclocken ganges også op med en (anden) factor for at given den ønskede cpu hastighed. Memory controller clocken fås ved at dividere cpu clock med en faktor. HT, CPU og MEM clocks kan altså ændres i forhold til hinanden (dog med visse begrænsninger). AMD har nemlig siden deres Hammer arkitektur blev introduceret fastsat frekvensen til hukommelsen efter northbridgen, som er et resultat af HT hastigheden. Northbridge? Hvad har den med hukommelsen at gøre? AMD64 snakker direkte med hukommelsen, det kan jeg næsten ikke tro andet end at du ved. Frekvensen opstår som jeg skrev den lige ovenfor. Det er de Intel cpuer der snakker til hukommelsen gennem northbridgen (dog ikke I7).
--
Gæstebruger, opret dit eget login og få din egen signatur.

#57 Crucial jeg kan og vil ikke gå ind i en diskusion om det her emne, af den simple grund jeg ikke ved nok om det. Min udtagelse er begrundet i oplevelser med de computere jeg har haft fat i gennem tiden - Samt noget viden som jeg har som baggrund selvfølge.. Den første computer jeg oplevede rammens betydning på var på en celeron med 128mb cache - Hurtig RAM(høj mhz + lav cl) sammen med en ok effektiv bushastighed kan absolut ikke erstatte cache, men det kan åbenbart hjælpe på problemerne som kommer på grund at den lave cache. Du kan prøve, du vil sikkert få samme resultat som mig - Så kan vi så ha' noget viden + en masse teorier om det.
--

#59 hvorfor have teorier, når man kan vide?
--
//Ewowa brug Piratebay inden den dør.

#60 Jeg vil helst heller ikke ha' teorier:) Jeg har så valgt at sige jeg ikke ved nok om det til at forklare det 100% og det er af den simple grund at det er så avanceret et emne, at det ikke er noget man bare lige kan læse sig frem til på et par timer, selvom man har en del viden i forevejen. Men hvis andre vil vide hvad der præsist sker, så er de velkommen til at gå i gang - Bare prefetch'eren er en kompliceret del af det, som i sig selv vil tage lang tid at sætte sig ordentligt ind i og som Galmok er inde på er der foreskel på kvaliteten af prefetch'eren(Hvilket jeg vælger at tro på) og det gør det bare endnu mere beværligt at skulle lære alt om netop den der sidder i Phenom, Core2duo og I7 - Hvis man overhovedet kan få de oplysninger, det tvivler jeg på man kan.
--

Jeg forstår ikke rigtigt hvad formålet med diskussionen er længere... anyways, er der nogen der ved hvornår man kan få de her processorer. Jeg står og skal lave et par computere og ville egentlig gerne have et par X3'ere i dem, men går der flere uger inden de bliver tilgængelige?
--
Gæstebruger, opret dit eget login og få din egen signatur.

#62 http://www.compumail.dk[...]
--
Mvh. Dnope(Passwordet er blevet ændret på: http://hol.dk[...] ) Jeg handler ikke hos SHG og Topdata.

De nye AM3 modeller clocker også lidt bedre end de gamle. Her lidt aktuelt 3dmark06 WR: http://www.xtremesystems.org[...]
--

Ja, som #63 viser, skulle de komme til Danmark i næste uge, jeg har set dem flere steder, sat til at komme på lager omkring d. 23. til 26. februar. Desuden har jeg fundet et par shops i England, der allerede har dem på lager, desværre ville de ikke sende dem udenlands.
--
http://www.flamewars.dk[...]

hvornår kommer de store 4 kernet modeller til am3?? så kunne det være man skulle have ny cpu
--
Bundkort: ASrock A780G CPU: AMD X4 9850 Black Edition 2.5GHz @ 2.9GHz Grafikkort: Sapphire Radeon HD 4870 512 GDDR5 RAM: A-Data 2x2GB+2*1 800 MHz