Er 64 bits nødvendig?

[tommen]

Viser til frekt avstengt tråd: 64 bits - er en vits

 

Ønsker nå å gjenoppta denne tråden nesten et par år senere!

 

CAT-scan: Hvor mange GB ram har du i pc'en din nå da? lol

 

bepe86: linken din funker ikke lengre, men det er helt klart at ved rå flytting av data så er det en fordel å kunne sende 64 bits i slengen (men til en opplysning så var faktisk bus-bredden på Pentium pro også på 64 bits..... men adresse busen var "bare" 32 bits). 64 bits aritmetikk (i de sjeldne tilfellene du trenger så store tall) er greit å ha. Men dette er mere aktuellt for store systemer (forskning o.l.) enn for deg og meg. Det er ikke noe problem å representere tall på over 4 milliarder (bare sjekk kalkissen i Windows! Den flater ikke ut 4Gb den :!: ). Ellers vil 64 bits bruke mer minne (faktisk dobbelt så mye) en et tilsvarende 32 bits system når minnet benyttes for variabler / konstanter etc. Performance gainen som det ofte er omtalt kommer av at det nå finns flere register å leke med en før. Dette hadde vært det samme på et vidreutviklet 32 bits system.

 

Selve betegnelsen 64 bits prosessor er ikke avhengig av adresserings bussen (Som mange har missforstått) men data bussen. Så 64 bits prosessorer har vi hatt i lang tid.

 

3.1.1.1 The Data Bus

 

The 80x86 processors use the data bus to shuffle data between the various components in a computer system. The size of this bus varies widely in the 80x86 family. Indeed, this bus defines the “size” of the processor.

 

On typical 80x86 systems, the data bus contains eight, 16, 32, or 64 lines. The 8088 and 80188 microprocessors have an eight bit data bus (eight data lines). The 8086, 80186, 80286, and 80386SX processors have a 16 bit data bus. The 80386DX, 80486, and Pentium Overdrive processors have a 32 bit data bus. The Pentium and Pentium Pro processors have a 64 bit data bus. Future versions of the chip (the 80686/80786?) may have a larger bus.

 

Utdrag fra the Art of Assembly boka til Randall Hyde. AoA

 

lock-aze: Narr

 

Rikky: Kjapp på avtrekkern. Du kan da la folk få svare. Når det gjelder "artikkelen" du refererte til så var "hoved" argumentet der at du kan adressere mere RAM. Nå er det slik at det fins svært få med mer en 4GB ram der til og med i dag. Nye PC'er leveres stort sett IKKE med 64 bits OS og den fantastiske performance hitten som dette skulle gi gamerne etc. venter jeg fortsatt på. Når det gjelder din kolegas påstand om at en pc ikke kan adressere mere en 4GB sier han jo selv at dette er mulig senere i artikkelen. Jeg brukte i min forrige artikkel commodore 64 som hadde en 16-bits adresserings bus som eksempel og vil gjøre det igjen: Denne maskina kunne ekspanderes til 256K REU ram expansion og hvis en var "litt" med i hva en gjorde så var det ikke noe problem å benytte dette minnet. Fantes faktisk kommersielt utviklede OS'er den gangen som gjorde akkurat dette (GEOS). Så det er jo rent merkelig at dette ikke skal la seg gjøre i dag på en skikkelig måte!?!?

 

Et annet problem er at Intel/AMD ikke greier å bli enig om hvordan denne "nye" arkitekturen skal være. Kan gi problemer for visse typer software om utviklerene ikke er forsiktige.

 

I disse dager er 64 bits kommet for å bli. Stort sett alt som selges 64 bits. Men å "løpe å kjøpe" for 2 år siden for å være forberedt på hva som kommer er jo til å le seg ihjel av. Mao: En vits!

Endret 21. oktober 2006 av tommen

[CoolDuckie]

Ellers vil 64 bits bruke mer minne (faktisk dobbelt så mye) en et tilsvarende 32 bits system når minnet benyttes for variabler / konstanter etc. Performance gainen som det ofte er omtalt kommer av at det nå finns flere register å leke med en før. Dette hadde vært det samme på et vidreutviklet 32 bits system.

 

Selve betegnelsen 64 bits prosessor er ikke avhengig av adresserings bussen (Som mange har missforstått) men data bussen. Så 64 bits prosessorer har vi hatt i lang tid. 

 

