Gå til innhold

Er 64 bits nødvendig?


tommen

Anbefalte innlegg

Gjest Slettet+3124

Jeg skal ikke blande meg inn i denne diskusjonen, men jeg klarte ikke dy meg. Jeg ser ikke helt poenget med denne tråden altså. Jeg ser på denne som iherdig forsøk på lage en "flame war" tråd alla "hva er best av Nvidia vs. ATI" greier, eller "Amd vs. Intel".

 

Japp, dette var mitt bidrag..

Lenke til kommentar
Videoannonse
Annonse

Hehehe. Artig tråd.

 

Men ettersom databussen visstnok forteller hvor mange bits en cpu er på. Hvilken innvirkning får DDR og QDR på dette? P4 er jo et godt eksempel her. Den har en databus på "bare" 64 bits (QDR). Allikevel klarer denne databussen på "bare" 64 bits å overføre lik mengde data som en minnebuss på 128bit (2x64 bit, DDR). Hva skal man kalle disse CPUene da? er de 64 bits, 128 bits (siden de overfører lik mengde data som en 128 bit eller 2x64 bit minnekanaler), eller er de 256bit (ettersom bussen er 64bit QDR)?

 

Target

Lenke til kommentar

Å diskutere om hvilken betydning x86-64 har i forhold til x86 er noe annet enn å diskutere 32 bit vs 64 bit. Så vidt jeg har forstått så er en av ulempene med x86 få og små registere, noe som kunne forandres med et utvidet instruksjonsett, men uten at denne nødvendigvis baserte seg på 64 bit. AMD som utviklet det bestemte seg imedlertid får at når man uansett ville prøve å forandre x86-instruksjonsettet, var 64 bit i diverse registere og regneengeter noe man også kunne ta med, da man uansett trengte nye kompilatorer og programvare får å utnytte det nye instruksjonsettet.

 

Altså, x86-64 vs x86 har flere forskjeller enn kun 64 bit vs 32 bit. Hva er det du egentlig vil diskutere / er så sint for?

Lenke til kommentar
Å diskutere om hvilken betydning x86-64 har i forhold til x86 er noe annet enn å diskutere 32 bit vs 64 bit. Så vidt jeg har forstått så er en av ulempene med x86 få og små registere, noe som kunne forandres med et utvidet instruksjonsett, men uten at denne nødvendigvis baserte seg på 64 bit. AMD som utviklet det bestemte seg imedlertid får at når man uansett ville prøve å forandre x86-instruksjonsettet, var 64 bit i diverse registere og regneengeter noe man også kunne ta med, da man uansett trengte nye kompilatorer og programvare får å utnytte det nye instruksjonsettet.

 

Altså, x86-64 vs x86 har flere forskjeller enn kun 64 bit vs 32 bit. Hva er det du egentlig vil diskutere / er så sint for?

7117997[/snapback]

 

Intruksjonssettet er da nesten likt på både x86-64 og x86 (Intel kaller det vel strengt tatt IA-32 og IA-32e). Husk; registrene er ikke en "del" av instruksjonssettet. Instruksjonssettet er bare en rekke instruksjoner man bruker for å bruke registrene. Det er litt uklart hva tommen vil frem til egentlig, men han svarer vel ganske raskt.

Endret av Jaffe
Lenke til kommentar
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 ^^.

 

? Irriterende ? La vær å les da.

 

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.

 

Føler vel at hvis ikke folk hadde vært så trigger happy og en får sjans til å fosvare sine utsagn ahdde det ikke vært noe problem.

 

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.

 

Dette var ikke et forsøk på å rakke ned på noen som helst. Jeg pekte på en konkret kilde til min påstand, og den andre karen gjorde det ikke. Hadde han gjort det så hadde jeg heller ikke hatt noe å si! Så langt er det vel ikke så mye som jeg ikke har kunne vært i stand til å dokumentere?

 

 

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

7117607[/snapback]

 

Hmm.. alright. Noen gode forslag til hva jeg bør kalle tråden da? Jeg lager et nytt og så kan jeg endre igjen hvis noen har noe bedre.

Lenke til kommentar
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...

7117613[/snapback]

 

Når det gjelder tråden i seg selv er det interressant å diskutere forskjellige aspekter ved utviklingen som kanskje ikke så mange tenker over. Om det er noe for alle og enhver er tvilsomt men for noen få kanskje.

 

