Mentos3
#0
hej...
jeg havde en lille "snak" med min IT lære om 32 og 64bit CPU'er...
jeg havde i et projekt skrevet:
(at en 64bit Cpu "teoretisk" set er dobbelt så hurtig som en 32bit, da den kan arbejde med dobbelt så mange tråde/sek, dette betyder ikke at den givne hastighed(MHz) stiger, men gør ganske simpelt at den kan håntere opgaver bedre og hurtigerer end en 32bit)
efter denne udtalelse, blev min lære særdeles utilfreds med at jeg sad og udtalte mig om ting jeg ikke kendte til..!
og så snakkede han lidt om at den kunne kontrollerer/og arbejde sammen med flere RAM end en 32bit kunne...
så nu vil jeg gerne have en ting at vide.. hvem har ret.. ?:(
og hvis der er nogen tilføjelser må i meget gerne sige frem!
på forhånd tak...
jeg havde en lille "snak" med min IT lære om 32 og 64bit CPU'er...
jeg havde i et projekt skrevet:
(at en 64bit Cpu "teoretisk" set er dobbelt så hurtig som en 32bit, da den kan arbejde med dobbelt så mange tråde/sek, dette betyder ikke at den givne hastighed(MHz) stiger, men gør ganske simpelt at den kan håntere opgaver bedre og hurtigerer end en 32bit)
efter denne udtalelse, blev min lære særdeles utilfreds med at jeg sad og udtalte mig om ting jeg ikke kendte til..!
og så snakkede han lidt om at den kunne kontrollerer/og arbejde sammen med flere RAM end en 32bit kunne...
så nu vil jeg gerne have en ting at vide.. hvem har ret.. ?:(
og hvis der er nogen tilføjelser må i meget gerne sige frem!
på forhånd tak...
#1
Arbejder ikke med flere tråde..
Den tager blot 64bit adgangen istedet for 32bit.. Eller den har mulighed for det.
Den tager blot 64bit adgangen istedet for 32bit.. Eller den har mulighed for det.
#2
Den suger bare dobbelt så mange tal igennem regneprocessen ad gangen - så du har delvist ret. Delvist ret, fordi der er flere komponenter som skal passe sammen med CPU'en og kunne udnytte de samme 64 bit vs 32 bit før ydelsen kommer op hvor den hører hjemme.
#3
okay...
men præsis hvad menes ved "bit" hvad er det en målestok for..?
men præsis hvad menes ved "bit" hvad er det en målestok for..?
#5
Derimod kan du nævne at loftet for max ram er steget markant :P
Fra 2^32 / 1024 / 1024 / 1024 = 4gb ram..
2^64 derimod er... 17179869184gb, 16777216tb, 16384(p)b?
:D
Fra 2^32 / 1024 / 1024 / 1024 = 4gb ram..
2^64 derimod er... 17179869184gb, 16777216tb, 16384(p)b?
:D
#6
#5... :o er det præcise tal...? :00
#7
av gutter, i siger noget godt og blandet.. og faktisk er det i bund og grund rigtigt nok.
64bit extentionen vil sige at du kan sætte en større sammenhængende thread af data til behandling. Altså slipper man for at skulle stykke den op. Eftersom threaden er større vil det også tage længere tid at behandle.. Dette fordobler ikke hastigheden men det effektivisere en del.
I 32bit (WinXP) kan ét program kun allokere 2gb ram til sig selv(ikke sikker på tallet). Dette bliver ikke en begrænsning i 64bit.
(søg evt på google)..
Så jeg tror nu din Mentor har ret.. :00
64bit extentionen vil sige at du kan sætte en større sammenhængende thread af data til behandling. Altså slipper man for at skulle stykke den op. Eftersom threaden er større vil det også tage længere tid at behandle.. Dette fordobler ikke hastigheden men det effektivisere en del.
I 32bit (WinXP) kan ét program kun allokere 2gb ram til sig selv(ikke sikker på tallet). Dette bliver ikke en begrænsning i 64bit.
(søg evt på google)..
Så jeg tror nu din Mentor har ret.. :00
#8
Kort sagt, så har din lærer ret.
En 64bit cpu arbejder ikke med flere tråde/threads, det gør en dual-core derimod (2 cores, 2 tråde, osv. derop ad..)
Som det allerede er blevet sagt, så kan en 64bit cpu derimod arbejde med større tal, og adresserer mere ram, end en 32bit cpu.
At den kan arbejde med større tal, giver ikke nødvendigvis mere performance, men kan give langt mere præcission i udregningerne (den kan regne med flere decimaler).
En 64bit cpu arbejder ikke med flere tråde/threads, det gør en dual-core derimod (2 cores, 2 tråde, osv. derop ad..)
Som det allerede er blevet sagt, så kan en 64bit cpu derimod arbejde med større tal, og adresserer mere ram, end en 32bit cpu.
At den kan arbejde med større tal, giver ikke nødvendigvis mere performance, men kan give langt mere præcission i udregningerne (den kan regne med flere decimaler).
#9
Din lærer har ret. At en cpu er 64 bit gør den ikke nødvendigvis hurtigere end en 32 bit cpu, der kører ved samme clockfrekvens. Det kommer helt an på designet af cpu'en, hvor mange instruktioner den kan behandle pr. clockcycle, antallet af de enkelte enheder i cpu'en(alu, fpu, simd, branch-prediction), pipeline og cachestørrelser osv. Tit er 64 bit ikke nogen fordel, husk på at det kræver dobbelt så meget hukommelse at lægge to og to sammen med 64 bit som det gør med 32 bit. Det er kun med beregningstunge opgaver at man opnår en reel fordel med 64 bit.
En 64 bit cpu kan adressere mere hukommelse på en gang end en 32 bit cpu kan, men det er også den eneste fordel som almindelige brugere har af den.
MVH
Morten Strårup
En 64 bit cpu kan adressere mere hukommelse på en gang end en 32 bit cpu kan, men det er også den eneste fordel som almindelige brugere har af den.
MVH
Morten Strårup
#10
Hmm... jeg havde nu forstået det anderledes... hvis cpuen fx skal regne med store "tal" (32+ bit) så bliver den nødt til at "dele" behandlingen op i 32bit stykker. Det samme gør sig gældende for 64bit men da de jo er størrer vil det give en mere effektiv udregning men ikke dobbelt så hurtig...
#11
jeg vil mene at du har ret..
en 32bit cpu kan tag 32 bit ind af gangen... en 64cpu tager 64 ind... derfor må 64'eren jo også kunne lave regnstykkerne det hurtigere efter som den kan have mere inde afgangen..
om resten af computern kan følge med..
men er praktisk holder det jo ikke, men det er en anden snak :D
en 32bit cpu kan tag 32 bit ind af gangen... en 64cpu tager 64 ind... derfor må 64'eren jo også kunne lave regnstykkerne det hurtigere efter som den kan have mere inde afgangen..
om resten af computern kan følge med..
men er praktisk holder det jo ikke, men det er en anden snak :D
#12
#2 #11
En 64 bit cpu kan som sådan kun lave udregninger som er tal på over 32 bit hurtigere...
Den kan ikke rive 2 udregninger med 32 bit tal ind af gangen.
Correct me if im wrong
En 64 bit cpu kan som sådan kun lave udregninger som er tal på over 32 bit hurtigere...
Den kan ikke rive 2 udregninger med 32 bit tal ind af gangen.
Correct me if im wrong
#13
Jeg kender ik så meget til det helle! Men kan da fortelle at der var en meget stor forskel fra min AMD Athlon xp3000+ til min AMD Athlon 64 3000+ 64'en var meget hurtiger :)
#14
#12 lyder meget logisk... det vil også medføre at en 64bit cpu vil være markant hurtigere til tunge programmer hvis de ellers er optimeret til 64bit...
#15
okay. jeg prøver igen.. hvis i vil ha den korte udgave så kig i #7.
ellers læs her:
http://arstechnica.com/cpu/03q...
hvis i kigger på diagrammet kan i se at trådens størrelse er større ved 64bit. MEN, det er stadig den samme ALU som laver "register" og integer beregningerne...
#13, jeps for cpu'ens generelle arkitektur er blevet forbedret. Du kører vel stadig WinXP 32bit?
ellers læs her:
http://arstechnica.com/cpu/03q...
hvis i kigger på diagrammet kan i se at trådens størrelse er større ved 64bit. MEN, det er stadig den samme ALU som laver "register" og integer beregningerne...
#13, jeps for cpu'ens generelle arkitektur er blevet forbedret. Du kører vel stadig WinXP 32bit?
#16
#13 Grunden til at din Athlon64 3000+ er "meget" hurtigere end din Athlon XP 3000+ er at en Athlon64 er bygget op efter en helt anden og bedre arkitektur der bl.a. indeholder onboard memorycontroller! Udover det er powerratingen ikke lavet udfra samme ydelses forhold!
#0 Det er din lærer der har ret! 64 bit gør udover at supporte en masse ram, gør det også at cpu ikke behøver dele udregningerne op lige så ofte som en 32 bit cpu, men det forudsætter at programmet der laver udregningerne understøtter 64 bit, så den ikke automatisk deler op efter 32 bit!
/Lars
#0 Det er din lærer der har ret! 64 bit gør udover at supporte en masse ram, gør det også at cpu ikke behøver dele udregningerne op lige så ofte som en 32 bit cpu, men det forudsætter at programmet der laver udregningerne understøtter 64 bit, så den ikke automatisk deler op efter 32 bit!
/Lars
#17
#13, at din Athlon64 er hurtigere i 32 bit programmer end din gamle Barton/Throughbread har ikke en skid med 64 bit at gøre. Athlon64'eren er bare en generation foran og dermed hurtigere clock for clock i forhold til de gamle Barton/Thoroughbread.
Det er netop det geniale ved AMD's indgangsvinkel til 64 bit, at de har lavet en supereffektiv 32 bit processor, der også kan køre 64 bit programmer ved hjælp af udvidelser i kernen. Andre "rene" 64 bit processorer som f.eks. Intel Itanium kan kun køre rene 64 bit programmer optimalt og får et stort performancehit ved afvikling af 32 bit programmer.
Prøv at se det som et regneark med enten 32 eller 64 felter. Et forsimplet eksempel kan være, at du vil lægge to tal sammen som f.eks. 3 og 4. Begge tal opbevares i et separat register indtil sammenlægningen foretages, hvorefter resultatet 7 bliver opbevaret i et tredje register – altså betyder antallet og størrelsen på registrene noget for den overordnede ydelse af processoren.
Nå, men en 64 bit processor har jo 64 registre i stedet for 32, så den må jo så være hurtigere. Nej, ikke nødvendigvis. Når man foretager matematiske operationer med integers (hele tal), så hjælper 64 bit kun, når man arbejder med operationer større end 32 bit, hvilket er ret unormalt i nuværende software. Når du lægger 3 og 4 eller 3.654.467 og 4.656.232 sammen, så skal man stadig kun bruge 1 register til hvert tal og 1 register til resultatet, og systemet er fløjtende ligeglad med, om det er 32 bit eller 64 bit registre, da du alligevel kun kan opbevare en værdi i hver.
Så kan man snakke om floating point operationer (decimaltal) – så burde 64 bit registre jo være hurtigere, da de kan holde flere tal efter kommaet, men x64 arkitekturen, som alle nuværende AMD og Intel 32 bit processorer tilhører, har allerede 64 bit floating point registre (faktisk 80 bit internt), så heller ikke her er der umiddelbart nogen fordel. Så hvad er fordelen så egentlig – de tre h’er såmen: hukommelse, hukommelse og hukommelse. Med et 64 bit operativ system, kan man komme over 4 GB grænsen (eller nærmere 3,5 GB). Dette er selvfølgelig indtil videre mest anvendeligt i server- og workstationmiljøer, men bliver selvfølgelig også hverdag for almindelige computerbruger inden for få år.
Athlon64 processoren kan enten køre i 32 bit mode (hvor 64 bit udvidelser er slukket), compatibility mode (f.eks. 64 bit windows, der afvikler 32 bit programmer) og ren 64 bit mode. I det rene 64 bit miljø frigives 8 ekstra registre, som alt andet lige kan forbedre ydelsen i forhold til 32 bit processorer i særlige tilfælde.
Det er netop det geniale ved AMD's indgangsvinkel til 64 bit, at de har lavet en supereffektiv 32 bit processor, der også kan køre 64 bit programmer ved hjælp af udvidelser i kernen. Andre "rene" 64 bit processorer som f.eks. Intel Itanium kan kun køre rene 64 bit programmer optimalt og får et stort performancehit ved afvikling af 32 bit programmer.
Prøv at se det som et regneark med enten 32 eller 64 felter. Et forsimplet eksempel kan være, at du vil lægge to tal sammen som f.eks. 3 og 4. Begge tal opbevares i et separat register indtil sammenlægningen foretages, hvorefter resultatet 7 bliver opbevaret i et tredje register – altså betyder antallet og størrelsen på registrene noget for den overordnede ydelse af processoren.
Nå, men en 64 bit processor har jo 64 registre i stedet for 32, så den må jo så være hurtigere. Nej, ikke nødvendigvis. Når man foretager matematiske operationer med integers (hele tal), så hjælper 64 bit kun, når man arbejder med operationer større end 32 bit, hvilket er ret unormalt i nuværende software. Når du lægger 3 og 4 eller 3.654.467 og 4.656.232 sammen, så skal man stadig kun bruge 1 register til hvert tal og 1 register til resultatet, og systemet er fløjtende ligeglad med, om det er 32 bit eller 64 bit registre, da du alligevel kun kan opbevare en værdi i hver.
Så kan man snakke om floating point operationer (decimaltal) – så burde 64 bit registre jo være hurtigere, da de kan holde flere tal efter kommaet, men x64 arkitekturen, som alle nuværende AMD og Intel 32 bit processorer tilhører, har allerede 64 bit floating point registre (faktisk 80 bit internt), så heller ikke her er der umiddelbart nogen fordel. Så hvad er fordelen så egentlig – de tre h’er såmen: hukommelse, hukommelse og hukommelse. Med et 64 bit operativ system, kan man komme over 4 GB grænsen (eller nærmere 3,5 GB). Dette er selvfølgelig indtil videre mest anvendeligt i server- og workstationmiljøer, men bliver selvfølgelig også hverdag for almindelige computerbruger inden for få år.
Athlon64 processoren kan enten køre i 32 bit mode (hvor 64 bit udvidelser er slukket), compatibility mode (f.eks. 64 bit windows, der afvikler 32 bit programmer) og ren 64 bit mode. I det rene 64 bit miljø frigives 8 ekstra registre, som alt andet lige kan forbedre ydelsen i forhold til 32 bit processorer i særlige tilfælde.
#18
#14 okay (:
#15 Jo køre bare med WinXP (32bit) Har prøvet WinXP pro x64! Men syndes ik om den :/
#16 Mmm okay! Syndes nu den virker hurtiger i alt! især i mine games :P
#15 Jo køre bare med WinXP (32bit) Har prøvet WinXP pro x64! Men syndes ik om den :/
#16 Mmm okay! Syndes nu den virker hurtiger i alt! især i mine games :P
#19
#18 Den ER også hurtigere i dine spil! Det er bare ikke pga 64 bit, men pga alle de andre optimeringer ifht Athlon XP bl.a indbygget memorycontroller!
/Lars
/Lars
#20
#17 vil nu ikke mene det er helt korrekt...
De kører samme antal tråde. Jep...
Pointen findes i at 32 bit henter 32 bit data fra rammene, og 64 bit henter 64 bit ad gangen...
Grunden til, at man kan bruge flere ram er simpel... Når en cpu kalder et sted i rammene kalder den det med et tal, og det tal kan naturligvis ikke være højere end det tal som X antal bit giver...
64 bit kan så hente fra 2^64 steder, og 32 bit 2^32...
Det der så bliver hurtigere, er tal som er højere end 32 bit...
Fx så har 32 bit x86, "2 registre" som loader noget fra ram...
når man loader så bliver der gemt 16 bit i AX, og 16 bit i EX (mener jge de hedder), og så kan man loade de første 8 bit i AX ved at loade AL, og AH for de sidste 8 bit.... HVIS man så skal loade mere end 32 bit, så bliver den nød til at kører mange flere intruktioner end en 32 bit (OVER dobbelt så mange)....
palle prop... det du siger med at 64 bit har 64 registre, ved jeg ikke helt, men når man loader fra ram, så bliver der altså kun brugt 64/8=8 og ved 32 bit 4, da man tager en byte ad gangen...
Så altså, i apps. som KUN bruger tal der er højere end 32 bit, vil du opnå mere end 100% forøgelse i hastigheden... Nu forholder det sig bare sådan, at der ikke forekommer NÆR så mange >32bit tal som <32 bit tal....
De kører samme antal tråde. Jep...
Pointen findes i at 32 bit henter 32 bit data fra rammene, og 64 bit henter 64 bit ad gangen...
Grunden til, at man kan bruge flere ram er simpel... Når en cpu kalder et sted i rammene kalder den det med et tal, og det tal kan naturligvis ikke være højere end det tal som X antal bit giver...
64 bit kan så hente fra 2^64 steder, og 32 bit 2^32...
Det der så bliver hurtigere, er tal som er højere end 32 bit...
Fx så har 32 bit x86, "2 registre" som loader noget fra ram...
når man loader så bliver der gemt 16 bit i AX, og 16 bit i EX (mener jge de hedder), og så kan man loade de første 8 bit i AX ved at loade AL, og AH for de sidste 8 bit.... HVIS man så skal loade mere end 32 bit, så bliver den nød til at kører mange flere intruktioner end en 32 bit (OVER dobbelt så mange)....
palle prop... det du siger med at 64 bit har 64 registre, ved jeg ikke helt, men når man loader fra ram, så bliver der altså kun brugt 64/8=8 og ved 32 bit 4, da man tager en byte ad gangen...
Så altså, i apps. som KUN bruger tal der er højere end 32 bit, vil du opnå mere end 100% forøgelse i hastigheden... Nu forholder det sig bare sådan, at der ikke forekommer NÆR så mange >32bit tal som <32 bit tal....
#21
#0 tja jeg vil faktisk give din lære mest ret .. da hoved årsagen til skiftet fra 32bit til 64bit er at man kan bruge/udnytte over 4gb ram... men det gir dog også en lille hastigheds forbedring... dog ikke specielt stor. MEn det fungere ikke som du beskriver det med at man i prinsippet ka køre dobbelt så hurtigt... desuden lyder det du forklare om nærmest som dual core... det er dem der kan håndtere 2 tråde på samme tid uden problemer i forhold til single cores. (vi snakker meget krævende tråde) ;)
#22
har lige tjekket... det med 64bit=64 registre, 32bit=32 registre holder ikke...
"basis" registrene for 32bit x86 er...
E[XX] = 32bit register
AX=16bit
BX=16bit
CX=16bit
DX=16bit
Der er så tilføjet 5-8 mere på 64bit AMD64
Som jeg er inde på tidligere kan man så dele dem op...
"basis" registrene for 32bit x86 er...
E[XX] = 32bit register
AX=16bit
BX=16bit
CX=16bit
DX=16bit
Der er så tilføjet 5-8 mere på 64bit AMD64
Som jeg er inde på tidligere kan man så dele dem op...
#23
Jeg tror ikke kun det er rammene der er grunden til at man skifter over til 64bit... Der må vel også være en grund til at gpu'er, powerpc mm kører 64-256 bit! Det giver meget logik det espeholt_jr siger med beregninger mm, da 64bit også giver store forøgelse i fx 3D programmer (i hh. til en nyhed om 64bit beta software jeg læste somewhere en træt aften)...
Jeg tør næsten æde en gammel hat på at hvis man sætte SuperPI/Prime95 op i en 32bit vs 64bit battle (forud sat der bliver lavet optimeret 64bit udgaver af dem) vil 64bit programmerne gå noget hurtigere, omend ikke dobbelt så hurtig så mærkbart hurtigere.
Jeg tør næsten æde en gammel hat på at hvis man sætte SuperPI/Prime95 op i en 32bit vs 64bit battle (forud sat der bliver lavet optimeret 64bit udgaver af dem) vil 64bit programmerne gå noget hurtigere, omend ikke dobbelt så hurtig så mærkbart hurtigere.
#24
#22, Som jeg også nævnte I mit eksempel, så var det et forsimplet forsøg på at forklare ideen bag 64 bit, men det kan da godt være, jeg har overforsimplet lidt. :e
For at præsicere lidt, så er problemet med x86 compilers, at de uden nok registre til rådighed nogen gange må bruge tid på bytte rundt på data for at få plads til de rigtige data til en given operation. Dette kan give flaskehalse. For at afhjælpe problemet indeholder x86-64 flere og bedre registre. x86-64 indeholder 8 ekstra general-purpose registre (GPR), så totalen er 16, og disse er ikke længere begrænset til 32 bit værdier, men kan alle indeholde 64 bit data. Ud over disse nye GPR's, indeholder x86-64 også 8 nye 128 bit SSE/SSE2 registre, så totalen af disse også er 16. De ekstra registre er sandsynligvis dem, der kan betyde den største ydelsesmæssige fordel ved arkitekturen.
Men det er svært at gætte på de reelle fordele. Den umiddelbare fordel er selvfølgelig muligheden for compileren at benytte flere "celler" til lokal dataopbevaring ved afvikling af kode, men det kommer igen an på det enkelte programs optimering. Og fordelene ved at have 16 GPR's frem for 8 kommer især an på kompleksiteten af koden. F.eks. vil Fortran koder med dybe loops drage større fordele end mere almindelige og mere lineare programkoder. Så i mange tilfælde vil der kun være lille eller ingen gevinst, mens der i andre tilfælde kan være enorme gevinster. Men som jeg også skrev i mit tidligere indlæg, så er den største umiddelbare fordel muligheden for mere hukommelse. Allerede i dag snakker BF2 gamere om nødvendigheden af 2 GB ram, så dagene med brug for 4 GB ram er nok ikke så langt ude i fremtiden endda. Og med tiden vil programmører verden over også udnytte mulighederne for mere komplekse programmer, nu hvor det ikke betyder et performancehit, men tvært imod kan betyde et performancegain.
For at præsicere lidt, så er problemet med x86 compilers, at de uden nok registre til rådighed nogen gange må bruge tid på bytte rundt på data for at få plads til de rigtige data til en given operation. Dette kan give flaskehalse. For at afhjælpe problemet indeholder x86-64 flere og bedre registre. x86-64 indeholder 8 ekstra general-purpose registre (GPR), så totalen er 16, og disse er ikke længere begrænset til 32 bit værdier, men kan alle indeholde 64 bit data. Ud over disse nye GPR's, indeholder x86-64 også 8 nye 128 bit SSE/SSE2 registre, så totalen af disse også er 16. De ekstra registre er sandsynligvis dem, der kan betyde den største ydelsesmæssige fordel ved arkitekturen.
Men det er svært at gætte på de reelle fordele. Den umiddelbare fordel er selvfølgelig muligheden for compileren at benytte flere "celler" til lokal dataopbevaring ved afvikling af kode, men det kommer igen an på det enkelte programs optimering. Og fordelene ved at have 16 GPR's frem for 8 kommer især an på kompleksiteten af koden. F.eks. vil Fortran koder med dybe loops drage større fordele end mere almindelige og mere lineare programkoder. Så i mange tilfælde vil der kun være lille eller ingen gevinst, mens der i andre tilfælde kan være enorme gevinster. Men som jeg også skrev i mit tidligere indlæg, så er den største umiddelbare fordel muligheden for mere hukommelse. Allerede i dag snakker BF2 gamere om nødvendigheden af 2 GB ram, så dagene med brug for 4 GB ram er nok ikke så langt ude i fremtiden endda. Og med tiden vil programmører verden over også udnytte mulighederne for mere komplekse programmer, nu hvor det ikke betyder et performancehit, men tvært imod kan betyde et performancegain.
#25
#23
Dobbelt så hurt6igt ville kræve dobbelt båndbredde og halv accesstime på ram oven i hatten :P - Men mon ikke den klare det på 70-80% af den tid en 32bit ville gøre det..
- 12k
Dobbelt så hurt6igt ville kræve dobbelt båndbredde og halv accesstime på ram oven i hatten :P - Men mon ikke den klare det på 70-80% af den tid en 32bit ville gøre det..
- 12k
#26
#25 det vil kun tiden kunne vise ;)
#27
#26
NaaH, man kan udregne det relativt præcist, men ligenu er jeg ikke i mode for at lave noget der så meget som minder mig om skole.
- 12k
NaaH, man kan udregne det relativt præcist, men ligenu er jeg ikke i mode for at lave noget der så meget som minder mig om skole.
- 12k
#28
palle prop -> "bytte rundt på data"... hhm :/...
Det der sker i de fleste tilfælde når man skal udregne ting der er større end 32 bit, er at cpuen bliver nød til at gemme data i rammene, og derefter tage dem ud iden, og derved få en MEGET lavere ydelse...+ at cpuen vil skulle bruge flere intruktioner...
eksempel... hvis vi har værdien 0 og vil adde (2^32) med 32 bit processer, så vil vi bare skulle kører én intruktion (ADD ax, værdi), men hvis vi skal regne større ting ud, så kommer vi min. op på 4 intruktioner...
registrene i cpuen er jo LANGT LANGT hurtigere, end adgangen til rammene...
det samme sker når man prøver at mere end 8 parenteser ud med 32 bit, så bliver den nød til at gemme i memory
Det der sker i de fleste tilfælde når man skal udregne ting der er større end 32 bit, er at cpuen bliver nød til at gemme data i rammene, og derefter tage dem ud iden, og derved få en MEGET lavere ydelse...+ at cpuen vil skulle bruge flere intruktioner...
eksempel... hvis vi har værdien 0 og vil adde (2^32) med 32 bit processer, så vil vi bare skulle kører én intruktion (ADD ax, værdi), men hvis vi skal regne større ting ud, så kommer vi min. op på 4 intruktioner...
registrene i cpuen er jo LANGT LANGT hurtigere, end adgangen til rammene...
det samme sker når man prøver at mere end 8 parenteser ud med 32 bit, så bliver den nød til at gemme i memory
#29
#27 kan du have ret i... teknologi er et wierd fag, men man laver nu ikke så meget, så et godt fag alligevel ;)
#30
For at komme tilbage til tiden er det ikke noget du "bare" lige regner ud. Du skal kende koden til begge programmer (eller i det mindste deres virke måde) og så skal du være godt og grundigt inde i opbygningen af cpuen, hvordan den håntere koden osv...
#31
Du kan relativt let finde ud af hvor mange intruktioner der bruges, men ikke alle intruktioner tager lige lang tid... og det kommer også an på parametrene... men hvis man kører den samme intruktion 10 mil. gange, så kan man jo sådanset godt finde ud af hvor hurtig lige præcis den intruktion er, med lige præcis de parametre....
#32
okay... ville gerne se en regne det ud, kun ved at læse om cpuen specs og ting den foretager :D:D:D
#33
#26, nu ordkløver du vist. :00
#34
#32 vi snakker ikke ren teori her, der bliver ført "bevis" og hele diskutionen går ud på hvorvidt 64bit er hurtigere eller ej, og der er nogen der siger den er og nogen der siger den ikke er. Der er ingen specifikke tal på!
#35
Hehe i slut fasen handler det om at skrive effektive 64bit programmer. Men det vil tid vise woooopeeee. Vi bliver nok nødt til at vente til næste år hehe. Medmindre vi selvfølgelig kontakter Microsoft, og får skiftet vores WinXP Home eller Prof til en 64bit version. Der var noget om at det var gratis at gøre det :D.
#36
#34 ved ikke hvad sådan noget jysk betyder ;) men det er ikke forkert det jeg siger....
#37
#37 det der snakkes om er om 64bit er hurtigere... så er der nogen der siger at det er og fortælle hvilke steder og på hvilke måder det er hurtigere, det er også praksis der er relevalt, syntes jeg ikke man kan sige med mariekiks :00
Jeg mente ikke at du snakkede teori, men forstod dit indlæg som du mente vi snakkede ren teori, derfor mit indlæg!
Jeg mente ikke at du snakkede teori, men forstod dit indlæg som du mente vi snakkede ren teori, derfor mit indlæg!
#38
Husk nu at bare fordi der ikke er plads i registrene, så bliver der ikke direkte skrevet til RAM'en. Der bliver skrevet til "memory" men det bliver i første gang L1 cachen der bliver skrevet til - og den er vanvittig hurtig.
64-bit giver ingen væsentlig ydelsesforbedring, medmindre man programmerer til at udnytte 64-bit talstørrelser.
64-bit ændrer kun på heltalsberegningerne, kommatalsberegningsenheden er nøjagtigt den samme om du kører 64-bit eller 32-bit (som der nævnes i en tidligere indlæg, så har kommatalsenheden en præcision på 80-bit i extended mode allerede).
Du kan ikke beregne 2 32-bit instruktioner samtidigt hvis du kører i 64-bit mode. Når du kører 64-bit mode, så vil 32-bit beregninger tage samme tid som hvis du kørte dem i 32-bit mode, fordi instruktionerne tager den tid de tager. Bare fordi 3 kan repræsenteres som 32-bit tal (30 nuller...11 ) så kan det på samme måde også repræsenteres med 64-bit (62 nuller...11) derfor kan du ikke køre 2 32-bit operationer i et hug, som mange fejlagtigt tror. Data'en fylder bare dobbelt så meget (som andre også skriver herinde).
Det er sikkert "muligt" at ændre, så man med 64-bit kan beregne 2 32-bit i et hug, men det kræver en hardware ændring, som jeg ikke tror nogen fra AMD eller intel er interesseret i at forske i. De har allerede dual-core hvis du vil have "dobbelt flertrådsydelse".
[Edit]
Det vil så sige, at hvis du vil lægge små tal sammen, som fx 3, som kan repræsenteres ved 2bit, skal 32-bit processorer så kunne lægge 16 af dem sammen ad gangen?
[/Edit]
Mvh. Uffe
64-bit giver ingen væsentlig ydelsesforbedring, medmindre man programmerer til at udnytte 64-bit talstørrelser.
64-bit ændrer kun på heltalsberegningerne, kommatalsberegningsenheden er nøjagtigt den samme om du kører 64-bit eller 32-bit (som der nævnes i en tidligere indlæg, så har kommatalsenheden en præcision på 80-bit i extended mode allerede).
Du kan ikke beregne 2 32-bit instruktioner samtidigt hvis du kører i 64-bit mode. Når du kører 64-bit mode, så vil 32-bit beregninger tage samme tid som hvis du kørte dem i 32-bit mode, fordi instruktionerne tager den tid de tager. Bare fordi 3 kan repræsenteres som 32-bit tal (30 nuller...11 ) så kan det på samme måde også repræsenteres med 64-bit (62 nuller...11) derfor kan du ikke køre 2 32-bit operationer i et hug, som mange fejlagtigt tror. Data'en fylder bare dobbelt så meget (som andre også skriver herinde).
Det er sikkert "muligt" at ændre, så man med 64-bit kan beregne 2 32-bit i et hug, men det kræver en hardware ændring, som jeg ikke tror nogen fra AMD eller intel er interesseret i at forske i. De har allerede dual-core hvis du vil have "dobbelt flertrådsydelse".
[Edit]
Det vil så sige, at hvis du vil lægge små tal sammen, som fx 3, som kan repræsenteres ved 2bit, skal 32-bit processorer så kunne lægge 16 af dem sammen ad gangen?
[/Edit]
Mvh. Uffe
#39
#40 også derfor jeg bevidst skiver memory og ikke rammne... men stadig langsommere...
#40
#39 Hihi, det havde jeg lagt mærke til. Troede bare at det meste som skulle siges var allerede sagt i diskussionen, medmindre vi vil ned i den dybe hardware ende. Var faktisk ikke mente som en direkte svar på din forrige indlæg om teori og tal :). Det var bare noget som jeg vil tilføje til diskussionen.
Tror at #40 har beskrevet det meget bedre end jeg har. :p
Tror at #40 har beskrevet det meget bedre end jeg har. :p
#41
#40, fin forklaring...
#42
Så hurtig er L1 sq heller ikke :P
20gb/s :|
L2: 12,5gb/s
Ram: 7300gb/s :|
20gb/s :|
L2: 12,5gb/s
Ram: 7300gb/s :|
#43
#44 se hellere på tilgangstiden istedet for båndbredden, det er der L1 virkelig har sin styrke.
Mvh. Uffe
Mvh. Uffe