Først: Selv om du har "64 bits minne", behøver ikke hver adresserbar enhet å inneholde en 64-bits variabel. Du kan stappe 8 separate bytes inn i 64 bits. I større array er vel ikke det noe problem å gjøre dette slik at minnet utnyttes.

 

For det andre så er det vel motsatt av det du skriver i 2. avsnitt. Selve betegnelsen "64 bits prosessor" går vel på adresseringen. Ingen påsto vel at PPRO var en 64 bits prosessor, selv om den hadde en 64 bits bred databuss?

 

CD

[tommen]

Ellers vil 64 bits bruke mer minne (faktisk dobbelt så mye) en et tilsvarende 32 bits system når minnet benyttes for variabler / konstanter etc. Performance gainen som det ofte er omtalt kommer av at det nå finns flere register å leke med en før. Dette hadde vært det samme på et vidreutviklet 32 bits system.

 

Selve betegnelsen 64 bits prosessor er ikke avhengig av adresserings bussen (Som mange har missforstått) men data bussen. Så 64 bits prosessorer har vi hatt i lang tid. 

 

Først: Selv om du har "64 bits minne", behøver ikke hver adresserbar enhet å inneholde en 64-bits variabel. Du kan stappe 8 separate bytes inn i 64 bits. I større array er vel ikke det noe problem å gjøre dette slik at minnet utnyttes.

 

For det andre så er det vel motsatt av det du skriver i 2. avsnitt. Selve betegnelsen "64 bits prosessor" går vel på adresseringen. Ingen påsto vel at PPRO var en 64 bits prosessor, selv om den hadde en 64 bits bred databuss?

 

CD

7109891[/snapback]

 

Til din første komentar så har jeg ikke i grunn påstått det heller. Men hvis en ikke er forsiktig så kan en risikere å benytte mere minne. Med dagens bruk av HLL uvikling er det neppe alle som faktisk tenker over dette faktum. En skal også huske på at adressering til minneplasser som ikke går opp i "64 bits" kan forårsake tregere utførelse av memory get/store. Dvs. senere access tid.

 

Til din andre komentar så var faktisk pentium PRO en 64 bits prosessor i og med at data bussen er 64 bits bred. Dette kan du se i sitatet som er skrevet over fra forfatteren av AoA. Adresseringsbussen på en 286 er 24 bits men betyr ikke at det er en 24 bits prosessor men derimot en 16 bits prosessor i og med at data busen er på 16 bits! Dette er en vanlig feiltolking av størrelsen på prosessorer.

[Ernie]

Et annet problem er at Intel/AMD ikke greier å bli enig om hvordan denne "nye" arkitekturen skal være. Kan gi problemer for visse typer software om utviklerene ikke er forsiktige.

7107105[/snapback]

Jassåja. Du påstår altså at EM64T ikke er det samme som AMD64? Har du noen kilde på det her? Sist jeg sjekket var de regnet som en og samme ting.

[tommen]

Et annet problem er at Intel/AMD ikke greier å bli enig om hvordan denne "nye" arkitekturen skal være. Kan gi problemer for visse typer software om utviklerene ikke er forsiktige.

7107105[/snapback]

Jassåja. Du påstår altså at EM64T ikke er det samme som AMD64? Har du noen kilde på det her? Sist jeg sjekket var de regnet som en og samme ting.

7110566[/snapback]

 

 

Tja hva med dette:

 

Differences between AMD64 and EM64T

There are a small number of differences between each instruction set. Compilers generally produce binaries that target both AMD64 and EM64T, making the differences mainly of interest to compiler developers and operating system developers.

 

* EM64T's BSF and BSR instructions act differently when the source is 0 and the operand size is 32 bits. The processor sets the zero flag and leaves the upper 32 bits of the destination undefined.

* AMD64 supports 3DNow! instructions. This includes prefetch with the opcode 0x0F 0x0D and PREFETCHW, which are useful for hiding memory latency.

* EM64T lacks the ability to save and restore a reduced (and thus faster) version of the floating-point state (involving the FXSAVE and FXRSTOR instructions).

* EM64T lacks some model-specific registers that are considered architectural to AMD64. These include SYSCFG, TOP_MEM, and TOP_MEM2.

* EM64T supports microcode update as in 32-bit mode, although it has been rumored that AMD processors have supported programmable microcode as an undocumented feature for years. [citation needed]