Faktumet at dagens prosessorer er kommet for å bli er det ikke tvil om. Jeg prøver på ingen måte i si imot utviklingen, bare peke på noen av de negative sidene ved dette.

 

Det jeg sier i mot er at dette var et must for 2 år siden.

 

Men nå er det snart helg og arbeidstida er snart over (gidder ikke å skrive her på fritida :D ).

Lenke til kommentar
Hehehe. Artig tråd.

 

Men ettersom databussen visstnok forteller hvor mange bits en cpu er på. Hvilken innvirkning får DDR og QDR på dette? P4 er jo et godt eksempel her. Den har en databus på "bare" 64 bits (QDR). Allikevel klarer denne databussen på "bare" 64 bits å overføre lik mengde data som en minnebuss på 128bit (2x64 bit, DDR). Hva skal man kalle disse CPUene da? er de 64 bits, 128 bits (siden de overfører lik mengde data som en 128 bit eller 2x64 bit minnekanaler), eller er de 256bit (ettersom bussen er 64bit QDR)?

 

Target

7117832[/snapback]

 

Dette skal jeg ikke svare hardnakket på.

 

Men jeg tør påstad at siden prosessoren kan ta imot 256 bits (4x64bits) på en gang så er bussens totale størrelse på 256 bits.

 

Kanskje noen hvet dette bedre en meg eller har noen kilder på dette!?

Lenke til kommentar
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 ^^.

Jeg har bare observert ^^ 3 ganger i alle hans poster i denne tråden. Overdriver du ikke litt?

 

Men kanskje 64-bit ikke burde bli reklamert for til massene, da de fleste ikke vil aktivt bruke muligheten. Sikkert mer relevant for 2 år siden, men så kan vi være glade for at vi har 2 konkurrenter som holder ut i CPU-markedet i dag.

Lenke til kommentar
Å diskutere om hvilken betydning x86-64 har i forhold til x86 er noe annet enn å diskutere 32 bit vs 64 bit. Så vidt jeg har forstått så er en av ulempene med x86 få og små registere, noe som kunne forandres med et utvidet instruksjonsett, men uten at denne nødvendigvis baserte seg på 64 bit. AMD som utviklet det bestemte seg imedlertid får at når man uansett ville prøve å forandre x86-instruksjonsettet, var 64 bit i diverse registere og regneengeter noe man også kunne ta med, da man uansett trengte nye kompilatorer og programvare får å utnytte det nye instruksjonsettet.

 

Altså, x86-64 vs x86 har flere forskjeller enn kun 64 bit vs 32 bit. Hva er det du egentlig vil diskutere / er så sint for?

7117997[/snapback]

 

Intruksjonssettet er da nesten likt på både x86-64 og x86 (Intel kaller det vel strengt tatt IA-32 og IA-32e). Husk; registrene er ikke en "del" av instruksjonssettet. Instruksjonssettet er bare en rekke instruksjoner man bruker for å bruke registrene. Det er litt uklart hva tommen vil frem til egentlig, men han svarer vel ganske raskt.

7118053[/snapback]

 

 

Du har helt rett jaffe. Instruksjonssetter er ikke utvidet til 64 bits op-koder. Det hadde vært upraktisk med tanke på plass og det faktum at det er rimelig tøfft å finne på 2^64 stk forskjellige OP-koder :D

 

Når det gjelder hva det "ultimate" poenget er (og jeg er da ikke sint libido, bare liker å diskutere litt røfft ;-)) , skal jeg si det her:

 

Det var bare tull å gå til anskaffelse av "64 bits" prosessorer for 2 år siden da en til og med i dag ikke kan utnytte de noe særlig med de unntak som nevnt tidligere. Hovedargumentet den gang var å kunne adressere mer en 4Gb noe som var tull (mener jeg). Å kunne behandle 64 bits integer blir det samme som å behandle 16 bits integer i et 32 bits register. Ingen spesiell vits hvis en holder seg innenfor de originale 16 bittene.

 

men dette får folk være enig i eller ikke. Denne tråden har blitt til en slags diskusjon om definisjonen på hvor stor en prosessor er og de tekniske implikasjonene "64 bits" har.

 

Som sagt. Helgen er her så vi fortsetter på mandag :thumbup:

Lenke til kommentar

