64-bit avmystifisert

[balleklorin]

Er det ikke positivt at en kan flytte dobbelt så mye data på en instruksjon da? En mov instruksjon kan jo flytte 64 bit i steden for 32 bit.. Noe av vinningen går vel opp i spinningen også ettersom tall-data av ulike regneoperasjoner ofte vil kreve mer IO pga flere bit som må flyttes, men strengoperasjoner burde få et boost på 64bit (i teorien iallefall), hvis en ikke tenker alt for mye på minnet som en flaskehals. 64bit burde gi muligheter for høyere IO skulle jeg tro.

[snorreh]

Er det ikke positivt at en kan flytte dobbelt så mye data på en instruksjon da? En mov instruksjon kan jo flytte 64 bit i steden for 32 bit.. Noe av vinningen går vel opp i spinningen også ettersom tall-data av ulike regneoperasjoner ofte vil kreve mer IO pga flere bit som må flyttes, men strengoperasjoner burde få et boost på 64bit (i teorien iallefall), hvis en ikke tenker alt for mye på minnet som en flaskehals. 64bit burde gi muligheter for høyere IO skulle jeg tro.

Joda, men glem heller ikke at siden man dobler antall registre i 64-bit modus (for x86-64) så kan også flere data lagres midlertidig noe som reduserer I/O-bruken og dermed øker også ytelsen generelt sett.

Endret 12. januar 2005 av snorreh

[DesertGlow]

DesertGlow: Fin artikkel, men du glemmer dessverre å nevne at AMD64-arkitekturen faktisk dobler antall dediserte registre (GPR) fra 8 stk. i 32-bit (x86/IA32) til 16 stk. i 64-bit (x86-64/AMD64). 8 stk. nye 128-bit SSE-registre er også lagt til, samt 64-bits utvidelser av registrene for flagg og instruksjonspekere (se vedlagt bilde). Dette betyr utvilsomt bedre ytelse på det aller meste. Til forskjell så har ikke de fleste andre arkitekturene som har gått fra 32-bit til 64-bit øket antall registre (f.eks. Power, SPARC, PA-RISC).

Har ikke glemt noe. Jeg snakker ikke her om arkitekturer, men om den generelle forskjellen mellom 32 og 64-bit. Har forøvrig så vidt nevnt det med flere registere i 64-bit mouds, men har i denne artikkelen har som hensikt å forklare forskjellen isolert sett, ikke arkitekturiske forskjeller AMD har valgt å legge inn samtidig. Men du har selvsagt helt rett i det du sier.

[tbend]

Drit bra artikkel....

 

Da lærte jeg noe nytt i dag også!

[Kimmer]

Har ikke glemt noe. Jeg snakker ikke her om arkitekturer, men om den generelle forskjellen mellom 32 og 64-bit.

Hei,

 

Vi venter spennt på en artikkel om AMD64's ytelser med Windows kommende 64bits operativ system (som nok ikke kommer før 2006 - hvis vi kender Microsoft rett).

Du har ikke nevnt eet ord om disse foreløbige tester der ligger på ute på nettet - men du har fått med dig DivX's egne uttalelser om 20% ytelsesforbedringer.

 

PS. Bare lurer på hvordan en artikkel (om samme emne) hadde set ut, hvis den var skrevet av han andre Intel-testeren her på hw.no?

 

Mvh

Kimmer

Endret 12. januar 2005 av Kimmer

[DesertGlow]

Har linket til tester fra både Anandtech og Ace's Hardware i denne testen, så jeg må si meg uenig i at jeg kun stoler på DivX-utviklernes uttalelser.

 

Forøvrig kan jeg ikke se at denne testen går hverken i Intel eller AMDs favør... Til tross for at jeg tester AMD-systemer har jeg absolutt ikke et horn i siden til Intel. Bruker Intel-laptop daglig, og venter nå på to nye Intel-maskiner, til eget bruk.

[magnusr]

Hei er det ikke feil i mattematikken i denne artikkelen? Ellers god artikkel

 

De skriver: En prosessor kan i utgangspunktet ikke adressere flere byte lagringsplass enn antall bit den selv opererer med

 

De skriver: Med en 64-bits prosessor kan man i prinsippet adressere opp til 2^64 byte, altså omtrent 18 petabyte med data.

 

Hm 2^64 blir 18446744073709551616 som skulle være a 18,44EB (exabyte) ?

 

De sa da altså petabyte. Det er jo bare ca 1/1000 del av hva en virkelig 64 bits cpu klarer å adressere?

[Ni kon]

På veien av en god venn og en som har litt mer peil enn de fleste:

 

http://www.aceshardware.com/forums/read_po...19163&forumid=1

 

Skulle hilse spesielt til Simen1.

[b0nna]