* EM64T's CPUID instruction is very vendor-specific, as is normal for x86-style processors.

* EM64T supports the MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading.

* AMD64 systems allow the use of the AGP aperture as an IO-MMU. Operating systems can take advantage of this to let normal PCI devices DMA to memory above 4 GiB. EM64T systems require the use of bounce buffers, which are slower.

* SYSCALL and SYSRET are also only supported in IA-32e mode (not in compatibility mode) on EM64T. SYSENTER and SYSEXIT are supported in both modes.

* Near branches with the 0x66 (operand size) prefix behave differently. One type of CPU clears only the top 32 bits, while the other type clears the top 48 bits.

 

Dette er tatt fra: http://en.wikipedia.org/wiki/EM64T

 

Som du ser så er det faktisk en del forskjeller ute å går. Ikke at bør by på et vedig stort problem da de fleste kompilatorer ordner ut i disse forskjellene. Men like fult ut er de ikke like og i visse tilfeller kan det gi problemer!

 

Håper dette avklarer situasjonen noget.

[Turgon]

Hm, får ikke helt tak i hva du vil frem til, men for meg virker det som om du blander sammen en hel masse som har betegnelsen 64 bit, som ikke nødvendigvis har noe med hverandre å gjøre.

 

Hva ytelses økningen angår kommer den nesten utelukkende av større registre, men de hadde det ikke vært mulig å bruk med 32 bit (om jeg ikke tar helt feil). Videre står vi snart ovenfor 4 GB grensa (min neste ram oppgradering vil gi meg 4 gb minne) og det er veldig praktisk å fjerne slike grenser før de blir et problem.

 

Jeg tror du prøver å få frem at det skulle la seg gjøre å ha mer enn 4 b minnne på en 32 bits prosessor og det stemmer, men det medfører en slags bytting slik at man på en måte ikke kan ikke kan bruke alt minne samtidig (man skifter mellom enheter på 4 og 4gb). Dette gjør at man får en stor ytelses ulempe. (kan noen med bedre kunnskaper om dette skrive dette mer forstålig?).

[tommen]

Hm, får ikke helt tak i hva du vil frem til, men for meg virker det som om du blander sammen en hel masse som har betegnelsen 64 bit, som ikke nødvendigvis har noe med hverandre å gjøre.

 

Hva ytelses økningen angår kommer den nesten utelukkende av større registre, men de hadde det ikke vært mulig å bruk med 32 bit (om jeg ikke tar helt feil). Videre står vi snart ovenfor 4 GB grensa (min neste ram oppgradering vil gi meg 4 gb minne) og det er veldig praktisk å fjerne slike grenser før de blir et problem.

 

Jeg tror du prøver å få frem at det skulle la seg gjøre å ha mer enn 4 b minnne på en 32 bits prosessor og det stemmer, men det medfører en slags bytting slik at man på en måte ikke kan ikke kan bruke alt minne samtidig (man skifter mellom enheter på 4 og  4gb). Dette gjør at man får en stor ytelses ulempe. (kan noen med bedre kunnskaper om dette skrive dette mer forstålig?).

7111666[/snapback]

 

Ok. Dette sporer litt av. Hovedpoenget var at det å løpe å kjøpe seg 64 bits prosessor og øvrig hardware for 2 år siden var fullstendig bortkastet. I dag er situasjonene endret. Men til stadig så denne tråden peppret med en masse synsing og mening om 64 bits og hva dette i praksis betyr.

 

så for å oppsummere: En 64 bits prosessor er en prosessor som har en databus på 64 bits IKKE en adresseringsbus på 64 bits. Se mitt eksempel tidligerer med en 286 prosessor. Poenget med dette er at hele betegnelsen 64 bits på dagens AMD64 / EM64T prosessorer ikke er noe nytt i og med dette har eksistert i mange år tidligere. Dette er en markedsførings flopp som massene har slukt.

 

Når det gjelder ytelsesøkningen du refererer til har det ikke med større registre å gjøre men med flere registre å gjøre. At de er større gjør at de kan holde større tall men ikke noe raskere. Flere gjør at flere tall kan holdes i registre som kan accesses av prosessoren uten noe bus venting etc. Enkelt kan man si at hvis en Athlon/P4 med 32 bits adressebus hadde vær utstyrt med tilsvarende flere registre så hadde disse også kunne yte merkant bedre.

 

