Nye Intel Centrino lansert

[MrLee]

poenget her var å illustrere at eksempelet ditt var litt feil.

 

Du bruker ikke MER båndbredde for å legge sammen 0001 og 0001 på en 64bit maskin i forhold til en 32bit maskin...det er bare mer båndbredde tilgjengelig.

 

Selvsagt vet også jeg at det ikke er så mange programmer som bruker 64bit enda. Men hva er grunnen til det? at det ikke er vits med det enda, eller at ett 64bit OS ikke har blitt allmennt utbredt (jeg sikter da til Windows XP 64bit edition)? :=)

5742584[/snapback]

Jo du bruker dobbelt så mye RAM, CPU til RAM båndbredde og cache kapasitet når du opererer med 64bit integer verdier som når du opererer med 32bit. Det finnes mange eksempler på at kompilering til 64 bit i stedet for 32 bit har medført lavere ytelse fordi en får cache trashing. I noen tilfeller får en også båndbredde problemer mot minnet, men det er mindre vanlig da integer kode som oftest ikke er veldig utsatt for dette problemet og FP kode blir gjerne lite påvirket av 32/64bit forskjellen i integer datatypene.

 

selvfølgelig... jeg tenkte bare på datamengden gjennom selve CPU...

[Babelfisken]

poenget her var å illustrere at eksempelet ditt var litt feil.

 

Du bruker ikke MER båndbredde for å legge sammen 0001 og 0001 på en 64bit maskin i forhold til en 32bit maskin...det er bare mer båndbredde tilgjengelig.

 

Selvsagt vet også jeg at det ikke er så mange programmer som bruker 64bit enda. Men hva er grunnen til det? at det ikke er vits med det enda, eller at ett 64bit OS ikke har blitt allmennt utbredt (jeg sikter da til Windows XP 64bit edition)? :=)

5742584[/snapback]

 

Eksempelet er ikke feil tror jeg. Bruker man 64bit så bruker man 64 bit. Nå er ikke jeg noen ekspert på nyere mikroprosessor-teknologi men om dette ikke er helt endret vil alle registere og alle minneforespørsler være på 64 bit. Dersom 90% av instruksjonene hadde klart seg med 32bit eller mindre er dette et enormt sløseri med båndbredde. I begrepet båndbredde legger jeg da også inn bruk av minnepalss.

 

Det er heller ikke et spørsmål om å bruke 64bit i programmer eller ikke. De data programmene behandler endres ikke, de har sine definerte størelser og man fyller bare opp med luft for å "bruke" 64 bit. Når 64bit-programmer etter hvert ser verdens lys vil de fleste i beste fall vil operere like raskt som deres forgjengere (gitt at men ikke har gjort andre optimaliseringer i koden som også deres 32bits forgjengere ville hatt like stor bruk av.) Dette gjelder selvsagt ikke alle programmer. Bergningsprogrammer og kodeker vil til en viss grad kunne nytte seg av 64bit og kjøre raskere. Jeg vet ikke hvilket presisjonsnivå spill operer på man antar at de i fremtiden vil kunne øke bildekvaliteten med 64bit uten at det går vesentlig utover fps, så der vil det nok også kunne ventes en bedring, men jeg ville ikke holdt pusten.

 

Selv om dette ikke er x86 maskiner gir dette en pekepinn

http://www.osnews.com/story.php?news_id=5768&page=3

 

- Omtrent like raske med et lite forsprang for 32bit

- større exe filer på 64bit

- høyere minnebruk på 64bit

[Babelfisken]

  selvfølgelig... jeg tenkte bare på datamengden gjennom selve CPU...

5746048[/snapback]

 

som altså er dobelt så stor, men inneholder mest "luft".

[MrLee]

Jo, men så er de laget for det (altså selve CPU'en). Så jeg ser ikke problemet med at de skal kunne eksekvere 64bit kode selv om det er "mest luft" i data som går gjennom dem. Poenget var vel at hvis en CPU er skalert til å ta 64bit kode, så blir den jo ikke akkurat "straffet" ytelsesmessig for det (om man ser på CPU isolert sett). Tror ikke den ville jobbet raskere om den ikke hadde de ekstra 32 bit bredden...?

[MrLee]

dobbeltpost.

Endret 15. mars 2006 av MrLee

[Babelfisken]

Jo, men så er de laget for det (altså selve CPU'en). Så jeg ser ikke problemet med at de skal kunne eksekvere 64bit kode selv om det er "mest luft" i data som går gjennom dem. Poenget var vel at hvis en CPU er skalert til å ta 64bit kode, så blir den jo ikke akkurat "straffet" ytelsesmessig for det (om man ser på CPU isolert sett). Tror ikke den ville jobbet raskere om den ikke hadde de ekstra 32 bit bredden...?

5757435[/snapback]

 

Nei det har du rett i. CPUen ville neppe vært noe raskere om den brukte 32bit, men mye tyder på at reursene rundt cpu, og disse er det som kjennt knapphet på både hva gjelder størelse og hastighet, lider under 64bit koden. Dermed blir totalen et tregere system.

 

Jeg har ikke noe i mot 64bit men når jeg om et år eller så kjøper ny CPU med 64bit er nok det kun fordi den har 2 kjerner og intern minnekontroller, ikke fordi den er på 64 bit :-)

[MrLee]

nei selvsagt ikke. tror ikke akkurat at 64bit støtten var særlig utslagsgivende for at jeg kjøpte X2 3800+, ei heller integrert minnekontroller....

 

men det er jo litt merkelig at intel, som til nå har gått over til 64bit støtte på alle desktopmodellene, lanserer en helt ny kjerne til bærbare uten...? Det har jo en viss markedsføringsverdi...

[Anders Jensen]

Jo, men så er de laget for det (altså selve CPU'en). Så jeg ser ikke problemet med at de skal kunne eksekvere 64bit kode selv om det er "mest luft" i data som går gjennom dem. Poenget var vel at hvis en CPU er skalert til å ta 64bit kode, så blir den jo ikke akkurat "straffet" ytelsesmessig for det (om man ser på CPU isolert sett). Tror ikke den ville jobbet raskere om den ikke hadde de ekstra 32 bit bredden...?

5757435[/snapback]

En kan bygge 32bit prosessorer med høyere klokkehastighet enn 64bit prosessorer, git at alt annet er likt (samme mikroarkitekturprinsipp bare smalere, samme CMOS prosess og samme termiske og elektriske egenskaper). F.eks. en multiplekser, svitsj, buss FPU eller ALU vil kunne operere på høyere frekvens jo smalere den er.

Endret 15. mars 2006 av Anders Jensen

[benlen]

ja kanskje vi bør gå tilbake til 16bit?

 

(beklager dårlig natt humor)