Han klarte ikke holde seg unna nei?

klemz

Endret 12. januar 2005 av b0nna

[Kimmer]

Har linket til tester fra både Anandtech og Ace's Hardware i denne testen, så jeg må si meg uenig i at jeg kun stoler på DivX-utviklernes uttalelser.

 

Hei,

 

Finner ingen linker til tester fra AnandTech og den linken til testen fra Ace's Hardware er 15 måneder gammel! (fra september 2003).

Der er dog trods alt sket svert mye siden da.

 

Mvh

Kimmer

Endret 12. januar 2005 av Kimmer

[CFD]

Windows anbefaler 1.5 ganger størrelsen av ram til SWAP, hvor 2.5 er kommet fra er jeg ikke sikker på. Det var da en voldsom stor swapfil da i tilfelle...

Nå har det seg slik at microsoft har gått tilbake på dette også. Microsoft blander også pagefile og swapfile, så man skal ikke ta alt som kommer ifra den fronten som fakta (selvom det er på sitt produkt). Muligens de har fjernet det ifra sine websider siden jeg spurte dem om hva som var riktig for en god stund siden..

 

Det finnes flere gode guider om akkurat dette på nettet og den på ARP er definitivt den beste.

 

DEL: Jeg sa ikke at noe ville passe til alle ,men at du skulle åpne aplikasjoner også se hvor mye det krever. Er sjelden en felles løsning passer like bra for alle

Endret 12. januar 2005 av CFD

[Gjest Slettet+9018234]

Lite nytt her, men det er supert med litt mythbusting til de store lesermassene.

[Simen1]

På veien av en god venn og en som har litt mer peil enn de fleste:

http://www.aceshardware.com/forums/read_po...19163&forumid=1

Skulle hilse spesielt til Simen1.

Så hyggelig. Godt å høre at han i det minste leser på forumet her. Du får hilse tilbake om han ikke leser dette.

 

Fint å få en avklaring på det jeg spurte om også. Ang. negative tall i en 2x32bit ADD så skal det gå fint for begge tallene så lenge sunnen av tallene er under 2^31-1. Tall er jo ofte definert med det første tegnet som fortegn. Dermed blir hele tallet inkludert fortegn 2^32. For å ikke vippe rundt skalaen så må summen inkludert fortegnet aldri overstige 2^32-1.

 

Jeg glemte å nevne at det sikkert er flere operasjoner som kan gjøres i form av 2x32bit eller 4x16bit i samme sleng med 64bit instruksjoner. Det er ikke bare ADD men også SUB+ADD (Dvs. det samme som ADD 2x32 + flipp fortegnet til det første tallet), AND, OR, NOR og XOR. Sikkert flere også, men MUL og DIV går f.eks ikke an å gjøre dette trikset på.

 

Så lenge programmereren er klar over at ikke noen av tallene overstiger 2^31-1 så slipper man å lage noe som sjekker dette på forhånd og sparer dermed noen sykluser. Evt. at de ikke overstiger 2^15-1 hvis man gjør 4x16bit sammenslåtte instruksjoner.

 

Så vidt jeg husker så gjøres de enkle operasjonene jeg nevnte på bare 1 klokkesyklus i 64bit i K8. I 32bit modus gjør K8 også dette på 1 klokkesuklus, men tar altså bare halvparten så mange bit og bruker dermed 2 klokkesykluser + minst 2 klokkesykluser ekstra for å hente frem de riktige tallene til GPR. Dermed vil akkurat disse operasjonene kunne gå unna 4 ganger så raskt i 64bit modus som i 32bit modus. (Så fremt det lar seg kjøre paralellt).

 

Jeg vet ikke om kompilatorer har slike triks innebygget eller om man må håndskrive slikt. Programmereren bør også vite helt klart hvilke grenser tallene holder seg innenfor.

[MailMan13]

Fint å få en avklaring på det jeg spurte om også. Ang. negative tall i en 2x32bit ADD så skal det gå fint for begge tallene så lenge sunnen av tallene er under 2^31-1. Tall er jo ofte definert med det første tegnet som fortegn. Dermed blir hele tallet inkludert fortegn 2^32. For å ikke vippe rundt skalaen så må summen inkludert fortegnet aldri overstige 2^32-1.

For logiske operasjoner som ikke innebærer skift er det helt problemfritt, men du vil få et problem med aritmetiske operasjoner dersom det 'nederste' tallet bytter fortegn, i stedet for at tallet bikker rundt og får satt fortegn flyter det som skulle være fortegn over i det 'øverste' tallet slik at det blir en for stort.

 

f.eks vi ønsket å gjøre disse to i en operasjon(2x4bits addisjon)

    1110 (-2)  0011 (3)
+ 0100 (4)   0100 (4)
= 0010 (2)   0111 (7)