Angående din teori om hvordan mere en 4GB minne kan adresseres med en prosessor med kun 32 bits adresse bus er riktig. MEN du sier selv at du først nå har gått til anskaffelsen av 4 Gb, som betyr at ditt OS tidligere har nyttegjort seg av "virtuelt" minne som ligger på HD'en din for å supplere hele 4Gb. Denne typen minne-triksing gir et skikkelig ytelses hit i forhold til å "banke" minne. Det gjøres med få cycles og vil ikke gi noen merkbar performance hit.

 

Håper ting er litt klarere.

[CoolDuckie]

Til din andre komentar så var faktisk pentium PRO en 64 bits prosessor i og med at data bussen er 64 bits bred. Dette kan du se i sitatet som er skrevet over fra forfatteren av AoA. Adresseringsbussen på en 286 er 24 bits men betyr ikke at det er en 24 bits prosessor men derimot en 16 bits prosessor i og med at data busen er på 16 bits! Dette er en vanlig feiltolking av størrelsen på prosessorer.

7110377[/snapback]

 

Hmm, jaja, mulig jeg har gått glipp av noe her. Nå var jo adresseringen til 286-en spesiell, for den ble vel utgjort av 2 overlappende 16 bits registre. Har vage minner om hvor kronglete det var å bruke store datamengder før 386-en kom med sin flate minnestruktur.

 

CoolDuckie

[Ernie]

*klippe*

Håper dette avklarer situasjonen noget.

7111311[/snapback]

Nei, det avklarer ikke en ting skal jeg si deg. Jeg veit meget godt er noen små forskjeller, men disse er stort sett av ubetydelig grad. Som det til og med står i det du siterte vil det bare være av interesse for de som skal driver med kompilatorer eller OS. Jeg veit ikke om det bare er meg, men jeg kaller ikke slikt for "forskjeller som kan gi utviklere problemer". Det er ikke noe mer problemer enn alle andre tingene Intel og AMD implementerer.

[sedsberg]

Det med 64-bits databuss på gamle prosessorer (Pentium, PPro, etc) var jo bare for å få inn mer data i slengen. Den jobbet fremdeles bare i 32-bit internt. Omtrent som når vi i dag har dual-channel.

 

80386SX f.eks. har bare 16-bits databuss, men er alikevel en 32-bits prosessor. Samme med gode gamle 68000. Disse må hente data inn i to omganger.

[Hårek]

... så for å oppsummere: En 64 bits prosessor er en prosessor som har en databus på 64 bits IKKE en adresseringsbus på 64 bits. ...

7112422[/snapback]

Den duger ikke som definisjon. ALU størrelse er en bedre målestokk.

"Without further qualification, however, a computer architecture described as "64-bit" generally has integer registers that are 64 bits wide ..."

 

Men det er ike lett å gi noen entydig definisjon på hvordan man klassifiserer en CPU.

http://en.wikipedia.org/wiki/64-bit

[tommen]

*klippe*

Håper dette avklarer situasjonen noget.

7111311[/snapback]

Nei, det avklarer ikke en ting skal jeg si deg. Jeg veit meget godt er noen små forskjeller, men disse er stort sett av ubetydelig grad. Som det til og med står i det du siterte vil det bare være av interesse for de som skal driver med kompilatorer eller OS. Jeg veit ikke om det bare er meg, men jeg kaller ikke slikt for "forskjeller som kan gi utviklere problemer". Det er ikke noe mer problemer enn alle andre tingene Intel og AMD implementerer.

7112593[/snapback]

 

Små forskjeller som KAN ha betydning er stikkordet her ^^

 

Du kan vri og vende, forskjeller er det som du selv sier. Hvor stor betydning de har får hver enkelt avgjøre selv.

[tommen]

Det med 64-bits databuss på gamle prosessorer (Pentium, PPro, etc) var jo bare for å få inn mer data i slengen. Den jobbet fremdeles bare i 32-bit internt. Omtrent som når vi i dag har dual-channel.

 

80386SX f.eks. har bare 16-bits databuss, men er alikevel en 32-bits prosessor. Samme med gode gamle 68000. Disse må hente data inn i to omganger.

7112776[/snapback]

 

riktig, riktig, riktig og riktig

 

Og pr definisjon (som du kan se av mitt sitat over fra AoA) er det databussen som definerer om en prosessor er på henholdsvis 8, 16 32 64 etc. bits.

