Test: Tanken og designet bag Quadcore
HT Exclusive d. 18. oktober. 2007, skrevet af red_martians 13 Kommentarer. Vist: 10359 gange.
Korrekturlæser:
Billed behandling:
Oversættelse:
Pristjek på http://www.pricerunner.dk
Produkt udlånt af: Highpoint
DK distributør: Highpoint
Billed behandling:
Oversættelse:
Pristjek på http://www.pricerunner.dk
Produkt udlånt af: Highpoint
DK distributør: Highpoint
#1
God læsning. Så får man lidt mere styr på hvad der ligger bag alt det med Quadcore og Dualcore.
#2
Super at få det teori på plads 🙂
Nogle tager en avis til morgen maden, jeg tager hwt 😀
AMD's systemer er godt nok noget mere gennemtænkt 😲 Så jeg begynder at tro, at AMD kommer på banen igen, og begynder at nakke Intel..... igen 🙂 Dog ville jeg gerne se noget mere cache på den Barcelona :yes:
Nogle tager en avis til morgen maden, jeg tager hwt 😀
AMD's systemer er godt nok noget mere gennemtænkt 😲 Så jeg begynder at tro, at AMD kommer på banen igen, og begynder at nakke Intel..... igen 🙂 Dog ville jeg gerne se noget mere cache på den Barcelona :yes:
#3
Hej
jeg syntes da det er interesandt læsning men syntes faktisk ikke at du siger hvad der er kan svare sig. Du starter artiklen med fup eller fakta, og jeg kunne godt lide at vide om det kan svare sig at købe duel eller qadro til css foreksempel ??.
Hilsen mad79
:yes: :yes: :yes:
jeg syntes da det er interesandt læsning men syntes faktisk ikke at du siger hvad der er kan svare sig. Du starter artiklen med fup eller fakta, og jeg kunne godt lide at vide om det kan svare sig at købe duel eller qadro til css foreksempel ??.
Hilsen mad79
:yes: :yes: :yes:
#4
Meget pædagorist skrevet artikle, men desværre har nogle fejl.
"Intil for et par år siden var det singlecore der var dominerende og den letteste måde at skyde hastigheden i vejret på, var at lægge mere og mere intern hukommelse ind i processoren. "
- Tildels rigtigt, men forøgelsen af cache lå mest i problemet med Intel's Netburst arkitektur, bedre kendt som Pentium4.
Pentium4 blev lavet med et væsentligt formål at opnå så høje frekvenser som muligt, for at opnå en PR mæssig fordel ved at præsentere en processor med en frekvens langt over andre.
Problemmet med dette lå i at cachen havde problemmer med at holde trit med processorens frekvens, her betød mængden af cache meget for Pentium4, mens Athlon64, som arbejdede med en lavere frekvens, ikke havde samme store behov.
"Fidusen er, at med den interne hukommelse behøver processoren ikke at hente data på ram, og skal sjældnere arbejde med flaskehalse der nedsætter systemets samlede ydelse."
-Cachen søger sine data i RAM'ene, ligesom RAM'ene søger sine data i harddisken. Spørgsmålet ligger i om hvormeget man skal have fx. af cachen, således at cachen kan holde sig selv fyldt op med de data som processoren skal bruge om et øjeblik. Er et dynamisk forhold mellem processoren og RAM'ene, som cachen prøver at holde trit med, så de undgår kontakt.
Selvfølgelig kan der bare smækkes en masse cache på processoren, men med kampen mellem AMD og Intel handler det hele om optimering. Det handler derfor at lave en cache der søger for at der hele tiden er de data der skal bruges snart af processoren, så RAM'ene undgås, samt at søger for at holde mængden af den så lav som muligt.
"Den var i tidernes morgen meget lille, da den fylder uhyggelig meget, og dermed gør processoren dyr at producere. "
-ikke helt uddybende :D ser man på tingene, så er cache og RAM det samme. Forskellen på de to er hvordan den interne hukommelse er opbygget på. Cache er baseret på det der hedder SRAM, Static RAM og de almindelig RAM er bygget på DRAM, Dynamisk RAM. Simpelt forklaret har SRAM den fordel at de er flere gange hurtigere internt og reagerer hurtigere end DRAM, men har den ulempe at produktionsomkostingerne er væsentligt højere.
Siden cachen skal reagere asp på processorens ordre, så er det her SRAM anvendes.
"Så hvad er problemet med singlecore? Reelt ikke meget, men den kan kun tackle en problemstiling, en beregning eller et program ad gangen."
-Er så direkte forkert, det var engang sådan, men er mange mange år tilbage.
Processoren er baseret på det der hedder pipelines, kan ses lidt ligesom en trappe data og dets instruktion(er) går ned af (instruktioner fortæller processoren hvad der skal ske med den gældende data). Den grundlæggende opbygning er en 4 trins pipeline arktitektur, som hedder: Fetch (henter data+instruktioner), Decode (laver det hele om til noget der er spiseligt for processoren), Execute (udføre en handling på data efter hvad instruktionen siger) og Write (skriver resultatet tilbage til RAM'ene). Disse 4-trin er så blevet udvidet igennem tiden til idag, hvor man har omkring 12-15 trin.
Holder vi os til 4-trins modellen, så kan en processor hente data fra et program, mens det decoder data fra et andet og executer fra et helt tredje.
Med Dualcore er det dog muligt at havde 2 forskellige programmer på samme trin og med quad, fire.
Skal vi være helt beviste omkring singlecore, så kunne Pentium4 udføre to programmer samtidigt i hvert trin med sin Hyperthreating, men er ikke blevet anvendt siden, da det var en lappe løsning på netburst's dårlige opbygning.
"Intil for et par år siden var det singlecore der var dominerende og den letteste måde at skyde hastigheden i vejret på, var at lægge mere og mere intern hukommelse ind i processoren. "
- Tildels rigtigt, men forøgelsen af cache lå mest i problemet med Intel's Netburst arkitektur, bedre kendt som Pentium4.
Pentium4 blev lavet med et væsentligt formål at opnå så høje frekvenser som muligt, for at opnå en PR mæssig fordel ved at præsentere en processor med en frekvens langt over andre.
Problemmet med dette lå i at cachen havde problemmer med at holde trit med processorens frekvens, her betød mængden af cache meget for Pentium4, mens Athlon64, som arbejdede med en lavere frekvens, ikke havde samme store behov.
"Fidusen er, at med den interne hukommelse behøver processoren ikke at hente data på ram, og skal sjældnere arbejde med flaskehalse der nedsætter systemets samlede ydelse."
-Cachen søger sine data i RAM'ene, ligesom RAM'ene søger sine data i harddisken. Spørgsmålet ligger i om hvormeget man skal have fx. af cachen, således at cachen kan holde sig selv fyldt op med de data som processoren skal bruge om et øjeblik. Er et dynamisk forhold mellem processoren og RAM'ene, som cachen prøver at holde trit med, så de undgår kontakt.
Selvfølgelig kan der bare smækkes en masse cache på processoren, men med kampen mellem AMD og Intel handler det hele om optimering. Det handler derfor at lave en cache der søger for at der hele tiden er de data der skal bruges snart af processoren, så RAM'ene undgås, samt at søger for at holde mængden af den så lav som muligt.
"Den var i tidernes morgen meget lille, da den fylder uhyggelig meget, og dermed gør processoren dyr at producere. "
-ikke helt uddybende :D ser man på tingene, så er cache og RAM det samme. Forskellen på de to er hvordan den interne hukommelse er opbygget på. Cache er baseret på det der hedder SRAM, Static RAM og de almindelig RAM er bygget på DRAM, Dynamisk RAM. Simpelt forklaret har SRAM den fordel at de er flere gange hurtigere internt og reagerer hurtigere end DRAM, men har den ulempe at produktionsomkostingerne er væsentligt højere.
Siden cachen skal reagere asp på processorens ordre, så er det her SRAM anvendes.
"Så hvad er problemet med singlecore? Reelt ikke meget, men den kan kun tackle en problemstiling, en beregning eller et program ad gangen."
-Er så direkte forkert, det var engang sådan, men er mange mange år tilbage.
Processoren er baseret på det der hedder pipelines, kan ses lidt ligesom en trappe data og dets instruktion(er) går ned af (instruktioner fortæller processoren hvad der skal ske med den gældende data). Den grundlæggende opbygning er en 4 trins pipeline arktitektur, som hedder: Fetch (henter data+instruktioner), Decode (laver det hele om til noget der er spiseligt for processoren), Execute (udføre en handling på data efter hvad instruktionen siger) og Write (skriver resultatet tilbage til RAM'ene). Disse 4-trin er så blevet udvidet igennem tiden til idag, hvor man har omkring 12-15 trin.
Holder vi os til 4-trins modellen, så kan en processor hente data fra et program, mens det decoder data fra et andet og executer fra et helt tredje.
Med Dualcore er det dog muligt at havde 2 forskellige programmer på samme trin og med quad, fire.
Skal vi være helt beviste omkring singlecore, så kunne Pentium4 udføre to programmer samtidigt i hvert trin med sin Hyperthreating, men er ikke blevet anvendt siden, da det var en lappe løsning på netburst's dårlige opbygning.
#5
#4 Hvorfor skriver du ikke gæsteartikler? Eller det gør du måske også?
#6
Vil nu mene at red_martians har fat i den lange ende mht. cachen. Rent fysisk er det vel samme silicium/transistorer/gates, som cachen er bygget op af og jeg kan derfor ikke se hvorfor, at cachen på nogen måde ikke skulle kunne køre med samme frekvens. Det skulle da lige være, hvis man rent faktisk sparer ved at bruge en produktionsmæssigt billigere teknologi til at lave cachen, så denne ikke er i stand til at køre samme hastigheder.
Det er typisk andre steder problemerne opstår ved øget frekvens (EMC, effekttab, timings osv.). Derfor er den lette løsning mere cache, idet man derved kan undgå flere kald til RAM eller harddisken. Næst kommer optimering af udnyttelsen af cachen. Begge løsninger er noget, som Intel har udnyttet ganske voldsomt med Core 2, netop fordi tiden er ved at løbe fra den gamle arkitektur med FSB og memory controller i chipsættet. Intel skal til gengæld have ros for at have gjort deres cache så effektiv, som den er og mængden af den ser ikke ud til at haft den store betydning for priserne (selv om DRAM er billigere at producere). På sin vis stadig mindre vigtigt, da pointen bare var, at cache er hurtigere end DRAM men også dyrere.
Mht. multitasking og pipelining, så er pipelining ikke det samme som multitasking. Der er stadig kun én ALU til rådighed (i en single core processor) og dermed kan processoren, uanset pipelining, kun regne på én ting af gangen. Pipelining forøger bare udnyttelsen af ALU'en og det samme gør sig gældende for HyperThreading - det er bare en smart måde at udnytte en ellers ineffektiv pipeline (og ikke en måde at udføre to beregninger samtidigt).
Det er typisk andre steder problemerne opstår ved øget frekvens (EMC, effekttab, timings osv.). Derfor er den lette løsning mere cache, idet man derved kan undgå flere kald til RAM eller harddisken. Næst kommer optimering af udnyttelsen af cachen. Begge løsninger er noget, som Intel har udnyttet ganske voldsomt med Core 2, netop fordi tiden er ved at løbe fra den gamle arkitektur med FSB og memory controller i chipsættet. Intel skal til gengæld have ros for at have gjort deres cache så effektiv, som den er og mængden af den ser ikke ud til at haft den store betydning for priserne (selv om DRAM er billigere at producere). På sin vis stadig mindre vigtigt, da pointen bare var, at cache er hurtigere end DRAM men også dyrere.
Mht. multitasking og pipelining, så er pipelining ikke det samme som multitasking. Der er stadig kun én ALU til rådighed (i en single core processor) og dermed kan processoren, uanset pipelining, kun regne på én ting af gangen. Pipelining forøger bare udnyttelsen af ALU'en og det samme gør sig gældende for HyperThreading - det er bare en smart måde at udnytte en ellers ineffektiv pipeline (og ikke en måde at udføre to beregninger samtidigt).
#7
Woodgnome ->
Kan ikke lige se hvor i min tekst dit kommentar angående cache kommer fra, kunne du evt. uddybe hvori denne kommentar opstod, ved kke om du har misforstået hvad jeg skrev angående det eller mig der har formuleret mig forkert.
Effekttab og timings hænder self når frekvensen hives i vejret, men Pentium4 var et ekstremt tilfælde når det gælder frekvensforøgelse, til dato er ingen processor overhovedet i nærheden af de 32 pipelines, som Pentium4 havde tilsidst. Endte også med et hvis effekttab, men selve arkitekturen ag Pentium4 betød at den satte et kraftigt pres på cachen i at følge med processoren.
Jeg mener på ingen måde at DRAM kan udfordre SRAM når det gælder cache, mere forklare hvad cache egentlig er, da det navn ikke fortæller hele sandheden om dets oprindelse.
Det sidste du skrev indeholder dog nogle fejl.
Pipelining og multitasking er ikke det samme, ja, men betyder stadig ikke at processoren kun kan lave en ting ad gangen, se hvad jeg svare på.
At en singlecore processor kun har en ALU er også noget der ligger mange mange år tilbage, nyere processor som fx Athlon64 og Pentium4 betår af flere ALU'er. Antallet af ALU definere en processors "bredde" dvs. hvor meget data den kan bearbejde simultant (samtidigt).
Processoren fungere ved ooo execution - out of order exection, dette sat sammen med register renaming og re-order buffer etc. fungere tingene som en gang tetris, hvor processoren prøver så vidt muligt at fylde en linie helt ud, således den bruger alle sine ALU'er samtidigt.
Hyperthreading opstod af Pentium4's problematiske arkitektur, frekvensen på processoren var så høj at processorne ikke kunne nå at sætte data'erne ordentligt sammen (super hurtig turbo tetris :D ). Kort sagt så udnytter den virtuelle processor i Hyperthreading de ALU'er, som processoren ikke selv kunne. Så begge processorer kan regne på samme tid, med hver sine ALU'er. (Udføre to beregninger samtidigt)
Samtidig er pipelining ikke en forøgelse af ALU'en udnyttelse, men en generel forøgelse af en processors effektivitet ved at lade processoren fungere som et samlebånd med hver sin del enhed, som kaldes trin.
Kan ikke lige se hvor i min tekst dit kommentar angående cache kommer fra, kunne du evt. uddybe hvori denne kommentar opstod, ved kke om du har misforstået hvad jeg skrev angående det eller mig der har formuleret mig forkert.
Effekttab og timings hænder self når frekvensen hives i vejret, men Pentium4 var et ekstremt tilfælde når det gælder frekvensforøgelse, til dato er ingen processor overhovedet i nærheden af de 32 pipelines, som Pentium4 havde tilsidst. Endte også med et hvis effekttab, men selve arkitekturen ag Pentium4 betød at den satte et kraftigt pres på cachen i at følge med processoren.
Jeg mener på ingen måde at DRAM kan udfordre SRAM når det gælder cache, mere forklare hvad cache egentlig er, da det navn ikke fortæller hele sandheden om dets oprindelse.
Det sidste du skrev indeholder dog nogle fejl.
Pipelining og multitasking er ikke det samme, ja, men betyder stadig ikke at processoren kun kan lave en ting ad gangen, se hvad jeg svare på.
At en singlecore processor kun har en ALU er også noget der ligger mange mange år tilbage, nyere processor som fx Athlon64 og Pentium4 betår af flere ALU'er. Antallet af ALU definere en processors "bredde" dvs. hvor meget data den kan bearbejde simultant (samtidigt).
Processoren fungere ved ooo execution - out of order exection, dette sat sammen med register renaming og re-order buffer etc. fungere tingene som en gang tetris, hvor processoren prøver så vidt muligt at fylde en linie helt ud, således den bruger alle sine ALU'er samtidigt.
Hyperthreading opstod af Pentium4's problematiske arkitektur, frekvensen på processoren var så høj at processorne ikke kunne nå at sætte data'erne ordentligt sammen (super hurtig turbo tetris :D ). Kort sagt så udnytter den virtuelle processor i Hyperthreading de ALU'er, som processoren ikke selv kunne. Så begge processorer kan regne på samme tid, med hver sine ALU'er. (Udføre to beregninger samtidigt)
Samtidig er pipelining ikke en forøgelse af ALU'en udnyttelse, men en generel forøgelse af en processors effektivitet ved at lade processoren fungere som et samlebånd med hver sin del enhed, som kaldes trin.
#8
Mener bare at du ikke helt har forstået pointen med red_martians artikel. Den er ment til personer, som ikke ved det helt store om processorer - ikke nørden, som godt ved hvad cache er. Hvis det var nørderne artiklen var skrevet til, så var den nok blevet skrevet uden de store forsimplinger - til gengæld ville det blive røvkedelig og uforståelig læsning for nok 9 ud af 10 læsere 🤡
Jeg ved i øvrigt godt hvad både SRAM og DRAM er og er udmærket klar over hvad fordele og ulemper de har - og ved også godt at DRAM ikke har nogen anvendelse som cache til en processor, der kører med clockfrekvenser i GHz området. Til gengæld må du gerne forklare hvad det er, der gør at Netburst sætter så fandens kraftig et pres på cachen?
Mht. ALU'er og multitasking, så er der vel efterhånden mere et spørgsmål om definition. Hvis ikke schedulerne kan fodre ALU'erne eller beregningerner der afvikles er afhængige af de mellemliggende resultaterne, så er der stadig kun én ting der kan regnes på af gangen. Man kan også se på det i forhold til hvor mange tråde der kan afvikles og på en single core processor, så er det én af gangen (medmindre man har HyperThreading). Det samme kan siges om ALU'er og pipelining - om man siger pipelinen sørger for bedre udnyttelse af ALU'en eller forøger processorens ydelse, kan vist komme ud på et...
Problemet med Netburst hænger til gengæld ikke sammen med hastigheden, det hænger sammen med længden af pipelinen. Hver eneste gang der skal laves en branch i maskinkoden, så skal pipelinen tømmes og med 32 stages (eller hvor mange Netburst nu endte med at have), så gør det ondt i ydelse at tømme pipelinen for mange gange. Der findes DSP processorer, hvor maskinkoden tillader, at man kan fylde pipelinen før en branch, således at denne ikke bliver tømt helt for data. Det kræver til gengæld, at man skriver i assembly eller maskinkode og har rimelig godt styr på de beregninger der skal afvikles. Der er bare den lille ting, at man selv indenfor DSP verdenen langt fra altid skriver i lavniveau sprog som assembly og maskinkode...
Men hvad gør man så når man skal vente på at pipelinen skal tømmes? Man laver det, så processoren selv kan finde ud af at fylde den op undervejs uden, at koden behøver at være skrevet specifikt til dette formål. Dermed opnår man den "ekstra kerne effekt". En ganske fantastisk udnyttelse af en ellers meget lang og ineffektiv pipeline (som var nødvendig for at opnå de hastigheder Intel kunne fremvise allerede da).
Jeg ved i øvrigt godt hvad både SRAM og DRAM er og er udmærket klar over hvad fordele og ulemper de har - og ved også godt at DRAM ikke har nogen anvendelse som cache til en processor, der kører med clockfrekvenser i GHz området. Til gengæld må du gerne forklare hvad det er, der gør at Netburst sætter så fandens kraftig et pres på cachen?
Mht. ALU'er og multitasking, så er der vel efterhånden mere et spørgsmål om definition. Hvis ikke schedulerne kan fodre ALU'erne eller beregningerner der afvikles er afhængige af de mellemliggende resultaterne, så er der stadig kun én ting der kan regnes på af gangen. Man kan også se på det i forhold til hvor mange tråde der kan afvikles og på en single core processor, så er det én af gangen (medmindre man har HyperThreading). Det samme kan siges om ALU'er og pipelining - om man siger pipelinen sørger for bedre udnyttelse af ALU'en eller forøger processorens ydelse, kan vist komme ud på et...
Problemet med Netburst hænger til gengæld ikke sammen med hastigheden, det hænger sammen med længden af pipelinen. Hver eneste gang der skal laves en branch i maskinkoden, så skal pipelinen tømmes og med 32 stages (eller hvor mange Netburst nu endte med at have), så gør det ondt i ydelse at tømme pipelinen for mange gange. Der findes DSP processorer, hvor maskinkoden tillader, at man kan fylde pipelinen før en branch, således at denne ikke bliver tømt helt for data. Det kræver til gengæld, at man skriver i assembly eller maskinkode og har rimelig godt styr på de beregninger der skal afvikles. Der er bare den lille ting, at man selv indenfor DSP verdenen langt fra altid skriver i lavniveau sprog som assembly og maskinkode...
Men hvad gør man så når man skal vente på at pipelinen skal tømmes? Man laver det, så processoren selv kan finde ud af at fylde den op undervejs uden, at koden behøver at være skrevet specifikt til dette formål. Dermed opnår man den "ekstra kerne effekt". En ganske fantastisk udnyttelse af en ellers meget lang og ineffektiv pipeline (som var nødvendig for at opnå de hastigheder Intel kunne fremvise allerede da).
#9
At den ikke er skrevet til nørden gør jo formulering jo endnu svære. Er udmærket klar over de vanskeligheder at koge et så stort emne ned i sådan en lille tekst, men betyder også at man skal være meget omhyggelig hvad man skriver og passe på hvilke assosiationer det kan give og synes red_martins har lavet nogle bummerter nogle steder i sin formulering og nogle steder synes jeg at det er endt i rent fejlinformering, fx. som at sige at en singlecore KUN kan regne en ting adgangen.
Hvis man ønsker at holde teksten simple, skulle man have startet med nogle indlende artikler, som kunne give et overordnet overblik over processorens virken.
Du må forstå woodgnome, at AMD's og Intel's processor til mainstream markedet (de almindelig folk) er lavet til at passe vores arbejdsforhold, 3 ALU'er, som de fleste har, er ikke imponerende iforhold til andre processor der sigter på server brug.
En af de problemmer G4 og G5 havde i Apple's computer, da disse var meget bredde iforhold til Intel's og AMD's processorer, hvilket betød at ALU'erne sjældent blev udnyttet så optimalt.
Generelt gør scheduleren et godt arbejde med at optimerer processoren optimalt mht. udnyttelsen af ALU'erne, er jo en grund til at vi kun har set Hyperthreading i Pentium4.
Du må have misforstået noget angående Branch Prediction Woodgnome. I processoren findes der en BPU, Branch Prediction Unit, denne, på basis af forgående resultater, forudsiger hvad udfaldet af en brach bliver og regner med dette udfald ved at hente data+instruktioner for denne.
Dette fungerer oftest også godt, med en succesrate på omkring 94-95%.
Sker der dog det at processoren undervejs finder ud af at den har ramt forkert, så sker der som du nævner, et pipeline flush.
Hvis en processor skulle tømmes hvergang der kom en branch, damn så skulle Pentium4 stå idle ofte :D.
Det der gjorde ondt hos Pentium4 var den "recovery" tid der var ved et pipeline flush, da det tager længere tid for den at komme op i fuld execute rate.
"om man siger pipelinen sørger for bedre udnyttelse af ALU'en eller forøger processorens ydelse, kan vist komme ud på et... "
En lille manupulering af hvad jeg har sagt.
"Samtidig er pipelining ikke en forøgelse af ALU'en udnyttelse, men en generel forøgelse af en processors effektivitet"
Og vil stadig sige der er en forskel, ALU'en er et trin indenfor pipelines og ikke direkte påvirket af pipelining.
Mht. Netburst og L2 cache, så er det fra en gammel artikle jeg læste år tilbage og har ikke haft held med at finde den desværre, så du må nøjes med hvad jeg skriver.
En forøgelse af pipelines betyder at hvert trin i processoren gør mindre, men kan gøre det hurtigere. Dvs. internt i processoren tager det længere tid at færdiggøre data, men udadtil henter og spytter den data ud i et højt tempo. Da der hentes i et højt tempo, så ligger der et pres på cachen for at søger for at der hele tiden er data tilgængeligt for processoren. Ligger egentlig ikke mere i det end det.
Hvis man ønsker at holde teksten simple, skulle man have startet med nogle indlende artikler, som kunne give et overordnet overblik over processorens virken.
Du må forstå woodgnome, at AMD's og Intel's processor til mainstream markedet (de almindelig folk) er lavet til at passe vores arbejdsforhold, 3 ALU'er, som de fleste har, er ikke imponerende iforhold til andre processor der sigter på server brug.
En af de problemmer G4 og G5 havde i Apple's computer, da disse var meget bredde iforhold til Intel's og AMD's processorer, hvilket betød at ALU'erne sjældent blev udnyttet så optimalt.
Generelt gør scheduleren et godt arbejde med at optimerer processoren optimalt mht. udnyttelsen af ALU'erne, er jo en grund til at vi kun har set Hyperthreading i Pentium4.
Du må have misforstået noget angående Branch Prediction Woodgnome. I processoren findes der en BPU, Branch Prediction Unit, denne, på basis af forgående resultater, forudsiger hvad udfaldet af en brach bliver og regner med dette udfald ved at hente data+instruktioner for denne.
Dette fungerer oftest også godt, med en succesrate på omkring 94-95%.
Sker der dog det at processoren undervejs finder ud af at den har ramt forkert, så sker der som du nævner, et pipeline flush.
Hvis en processor skulle tømmes hvergang der kom en branch, damn så skulle Pentium4 stå idle ofte :D.
Det der gjorde ondt hos Pentium4 var den "recovery" tid der var ved et pipeline flush, da det tager længere tid for den at komme op i fuld execute rate.
"om man siger pipelinen sørger for bedre udnyttelse af ALU'en eller forøger processorens ydelse, kan vist komme ud på et... "
En lille manupulering af hvad jeg har sagt.
"Samtidig er pipelining ikke en forøgelse af ALU'en udnyttelse, men en generel forøgelse af en processors effektivitet"
Og vil stadig sige der er en forskel, ALU'en er et trin indenfor pipelines og ikke direkte påvirket af pipelining.
Mht. Netburst og L2 cache, så er det fra en gammel artikle jeg læste år tilbage og har ikke haft held med at finde den desværre, så du må nøjes med hvad jeg skriver.
En forøgelse af pipelines betyder at hvert trin i processoren gør mindre, men kan gøre det hurtigere. Dvs. internt i processoren tager det længere tid at færdiggøre data, men udadtil henter og spytter den data ud i et højt tempo. Da der hentes i et højt tempo, så ligger der et pres på cachen for at søger for at der hele tiden er data tilgængeligt for processoren. Ligger egentlig ikke mere i det end det.
#10
Rigtig god læsning det der :)!
#11
Hehe, da glad for at andre også finder gavn af denne diskution :D
btw.
red_martians, kunne godt ønske mig en kommentar fra dig, da den oprindeligt var rettet mod dig. :)
btw.
red_martians, kunne godt ønske mig en kommentar fra dig, da den oprindeligt var rettet mod dig. :)
#12
#11: Den er skrevet med enkelthed som nøgleord. Så Alle kan forstå hvad forskellen er. Hvis du kan forklare på 2linier hvad forskellen er mellem en dualcore og en singlecore er, så skal jeg da gerne ta' det til efterretning. Men mener at jeg udfra tanken om multitaskning kan beskrive en singlecore som en ensporet processor der tager en ting ad gangen. Jeg tager muligvis fejl, og skal da gerne rette det, men så har jeg misforstået hele konceptet bag en dual/quadcore.
Angående cache, skyldes det ikke kun pentium4, AthlonXP langt det meste af tiden ligeså meget cache som pentium4, og kampen stammer helt fra tiden med pentium3 og K6-2, da man begyndte på intern cache. Idéen er som den altid har vejret at fjerne flaskehalse.
Angående cache og ram... den generelle idé er at cache er en hurtig ram, og ram er langsommere. Så L1->L2->L3->ram-Harddisk er jeg slet ikke uenig i.. grundtanken er hukommelse, bare hurtigere.
Desuden er Hyperthreding blevet udnyttet derefter. Intel har fremvist utallige Core2'ere med HT, og det er bare et spørgsmål om tid før vi ser det i core-processorne. Ligesom med Pentium4 har Core2 det indbygget, bare ikke aktiveret.
Personligt vil jeg gerne undgå alt muligt snak omkring processorens teknik, bare have det grundlæggende på plads så man kan se ideen bag to eller flere kerner.
mvh red_martians
Angående cache, skyldes det ikke kun pentium4, AthlonXP langt det meste af tiden ligeså meget cache som pentium4, og kampen stammer helt fra tiden med pentium3 og K6-2, da man begyndte på intern cache. Idéen er som den altid har vejret at fjerne flaskehalse.
Angående cache og ram... den generelle idé er at cache er en hurtig ram, og ram er langsommere. Så L1->L2->L3->ram-Harddisk er jeg slet ikke uenig i.. grundtanken er hukommelse, bare hurtigere.
Desuden er Hyperthreding blevet udnyttet derefter. Intel har fremvist utallige Core2'ere med HT, og det er bare et spørgsmål om tid før vi ser det i core-processorne. Ligesom med Pentium4 har Core2 det indbygget, bare ikke aktiveret.
Personligt vil jeg gerne undgå alt muligt snak omkring processorens teknik, bare have det grundlæggende på plads så man kan se ideen bag to eller flere kerner.
mvh red_martians
#13
Beklager det sene svar.
Har da heller ikke nogen planer at starte flere diskutioner angående artiklen, har sagt hvad jeg ville. Tænkte bare at en kommentar fra dig ville være en gpd afslutning :D
btw.
din sætning omkring single core er sådan set ok, hvis du bare erstatter "kun" med "ofte".
Har da heller ikke nogen planer at starte flere diskutioner angående artiklen, har sagt hvad jeg ville. Tænkte bare at en kommentar fra dig ville være en gpd afslutning :D
btw.
din sætning omkring single core er sådan set ok, hvis du bare erstatter "kun" med "ofte".