64-bit avmystifisert

[Boralis]

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.

Jepp, sørgelig at de mest seriøse finner det best å dra herfra, han var og er den med mest peiling uansett .

[idos]

Kjørte 3Dmark05 i både windows XP SP2 og Winows XP 64bit edition .1218

 

Hadde ca 40% bedre ytelse i CPU -scoren

 

http://www.da-lan-e.com/3dmark05.htm

 

sjekk linken for mer.

 

Uansett. Ytelsen var generelt litt bedre i 64 bit selv om 32 bit "vant" i canyon flight

[snorreh]

Jeg var ikke klar over at det fantes en 64-bit versjon av 3DMark05...?

[Aalton]

Jeg var ikke klar over at det fantes en 64-bit versjon av 3DMark05...?

ikke jeg heller

[idos]

Vel ikke vet jeg.

Lasta ned den vanlige versjonen fra futuremark og installerte i begge OS'ene. Egentlig Bare for å sjekke de "nye" 64 bits beta driverne til ATI. Disse gav litt bedre ytelse enn 4.12. Det som er mer spennende/rart er den vesentlig høyere CPU scoren. Kjører 3Dmark05 faktisk i 64 bit eller er det andre årsaker til dette ??

[martiol]

Når det gjelder å kjøre multiple data på en instruksjon i A64 ALUen tror jeg ikke det har noen reell ytelsesgevinst. Først og fremst pga ekstra linjer i programmet for å sette sammen disse tallene. Man sparer en instruksjon men bruker 3...

 

Ytelsesøkning i 64bit mode kommer IKKE av større registre, men at det er fler registre og andre forbedringer av instruksjonssettet. Det er tross alt en ny modus med nye instruksjoner i prosessoren. Noen av disse kan bare hoppe over decode-stadiet i prosessoren pga optimaliserte instruksjoner.

 

Litt sent men... hehe. Det er så mange rare meninger rundt disse prosessorene så det nesten litt håpløst å prøve å diskutere det. hehe

[Slither]

jaja.... min AMD64 ser i alle fall penere ut enn den gamle athlon XP'en

[EMM386]

Selv om det fremdeles vil ta litt tid før 64-bits OS/software blir "stuerent", er det likevel bare fordeler med å ha en 64-bits CPU nå. Neste gang man kjøper nytt nå (1.5 - 2 år) blir det gamle systemet en utmerket 64-bits server, med rimelig utprøvd/stabil OS og programvare. Tror verdien på denne hardwaren vil holde seg lenger enn det som har vært normalt.

[Pygar]

Ja, dette er interessant, og det gir opphav til mange nye spørsmål, som f.eks. hvordan en klarer å lage en 64 bit prossessor som henger med i 32 bits modus. Fannt ut at min Intel 3,2 brenner like mye strøm som hovedlysene på bilen. Kan si det går unna så det lukter svidd!

[Simen1]

Ja, dette er interessant, og det gir opphav til mange nye spørsmål, som f.eks. hvordan en klarer å lage en 64 bit prossessor som henger med i 32 bits modus.

Det høres ut som du ikke har fulgt helt med, siden 64bit prosessorer som yter utmerket i 32bit har eksistert i et par år allerede: Opteron, og 1,5år: Athlon64 og Athlon64FX, og ca 0,5år: Pentium4 J-serien.

 

Alle disse yter identisk med sine 32bit brødre i 32bit modus. Forskjellen er bare at de takler 64bit modus i tillegg. Et såkalt hybrid.

[Del]

Når det gjelder å kjøre multiple data på en instruksjon i A64 ALUen tror jeg ikke det har noen reell ytelsesgevinst. Først og fremst pga ekstra linjer i programmet for å sette sammen disse tallene. Man sparer en instruksjon men bruker 3...