Leser vi den inn med det negative tallet først i et 8bits register får vi:

    0011  1110
+ 0100  0100
= 1000  0010

 

Den første addisjonen (-2) + 4 blir riktig, men fortegnet som her normalt skulle gå til overflow blir lagt til den andre slik at man får 3 + 4 = 8, i grensetilfeller kan man også få resultater som 8+7=0 uten at vi er i stand til å detektere overflow.

 

Jeg vil tro at i den grad slike teknikker brukes er det nok kun brukbart for positive heltall som alltid er < 2^32/2, for større tall og negative tall blir vanskelig å være sikker på hva vi gjør.

Endret 14. januar 2005 av MailMan13

[LOZER]

Takker meget for denne artikkelen!

[Kenneth Dammyr]

Kan vi, og isåfall når vente oss 128bits prosessorer?

[DesertGlow]

De er allerede på markedet, det samme med 256-bit, men det er høyst tvilsomt om det skjer på de nærmeste 20 årene på desktop-markedet. Det er ikke bare å pøse på med antall bit og tro at man vil få en ekstrem ytelsesøkning. Det er fordeler og ulemper ved å øke antall bit.

[snorreh]

Vi venter spennt på en artikkel om AMD64's ytelser med Windows kommende 64bits operativ system (som nok ikke kommer før 2006 - hvis vi kender Microsoft rett).

Du har ikke nevnt eet ord om disse foreløbige tester der ligger på ute på nettet - men du har fått med dig DivX's egne uttalelser om 20% ytelsesforbedringer.

Windows x64 er enda ikke ferdig ennå og er fortsatt kun tilgjengelig som beta/release candidate, så det er altfor tidlig å konkludere med noe her selv om det virker som du har gjort det for lenge siden

 

Her er noen nylige smakebiter iallefall:

 

Nearing Completion: Windows XP Professional x64 Edition RC1

 

AMD Athlon64 - 64-bit vs. 32-bit, A Head On Comparison

 

PS. Bare lurer på hvordan en artikkel (om samme emne) hadde set ut, hvis den var skrevet av han andre Intel-testeren her på hw.no?

Du er ikke lite frekk hvis du antyder at DesertGlow ikke er objektiv til den han her skriver, da tror jeg heller du skal sette pekefingeren på deg selv

 

Finner ingen linker til tester fra AnandTech og den linken til testen fra Ace's Hardware er 15 måneder gammel! (fra september 2003).

Der er dog trods alt sket svert mye siden da.

Nye prosessorer har kommet og gått, men ingen arkitekturer har forandret seg vesentlig på så kort tid (kun mindre mikroarkitektoniske endringer som SSE3).

 

Her er forøvrig linken til testen hos Anandtech som jeg antar det er snakk om (fra august 2004):

http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=2

Endret 14. januar 2005 av snorreh

[Kimmer]

Finner ingen linker til tester fra AnandTech og den linken til testen fra Ace's Hardware er 15 måneder gammel! (fra september 2003).

Der er dog trods alt sket svert mye siden da.

Nye prosessorer har kommet og gått, men ingen arkitekturer har forandret seg vesentlig på så kort tid (kun mindre mikroarkitektoniske endringer som SSE3).

Hei,

 

Man trenger ikke å være særligt oppegående for at forestille sig, at der er sket svert mye (de sidste 15 måneder) med utviklingen av Win64 og ikke mindst drivere dertil.

 

Takker for linkerne.

 

Mvh

Kimmer

[snorreh]

Man trenger ikke å være særligt oppegående for at forestille sig, at der er sket svert mye (de sidste 15 måneder) med utviklingen av Win64 og ikke mindst drivere dertil.

 

Takker for linkerne.

Joda, og det viser også den GamePC-testen jeg linket til over. Mesteparten av utviklingen har likevel skjedd på 64-bit Linux som denne meget grundige testen foretatt av HARDiNFO.dk viser:

 

32-bit vs. 64-bit Linux

På trods af at Microsoft endnu ikke har deres 64-bit udgave af Windows ude endnu, er x86-64 bestemt ikke ubrugeligt. Som vores benchmarks har kunnet vise, giver 64-bit (og særligt de ekstra registre) en stor fordel i meget CPU-intensive applikationer. Langt størstedelen af alle applikationer, vil med fordel kunne omskrives (reelt vil dette kun være nødvendigt for ganske få applikationer - resten vil kunne understøtte x86-64 ved blot at blive compileret til denne platform) til at understøtte x86-64.

 

Vores tests har vist at 64-bit virkelig er en fordel, og at man vil kunne forvente et ydelsesløft fra applikationer, der direkte understøtter dette instruktionssæt.

Endret 16. januar 2005 av snorreh