[Jaffe]

så for å oppsummere: En 64 bits prosessor er en prosessor som har en databus på 64 bits IKKE en adresseringsbus på 64 bits. Se mitt eksempel tidligerer med en 286 prosessor. Poenget med dette er at hele betegnelsen 64 bits på dagens AMD64 / EM64T prosessorer ikke er noe nytt i og med dette har eksistert i mange år tidligere. Dette er en markedsførings flopp som massene har slukt.

 

Nei, den vanligste definisjonen av en 64-bits prosessor er at den kan operere med 64 bits samtidig (altså; at den har 64-bit store registre for å utføre regneoperasjoner). Størrelsen på databussen avgjør bare hvor mye data prosessoren kan hente fra minnet samtidig -- ikke hvor raskt den kan operere med disse dataene.

 

Og pr definisjon (som du kan se av mitt sitat over fra AoA) er det databussen som definerer om en prosessor er på henholdsvis 8, 16 32 64 etc. bits.

7113452[/snapback]

 

Nå er ikke Art of Assembly på noen som helst måte en bok som definerer hva som er rett

Endret 20. oktober 2006 av Jaffe

[tommen]

så for å oppsummere: En 64 bits prosessor er en prosessor som har en databus på 64 bits IKKE en adresseringsbus på 64 bits. Se mitt eksempel tidligerer med en 286 prosessor. Poenget med dette er at hele betegnelsen 64 bits på dagens AMD64 / EM64T prosessorer ikke er noe nytt i og med dette har eksistert i mange år tidligere. Dette er en markedsførings flopp som massene har slukt.

 

Nei, den vanligste definisjonen av en 64-bits prosessor er at den kan operere med 64 bits samtidig (altså; at den har 64-bit store registre for å utføre regneoperasjoner). Størrelsen på databussen avgjør bare hvor mye data prosessoren kan hente fra minnet samtidig -- ikke hvor raskt den kan operere med disse dataene.

7113468[/snapback]

 

Føler jeg gjentar meg selv her, men here goes:

 

Fordi du har registre som kan håndtere 64 bits betyr det ikke at de er raskere en register som kan håndtere 32 bits. De jobber like kjapp om du "dytter" tallet 123456789 igjennom dem og utfører aritmetikk på det (hvis forskjellen kun er størrelsen på registerne). Kun i de (FÅ!) tilfeller hvor du trenger å gjøre regneoperasjoner som krever tall over 4 milliarder gir det en ytelsesboost når en bruker 64 bits registre. Flere registre på den annen side gir mer power!

 

Så over til data bussen. Dette er flaskehalsen på prosessoren. får ikke prosessoren tak i det minne som den skal behandle raskt nok vil prosessoren gå i wait-state til den får infoen den trenger og mister fort en masse cycles for pga dette. I og med at prosessoren er så mye raskere enn minnet (cache også) så er det viktig å fylle cpu'en med ting å gjøre fort nok hvis ikke blir det ikke gjort noe som helst samma faen hvor store register du har. DERFOR er det data bussen som avgjør "hvor stor" en prosessor er! Sjekk mitt forste sitat ovenfor. Kan love deg at dette er en kar som vet hva han snakker om.

 

 

 

Og pr definisjon (som du kan se av mitt sitat over fra AoA) er det databussen som definerer om en prosessor er på henholdsvis 8, 16 32 64 etc. bits.

 

Nå er ikke Art of Assembly på noen som helst måte en bok som definerer hva som er rett

 

Tror nok forfatteren av denne boka har mer greie på dette en deg ^^

Endret 20. oktober 2006 av tommen

[Jaffe]

Tror nok forfatteren av denne boka har mer greie på dette en deg ^^

7113582[/snapback]

 

Og ditt poeng er?

 

Art of Assembly definerer fortsatt ikke hva somer rett

Det fins haugevis av andre meninger om dette.

 

EDIT:

Dette er vel egentlig en meningsløs tråd, i og med at man i dag omtrent ikke får kjøpt 32-bits prosessorer uansett. Hva er det å klage på da -- når du får en 64-bits prosessor til samme pris, selv om du kanskje ikke har bruk for det? Skjønner egentlig ikke helt hvorfor du lager en tråd for å formidle dette når det faktisk bare er noe man får finne seg i (selv om det ikke akkurat er noe som irriterer de fleste ... lol)

