Gå til innhold

64-bit avmystifisert


Anbefalte innlegg

Videoannonse
Annonse

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 ?? :hmm:

Lenke til kommentar
  • 3 uker senere...

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

Lenke til kommentar
  • 1 måned senere...

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.

Lenke til kommentar
  • 2 måneder senere...

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 :whistle: så det lukter svidd!

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

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

Lenke til kommentar
  • 3 måneder senere...

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.

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

Lenke til kommentar

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 av Anders Jensen
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...