Hvorvidt det er flere programlinjer betyr vel i utgansgspunktet ingenting, det er sluttresultatet kompilatoren produserer som avgjør om du må gjøre noen omveier. Du kan se for deg at du håndterer et 64-bit integer som en vektor bestående av to 32-bit integer (hvis problemet ditt tillater det). Å holde styr på mente tror jeg er en avsporing her, for eksempelets skyld kan du jo nøye deg med 2x31-bit, og la siste bit bli hva den vil. Med andre ord du trenger ingen ekstra linjer, du trenger i utgansgspunktet bare å reformulere problemet ditt (hvis problemet tillater det), å kode det deretter. Så for enkelte problemer forundrer deg meg mye om ikke det er mulig å utnytte 64-bit til å speede opp prosesseringen, tror snart jeg må sette meg ned å kode en snutt selv, bare for å få dette endelig bekreftet (vi diskuterer jo tross alt noe som ikke dreier seg om synsing, enten går det, eller så går det ikke).

 

Ellers er jeg helt enig i at det er mange meninger om disse prosessorene.

[Pygar]

Den største gevinsten ligger i adresseutregning som påpekt. I tillegg kan den kjøres i "protected modus" og kjøre 32 bits program.

[Del]

Når det gjelder mine ønsker om å utnytte 64-bit integer til å gjøre to integer add, trekker jeg meg. I prinsippet kan man utnytte alle 64 bit men det vil ikke være hensiktsmessig untatt for veldig speisaliserte problemer og implementasjoner. Spill-over som følge av "mente" ødelegger generell praktisk anvendelse.

 

Adressegevinsten er vel alle enige om, men jeg har sett vitenskapelig programvare optimalisert for AMD64 med betydelige gevinst som ikke kan tilskrives minneadressering, vil vel kanskje heller anta at det skyldes god utnyttelse av SSE registre, evt. SSE utvidelser som det stadig kommer fler av.

[Simen1]

Når det gjelder mine ønsker om å utnytte 64-bit integer til å gjøre to integer add, trekker jeg meg. I prinsippet kan man utnytte alle 64 bit men det vil ikke være hensiktsmessig untatt for veldig speisaliserte problemer og implementasjoner. Spill-over som følge av "mente" ødelegger generell praktisk anvendelse.

Jeg husker ikke hvordan denne eldgamle diskusjonen endte tidligere i tråden, men jeg får hoste opp litt av det gamle argumentet mitt: Hvis man på forhånd vet at det den minst signifikante 32bit ADD-operasjonen i 64bit ADD-operasjonen ikke ender med noe mente så tror jeg det kan brukes. F.eks en full 32bit ADD + en 31bit ADD = en 64bit ADD uten menteproblemer.

 

Men det kreves jo litt ekstra jobb fra programmereren å sette seg inn i om kriteriet for problemløs mente er oppfyllt eller ikke. Kompilatorer vil neppe benytte dette trikset. Så det vil nok forbli en skjeldenhet i bruk. Selv 32 + 16bit ADD vil kunne skape problemer hvis man ikke vet at antall etterfølgende add er mindre enn 2^16 slik at ikke menten rykker oppover for hver add og ødelegger 32bit ADD-operasjonen etter 2^16 ADD. Men det hadde jo vært litt tøft om man fikk kompilatorer til å sjekke kriteriene automatisk og dermed kunne benytte denne muligheten titt og ofte.

[Anders Jensen]

Googling etter "bit slicing" anbefales for denne diskusjonen. Å kjøre 2x32 bit i 64bit GPR er fullt mulig men det gjelder bare for spesialtilfeller av vektoriserbar kode (altså et spesialtilfelle av et spesialtilfelle...). I praksis vil en bruke SIMD registrene (for de prosessorene som har egne SIMD registre) og SIMD instruksjonene i alle de tilfellene hvor en kan vektorisere, så det kan jo diskuteres hvor relevant dette er.

 

En må også være nøye med datastrukturen for at dette skal kunne gjøres effektivt. Om en må pakke inn/ut to 32bit int til en 64bit int så har en ikke tjent noe som helst. Det må komme direkte ut av datastrukturen for å være effektivt. Om det ikke gjør det så måtte en ha scratch/gather registre for ut/inn pakking på effektivt vis. Det er det bare vektorprosessorer som er utstyrt med i dag og det ville neppe vært særlig effektivt på SIMD ettersom en gjerne oppererer på relativt få elementer i forhold til vektorprosessorer.

Endret 18. september 2005 av Anders Jensen