Endret 20. oktober 2006 av Jaffe

[Quintero]

Litt av en tråd... Plutselig kommer du og slenger ut overhøvlinger på bakgrunn av en nesten to år gammel diskusjon...

 

3.1.1.1 The Data Bus

 

The 80x86 processors use the data bus to shuffle data between the various components in a computer system. The size of this bus varies widely in the 80x86 family. Indeed, this bus defines the “size” of the processor.

 

On typical 80x86 systems, the data bus contains eight, 16, 32, or 64 lines. The 8088 and 80188 microprocessors have an eight bit data bus (eight data lines). The 8086, 80186, 80286, and 80386SX processors have a 16 bit data bus. The 80386DX, 80486, and Pentium Overdrive processors have a 32 bit data bus. The Pentium and Pentium Pro processors have a 64 bit data bus. Future versions of the chip (the 80686/80786?) may have a larger bus.

Jeg lurer på hvordan du kan være salig overbevist om hva de mener med "the "size" of the processor", og hvordan det beviser at betegnelsen "64-bits CPU" brukes helt feil idag. En 64-bits prosessor har GPRs som er 64 bits brede, og det har ikke eksistert i desktop-segmentet i mer enn noen få år. Slike prosessor kan behandle tallrekker på inntil 64 siffer i en operasjon, og det handler jo om noe helt annen enn kommunikasjonen mellom de forskjellige komponentene.

 

En 64 bits prosessor er en prosessor som har en databus på 64 bits IKKE en adresseringsbus på 64 bits. Se mitt eksempel tidligerer med en 286 prosessor. Poenget med dette er at hele betegnelsen 64 bits på dagens AMD64 / EM64T prosessorer ikke er noe nytt i og med dette har eksistert i mange år tidligere. Dette er en markedsførings flopp som massene har slukt.

7112422[/snapback]

Det virker som om du tror at det bare finnes ett eneste grensesnitt for kommunikasjon i hele systemet, men jeg skal gå ut ifra at du mener minnebuss og/eller FSB når du sier "databuss".

 

La meg få opplyse om at det finnes en rekke busser i systemet, som godt kan ha forskjellige bredder. Hele Pentium 4-serien har for eksempel 256-bits forbindelse mellom L1 og L2, og 64 bits mellom CPU og minnekontroller. Alle disse bussene tjener jo formålet å bringe data til og fra prosessoren, som du ivrig poengterer betydningen av, derfor blir det feil å hele tiden snakke om "bussen" (bestemt form). Og dette sier jo ingenting om hvor mange bits en prosessor er på.

 

Jeg har forøvrig også til gode å se 64-bits adresse-registre. For eksempel har A64 40-bits fysisk register, og 48-bits virtuelt.

 

Det med 64-bits databuss på gamle prosessorer (Pentium, PPro, etc) var jo bare for å få inn mer data i slengen. Den jobbet fremdeles bare i 32-bit internt. Omtrent som når vi i dag har dual-channel.

 

80386SX f.eks. har bare 16-bits databuss, men er alikevel en 32-bits prosessor.

7112776[/snapback]

riktig, riktig, riktig og riktig

 

Og pr definisjon (som du kan se av mitt sitat over fra AoA) er det databussen som definerer om en prosessor er på henholdsvis 8, 16 32 64 etc. bits.

7113452[/snapback]

Er det ikke en selvmotsigelse å samtykke til at 386 er 32-bits, til tross for at den bare har 16-bits databuss? Du hevder jo for harde livet at det er databussen som bestemmer "størrelsen" på prosessoren, samtidig som du bekrefter at en bredere buss kan brukes til å overføre data mer effektivt, uten at det påvirker hvor mange bits prosessorens er.

 

Og forresten, siden A64-prosessorer opererer i dualchannel (2x64 bits) betyr vel det at de er 128-bits?

 

Så over til data bussen. Dette er flaskehalsen på prosessoren. får ikke prosessoren tak i det minne som den skal behandle raskt nok vil prosessoren gå i wait-state til den får infoen den trenger og mister fort en masse cycles for pga dette. I og med at prosessoren er så mye raskere enn minnet (cache også) så er det viktig å fylle cpu'en med ting å gjøre fort nok hvis ikke blir det ikke gjort noe som helst samma faen hvor store register du har. DERFOR er det data bussen som avgjør "hvor stor" en prosessor er!