Det er fortsatt en meningsløs tråd. Og med det at du sier at det var bare tull å gå til anskaffelse av 64-bits prosessorer for to år siden: javel. Hva hjelper det å klage på det nå?

 

Man får snart ikke kjøpt 32-bits prosessorer lenger, så hva er da problemet ditt? Det er bare å vende seg til det -- 64-bits prosessorer er kommet for å bli, og erstatter 32-bits prosessorer, selv om du kanskje syns det er unødvendig.

Lenke til kommentar
Jeg kan jo tilføye at WinXP 64-bit faktisk _ER_ raskere enn 32-bit i applikasjoner, spill og benchmarks.

7118548[/snapback]

Vel, det har ikke akkurat noe med overgang til 64bit å gjøre. Det har nok noe med at M$ måtte skrive kjerna på nytt, og da blir koden litt bedre enn et lappeteppe ala. 32bits-kjerna.
Lenke til kommentar
Jeg kan jo tilføye at WinXP 64-bit faktisk _ER_ raskere enn 32-bit i applikasjoner, spill og benchmarks.

7118548[/snapback]

Vel, det har ikke akkurat noe med overgang til 64bit å gjøre. Det har nok noe med at M$ måtte skrive kjerna på nytt, og da blir koden litt bedre enn et lappeteppe ala. 32bits-kjerna.

7118951[/snapback]

 

Nei, men det har noe med det trådstarter prøver å få frem.

Lenke til kommentar