Dette blir for svart-hvitt. Det er jo en lang rekke ting som må tas med i betraktningen, og du får det til å virke som om bredden på minnebussen er altoverskyggende. FSB og minnebussen sier ingenting om hvor effektiv cachen er, og det blir helt feil å nærmest konsekvent gå ut ifra at prosessoren må hente data fra main memory. Cachen opererer også på samme klokkefrekvens som CPU, og selv om det er snakk om noen få syklusers forsinkelse (L1) blir det feil å si at cachen er så mye tregere enn CPU. Klokkefrekvens, forsinkelser, prefetching, datarate (pumping), dataorganisering og ørten andre faktorer til de forskjellige leddene av minnehierarkiet kan jo også bety mye mer enn bredden på bussene, alt ettersom.

 

Det er forresten mye mer jeg kunne ha sagt, men har på følelsen at det har liten hensikt å utdype i det uendelige...

[tommen]

Litt av en tråd... Plutselig kommer du og slenger ut overhøvlinger på bakgrunn av en nesten to år gammel diskusjon...

 

Følte vel at poenget mitt i den diskusjonen ikke ble helt hørt da vet du^^ så viser det seg at det faktisk var en helt legitim ting å diskutere den gangen. Er enig i at det er pointless å diskutere dagens situasjon på samme måte.

 

Poenget den gangen var at storinvistering i 64-bits utstyr ikke hadde noe for seg og det ville være bedre å vente til at dette ble mere implementert slik som nå.

 

Som sagt var hovedargumentet den gangen å være forberedt på å ha mer enn 4Gb minne i maskina. Men som jeg har sagt utallige ganger allerede er det ikke før NÅ at folk faktisk "kan ha bruk for dette". Jeg snakker her selvfølgelig om vanlige forbrukere.

 

Jeg lurer på hvordan du kan være salig overbevist om hva de mener med "the "size" of the processor", og hvordan det beviser at betegnelsen "64-bits CPU" brukes helt feil idag. En 64-bits prosessor har GPRs som er 64 bits brede, og det har ikke eksistert i desktop-segmentet i mer enn noen få år. Slike prosessor kan behandle tallrekker på inntil 64 siffer i en operasjon, og det handler jo om noe helt annen enn kommunikasjonen mellom de forskjellige komponentene.

 

Tja hva skal en si... en prosessor er vel ikke i stand til å gjøre så mye uten kommunikasjon med de andre komponentene her isærs minnet. Derfor kan du ha en 4096 bits GPR med en 8 bits minne bus. Dette ville sikkert bli dundre bra. På den annen side som du nevnte med 386SX (kommer tilbake til dette) ha en 256 bits Data buss (minne buss) og 16 bits registre, og du vil alltid ha ting å jobbe med inne i prosessoren da en unngår wait states o.l. Dette er to eventyr scenariorer, men jeg tror du skjønner pointet. Dette kan bli et større problem på cpu'er med lengre pipelines.

 

Det virker som om du tror at det bare finnes ett eneste grensesnitt for kommunikasjon i hele systemet, men jeg skal gå ut ifra at du mener minnebuss og/eller FSB når du sier "databuss".

 

Databuss er bussen mellom cpu og øvrige enheter (Ikke cache minne og annet som ligger intærnt på CPU). Minnebuss funker bra ;-)

 

La meg få opplyse om at det finnes en rekke busser i systemet, som godt kan ha forskjellige bredder. Hele Pentium 4-serien har for eksempel 256-bits forbindelse mellom L1 og L2, og 64 bits mellom CPU og minnekontroller. Alle disse bussene tjener jo formålet å bringe data til og fra prosessoren, som du ivrig poengterer betydningen av, derfor blir det feil å hele tiden snakke om "bussen" (bestemt form). Og dette sier jo ingenting om hvor mange bits en prosessor er på.

 

Cacheminnet er en del av prosessoren og er ikke det jeg regner for data/minne bussen. Den interne busser mellom de forskjellige komponenetene på cpu'en kan bestå av så mange bits den bare vil. Hvis data/minne bussen er den på 64 bits, hjeper pent lite med 128 bits eller 256 bits buss mellom cpu og cache når du likevel må gjennom en 64 bits bus for å hente de data som du skal behandle. Men er enig at intern behandling av data foregår raskere med større buss bredde (da en er mer sikker på at CPU til en hver tid er opptatt med noe og ikke behøver å vente). Effektiviteten av dette kommer helt an på akkurat hva det er cpu'en skal gjøre. Skal du behandle en rekke tall i vanlig minne (trekke fra 1 eller liknende) og lagre de tilbake igjen er det minnebussen som avgjør hvor fort dette skjer. Skal du derimot hente et tall fra minne, gjøre en masse tunge beregninger med det så er det en fordel å kunne flytte ting kjappt internt i cpu'en. Bottom line; Data bussen er størrelsen på bussen mellom CPU og øvrige enheter.

 

Jeg har forøvrig også til gode å se 64-bits adresse-registre. For eksempel har A64 40-bits fysisk register, og 48-bits virtuelt.

 

Right Er ikke noe å diskutere med dette. en A64 kan ikke adressere 2^64 minne direkte (men med bankswitching kan den adressere så mye den vil i teorien).

 

Er det ikke en selvmotsigelse å samtykke til at 386 er 32-bits, til tross for at den bare har 16-bits databuss? Du hevder jo for harde livet at det er databussen som bestemmer "størrelsen" på prosessoren, samtidig som du bekrefter at en bredere buss kan brukes til å overføre data mer effektivt, uten at det påvirker hvor mange bits prosessorens er.

 

En 386SX har en 16 bits data buss mens en 386 DX har en 32 bits data buss. Sorry for forvirringen. En SX er en 16 bits prosessor og en DX er en 32 bits prosessor. adresse bussen på en sx er 24 bits mens på en DX er den 32 bits f.y.i.

 

Og forresten, siden A64-prosessorer opererer i dualchannel (2x64 bits) betyr vel det at de er 128-bits?

 

What can I say ^^ Greit at AMD har skjønt viktigheten av å supplere CPU'en med data som den kan behandle.

 

Dette blir for svart-hvitt. Det er jo en lang rekke ting som må tas med i betraktningen, og du får det til å virke som om bredden på minnebussen er altoverskyggende. FSB og minnebussen sier ingenting om hvor effektiv cachen er, og det blir helt feil å nærmest konsekvent gå ut ifra at prosessoren må hente data fra main memory. Cachen opererer også på samme klokkefrekvens som CPU, og selv om det er snakk om noen få syklusers forsinkelse (L1) blir det feil å si at cachen er så mye tregere enn CPU. Klokkefrekvens, forsinkelser, prefetching, datarate (pumping), dataorganisering og ørten andre faktorer til de forskjellige leddene av minnehierarkiet kan jo også bety mye mer enn bredden på bussene, alt ettersom.

 

Det er forresten mye mer jeg kunne ha sagt, men har på følelsen at det har liten hensikt å utdype i det uendelige...

 

Helt enig i det siste du sier. Du kan gjøre dette så teknisk og komplisert som du bare vil, sannheten er at så snart CPU har noe å jobbe med så gjør den det kjappt og bra. Må den vente på data så gjør den ikke en dritt.Og det er engang slik at et programm som starter opp lagres førs i main memory og ikke i cachen så vidt jeg vet. Så det må inn der og deretter ut igjen før du kan se effekten av det. DER komme minne/data bussen inn.

[oysfaerg]

Trådstarter: I stedetfor å ^^ skrive ^^ hele ^^ tida ^^ kan du heller oppføre deg litt ^^ saklig og ^^ seriøst. Det er så irriterende å lese at ^^ hele tida ^^.

 

Forøvrig var ikke den andre tråden "frekt stengt", den ble stengt på ett godt grunnlag, noe du selv kunne unngått ved å lage en _SKIKKELIG_ tråd, ikke bare slenge ett utsagn ut i lufta og så si at mitt ord er lov.

 

Og gjør meg en tjeneste - Slutt å rakk ned på alle som sier deg i mot, slutt å kom med utsagn som "Jeg tror nok at han som skrev boka vet mer enn deg ass", det fører ingen vei.

 

Til syvende og sist - Endre emnetittelen før jeg stenger denne tråden også.

[Jaffe]

Dere kan jo krangle så mye dere vil egentlig, tråden er fortsatt helt unødvendig; 64-bits prosessorer er kommet for å bli -- uansett hvor unødvendig det kanskje er med 64-bits prosessorer...

Endret 21. oktober 2006 av Jaffe