Om du tror microsoft skrev om kjernen for å porte over til 64-bit tror jeg du bommer "litt." Microsoft skrev NT kjernen som cross-hwplatform og future-proof (nye cpu'er, f.eks. en fremtidig 64-bit erstatter for intels 32bit plattform). Hvordan de gjorde det? Skrev mesteparten av NT kjernen i "pure"(microsoft extension added seff.) c (og senere c++) og targeted som første cpu i860 cpu'en. Så porta de over til 80386'ene for å være sikker på å oppnå de målsetningene de hadde. Porteringa over til intel's x86-arkitektur krevde kun en total rewrite av de aller laveste lagene i kernelen. Resten var i pure c og måtte bare compiles for rett cpu. Samme skjedde når microsoft gikk løs på x86_64 utgave.

Endret av johneinar
Lenke til kommentar

I følge Intel.com så er alle prosessorene i 386-familien 32-bits. Jeg stoler mer på de som faktisk har designa prosessoren enn en random fyr på et diskusjonsforum. :p At en prosessor har 16, 32, 64, 128, whatever-databuss betyr ingen ting. Pentium (1) har 64bits databuss men den kan ikke kjøre 64-bits kode. 386sx har 16-bits databuss og KAN kjøre 32-bits kode.

 

Kilde: En PDF-fil fra www.intel.com

Endret av sedsberg
Lenke til kommentar
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.
Det har jo ingenting med definisjoner å gjøre, og jeg må visst gjenta at du fokuserer altfor mye på bredden til bussen.

 

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.
Selvfølgelig hjelper det. Har du hørt om prefetching? Vet du hvor mange execution units en moderne CPU har? Og hvis det ikke hjelper, hvorfor brukes det ressurser på å designe det da?

 

Ikke bare det, men minnet vil aldri komme i nærheten av båndbredden til cachene, av opplagte grunner. Så det ligger altså underforstått i det du sier at minnet opererer på CPU-fart, siden bredden til cache-linkene og FSB må samsvare...

 

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.
Data behandles ikke i minnet, og går heller ikke direkte fra minnet til registrene (execution core), og tilbake til minnet. Data fetches først fra minne til cache.

 

Bortsett fra i tilfeller hvor flere prosessorer deler samme minne, har det ingen isolert betydning hvor raskt minnet oppdateres. Skrivekommandoer er i prinsippet "fire & forget" sett fra prosessorens ståsted.

 

Data bussen er størrelsen på bussen mellom CPU og øvrige enheter.
Jeg gjentar: Det finnes flere busser, ikke bare internt på CPUen, men også i hele systemet. Se for eksempel på A64 som har to uavhengige busser i minnebussen og HyperTransport. Det må være vanskelig å vite hvor mange bits en prosessor er på, når det er så mange busser med forskjellige karakteristikker rundt omkring... Og hvis man flytter prosessoren over i et annet hovedkort hvor brikkesettet og bussene er forskjellige kan man jo til og med ende opp med å oppgradere prosessoren... :whistle:

 

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.
Intels konvensjonelle 80386-serie er 32-bits. Punktum.

 

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.
AMD-prosessorer har for den saks skyld ikke behov for høy båndbredde, og benytter ikke aggressiv prefetching, så dualchannel hjelper lite på loaded latency. Men ifølge din logikk er jo A64 på 128 bits... Eller kanskje 256 bits siden minnet er dualpumped...

 

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.
Når det er snakk om å starte opp et program er det banalt å i det hele tatt trekke frem minneeffektiviteten. Forskjellene vil bli nærmest fullstendig overskygget av forsinkelsen til harddisken (og i noen tilfeller andre enheter).

 

Og for n'te gang, du fortsetter å overdrive bredden på bussen, og ignorerer klokkefrekvens, forsinkelser, interleavings-teknikker, prefetching, dual/quadpumping, osv osv. Det er bare å velge - det er en drøss med andre ting som kan gjøres, og bredden på FSB/minnebuss sier ingenting om hvor mange bits prosessoren er på. Sånn er det bare.

 

Men ettersom databussen visstnok forteller hvor mange bits en cpu er på. Hvilken innvirkning får DDR og QDR på dette? P4 er jo et godt eksempel her. Den har en databus på "bare" 64 bits (QDR). Allikevel klarer denne databussen på "bare" 64 bits å overføre lik mengde data som en minnebuss på 128bit (2x64 bit, DDR). Hva skal man kalle disse CPUene da? er de 64 bits, 128 bits (siden de overfører lik mengde data som en 128 bit eller 2x64 bit minnekanaler), eller er de 256bit (ettersom bussen er 64bit QDR)?

 

Target

7117832[/snapback]

Dette skal jeg ikke svare hardnakket på.

 

Men jeg tør påstad at siden prosessoren kan ta imot 256 bits (4x64bits) på en gang så er bussens totale størrelse på 256 bits.

7118238[/snapback]

Akkurat, så da er Pentium 4-serien på hele 256 bits... :no:

 

På den andre siden var det en lettelse å se at du endelig virker å innse at det ikke bare er antallet linjer på FSB som avgjør hvor effektiv kommunikasjonen er...

Lenke til kommentar

For en meningsløs flammetråd. Håpløst å komme med et slikt angrep på 64bit uten å gi noen skikkelig begrunnelse for hvorfor du ønsker å sverte det så inn i granskaugen. Jeg lurer egentlig på hvorfor du kommer med dette utbruddet.

 

Bare for å ta tak i noen tvilsomme uttalelser først:

 

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.

7112422[/snapback]

Det går ikke siden det er en grunnleggende måte instruksjonssettet fungerer på. Hvis det blir flere registere i 32bit modus så vil en rekke programmer ikke fungere og den hypotetiske prosessoren vil ikke være kompatibel med x86 32bit. Man kunne kanskje tenkt seg at man bygger opp et komplett nytt instruksjonssett via tillegg som SSE-modulen, men det høres svært lite praktisk ut. Særlig når grensa på 32 bit nærmet seg med stormskritt.

 

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.

7113582[/snapback]

Så du mener at et høyt antall eksekveringsenheter og hvordan de er koblet internt, latencyer, L1 og L2 cahce osv bare er moderne vissvass uten noen nyttig funksjon?

 

Selv Kentsfield med sine 4 kjerner får ikke noen merkbar ytelseforbedring ved å øke FSB. Kilde.

 

Forøvrig så mener jeg at 64bit ikke er strengt tatt nødvendig, men det er kjekt å ha. Det gir rundt 15-20% bedre ytelse i godt kompilerte programmer (altså ikke intel-kompilator på programmer som skal kjøres på AMD-prosessorer siden intel-kompilatoren effektivt slår av 64bit modus dersom den oppdager at det er en AMD-prosessor. Med andre ord et feigt slag under beltestedet fra intel.). 15-20% bedre ytelse er ikke nødvendig, men det er kjekt å ha. Når det gjelder minnemengden så er det fortsatt svært skjeldent nødvendig med mer enn 4GiB på en desktop-PC, men på serversiden gir det mer mening, både nå og når 64bit kom for 3,5 år siden. Det finnes en rekke serverapplikasjoner som har god bruk for mer minne uten bruk at ytelsebremsen PAE som fantes på PIII og P4 og serverversjonene av disse.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...