klärt mich BITTE auf: 64bit oder 32bit - Seite 4

Seite 4 von 5 - Forum: Prozessoren auf overclockers.at

URL: https://www.overclockers.at/prozessoren/klaert_mich_bitte_auf_64bit_oder_32bit_120481/page_4 - zur Vollversion wechseln!

d0lby schrieb am 28.07.2004 um 23:25

also... jetzt kann ich sagen, dass ich mal einen wichtigen eindruck habe. jetzt check ich das mal circa ab und kann mi rmal vorstellen was da genau abgeht

thx ... trotzdem
wem was einfällt
rein damit gg

ins schrieb am 29.07.2004 um 13:34

so eine frage darfstt du in so einem forum niemals stellen , weil du immer 50 verschiedene antworten mit ca 10 verschieden meinungen bekommst
winxp simuliert bei applikationen 64bit wobei in wirklichkeit alles auf 32 bit basis läuft..
win2k3 server edition is das erste windows das 64 bit unterstützt .. und es ist gut
während ich mit winxp bei 3dmark 2003 in winxp nur ~11000pts,hab ich mit win2k3 ~14000 .. markanter unterschied also zwischen unsrem "heutigen" 64 bit und dem echten

that schrieb am 29.07.2004 um 14:02

Zitat von ins
winxp simuliert bei applikationen 64bit wobei in wirklichkeit alles auf 32 bit basis läuft..
win2k3 server edition is das erste windows das 64 bit unterstützt .. und es ist gut

Wo ist denn dieses Gerücht her?

Derzeit gibts nur 32 Bit Windows, sowohl von XP als auch Server 2003 (wo wird da 64 Bit "simuliert"?). Die 64 Bit Versionen von XP und Server 2003 sind als Beta erhältlich und sollen irgendwann nächstes Jahr offiziell herauskommen.

fresserettich schrieb am 29.07.2004 um 21:54

Zitat von smashIt
genau für diesen fall ist aber die FPU zuständig

stimmt eigentlich nicht eigentlich wird hier die int-unit beansprucht ich glaube alu schimpft sich das ding
habe ich früher auch immer geglaubt aber vor kurzer zeit hat mich da sys aufgeklärt
--> drum fragen an ihn für warum,wieso

SYSMATRIX schrieb am 30.07.2004 um 12:32

Zitat von smashIt
genau für diesen fall ist aber die FPU zuständig, und die arbeitet selbst auf einer 32bit cpu mit bis zu 64bit (ich glaub mal gehört zu haben das sogar bis 80bit möglich sind)

du redest nehm ich mal an sowieso von x87 FPUs:

IEEE 754 floats werden in 80bit IEEE like floats seit 80x87 zeiten gespeichert um operanden vor und zurück zu wechseln ohne präzision für IEEE 754 double und single precision zu verlieren.

SSE/2/3 verwenden IEEE 754 floats und umgehn den x87 stack.
und IEEE 754 floats definieren 32bit für single precision und 64bit für double precision.

wobei IEEE 754 eine mantissa(M)+significant(N) darstellung ist.

also kann eine x87 FPU 3 modi:
IEEE 754 single (M=8, N=24), IEEE 754 double (M=11, N=53) und IEEE 754 like extended precision (M=15, N=64).

zusätzlich dazu gibt es halt noch SSE und SSE assited FP register die aber auch ints ALU-like behandeln (64bit MMX und 128bit packed SSE register)

das gesamte register file hat 128 einträge mit oder 8 MMX (64bit) register und 8(16 jetzt?)XMM (SSE) register die jeweils bei 128bit 4*32 oder 2*64 und bei 64 1*64 und 2*32bit gepakt sein können.

beren64 schrieb am 28.08.2004 um 17:17

Der letzte post ist zwar schon eine paar Wochen her, ich bin aber erst jetzt darauf gestoßen, da ich mir auch bald einen neuen PC anschaffen möchte und das wird wohl ein Laptop mit Athlon64 sein.
Es ist auch schon viel, teilweise verwirrendes, gesagt worden aber mir fällt auch noch etwas zum Thema ein, obwohl ich kein Spezialist bin.

Zuerst möchte ich zustimmen, dass es quatsch ist, dass ein 64-Bit-Rechner genauer rechnet. Wie Sysmatrix oben "verständlich" drauf hin gewiesen hat, gibt nach IEEE Definitionen durch wieviel Bit eine Zahl repräsentiert wird. Auch eine 32-Bit-CPU kann mit 64-Bit-Zahlen rechnen, sie muss sie dann nur aufteilen. Wie beim Addieren großer Zahlen von Hand. Da addiert man auch jede Ziffer einzeln, mit 1 im Sinn usw. Deswegen könnte eine 64-Bit-CPU auch schneller rechnen, da sie das nicht muss oder zumindest weniger.
Das Aufteilen übernimmt jetzt aber die Software. Und wenn die nicht weis, dass sie auf einem 64-Bit-Rechner läuft, dann weis sie auch nicht, dass sie sich das Aufteilen sparen kann und rechnet z.B. eine 64-Bit-Addition immer noch in zwei Schritten. Deshalb nützt die 64-Bit-CPU ohne unterstüzende Software gar nichts.

Ich weis jetzt aber nicht wie SSE & CO die 32-Bit-CPU tunen, um dann doch schneller rechnen zu können und den Unterschied damit wieder kleiner ausfallen lassen. Wenn ich das richtig verstanden habe, können mit diesen Erweiterungen auch heute schon arithmetrische Operation (+ -) mit 64 Bit gleichzeitig ausgeführt werden.

Ich werde mir als nächstes einen Athlon64 kaufen. Denn ich denke auch Mircosoft kommt demnächst mit Windows 64 in die Pötte. Und sonst gibt es ja auch noch Linux. Bei den Workstations sind 64 Bit auch schon seit ein paar Jahren verfügbar. Und deswegen glaube ich, dass 64Bit kommen werden. Ob der Otto-Normal-Verbraucher allerdings noch mehr Computer braucht als es heute schon gibt, ist sowieso eine andere Frage.

@smashIt, Es müssen nicht immer große Zahlen sein. Auch zwischen 1 und 2 gibt es unendlich viele Zahlen.

smashIt schrieb am 28.08.2004 um 19:54

Zitat von beren64
@smashIt, Es müssen nicht immer große Zahlen sein. Auch zwischen 1 und 2 gibt es unendlich viele Zahlen.

nicht im integer-bereich, auf den sich die 64bit beziehn

Ich din nicht so der profi was die ganzen erweiterungen wie simd, 3dnow und so betrift. aber wenn ich mich nciht irre sind die nur 32bit. können aber mehrere operationen gleichzeitig ausführen.

Ringding schrieb am 29.08.2004 um 02:20

SSE2 verwendet 64bittige floating point-Zahlen (double).

smashIt schrieb am 29.08.2004 um 03:59

wie schon gesagt wir reden hier übern integer teil. die fpu war schon immer ein thema für sich.

abgesehn davon hengt ob double 64bit ist oder was anderes von der programmiersprache ab. iirc is das bei c, c++ nicht genormt. bei den interpretierten sprachen wie java allerdings schon.

SYSMATRIX schrieb am 30.08.2004 um 11:56

bitte smashit hör auf hier zu posten, es wird einem ja schlecht wie viel falsches du postest.

edit:
der k8/a64 ist eine 3 weg super-scalar MPU, der core kann AFAIR 3 CISC (x86) instruktionen mit multiplen (>2) quellen und operanden pro maschinenzyklus ausführen.

allgemein gesehen kann man x86 instruktionen als f(register, register), f(register, memory) bzw vize versa betrachten. der erste operand ist immer quelle und ziel zugleich. f(register, register) und f(register, memory) sind typisch für integer, MMX und SSE2 operationen. die integer pipline handelt aber load/stores für _alle_ operationen(inkl. SSE2/MMX und "gewöhnliche" IEEE 754 extended precision floats)

die K8 MPU hat noch eine zusätzliche instruktionsklasse: double dispatch instructions. oder auch "doubles" genannt. diese doubles werden gegen ende der decodierstufe der pipline erzeugt und werden in zwei separate instruktionen geteilt. die 3-way super-scalar pipeline kann deshalb eigentlich 6 instruktionen per maschinenzyklus ausführen. die instruktionen werden am ende der "pack"-stage wieder rücktransformiert.

fast alle 128 bit SSE und SSE2 und jetzt denn halt auch SSE3 sind als "double dispatch" instruktionen implementiert. instruktionen die nicht in zwei separate 64 bit instruktionen gesplittet werden können, werden ganz gewöhnlich vom uCode sequenzer verarbeitet.

das ergibt für 128bit SSE instruktionen sowohl vorteile als auch nachteile, ein nachteil ist zB daß die decodierungsrate von SSE instruktionen auf 1.5 pro zyklus fällt (was aber nicht sonderlich schlimm ist da die FP units und die ausführungshardware nur eine 128bit SSE instruktion per zyklus handeln können)

im pentium 4 werden SSE instruktionen erst später in der FPU selbst zerlegt und die FPU ist auch in der lage 128bit source daten zu akzeptieren, dann wird die instruktion zerlegt und am ende in ein 128bit resultat gepackt. -> ein extra zyklus muß eingeschoben werden.
x87 FADD und FMUL brauchen 5 und 7 zyklen respektive während die 128bit (2x64bit) SSE2 äquivalenten instruktionen 6 zyklen und 8 zyklen brauchen.

K8 und K7 handeln FADD und FMUL in 4 zyklen, die SSE2 pendants brauchen auch nur 4 zyklen. sprich 1 zyklus entfällt hier mindestens -> ~ 25% weniger latency -> sehr wichtig für piplined d-signs da diese am meisten an höhreren latencies leiden.

der prescott hat angeblich eine zusätzliche hardware FADD und FMUL einheit welche die latencies für FMUL FADD wider auf 5 und 7 zyklen bringen. -> _wesentlich_ höhere FP bandbreite!!

im k8 werden double dispatch instruktionen eben auch für integer instruktionen wie PUSH und POP verwendet. auch FP instruktionen die einen integer als operand haben werden als double dispatch instruktionen implementiert und sind somit schneller als ihre normalen uCode conterparts.

zusätzlich kann der L1 data cache zwei unabhängige 64bit load/stores von unterschiedlichen aderessen ausführen! -> was das leben der compiler leute doch vereinfachen kann.

d0lby schrieb am 30.08.2004 um 12:45

oida oida
:bash:
wozu hab eich das jemals gefragt

30 Beiträge und 29 davon sind unterschiedlich.
soll ichmir jetzt einen richtigen rauspicken?
wenn es wenigstens 5 oder 6 ähnliche beträgegeben würd, könnte man sich eventuell etwas darunter vorstellen.

tun hier die meisten als ob sie so viel ahnung hätten?

argl

nach den 30 unterschiedlichen Meinungen und Erklärung der Unterschiede kann man ja nur noch verwirrter werden

.dcp schrieb am 30.08.2004 um 12:57

das liegt daran, dass man ein so komplexes thema nicht mit 5 sätzen erklären kann, und auch wenn ich hier nicht mitreden kann, weis ich dass einige hier (sys, ringding) soviel ahnung von der materie haben, dass sie sicher nix falsches posten

SYSMATRIX schrieb am 30.08.2004 um 13:12

Zitat von dolby
oida oida

wozu hab eich das jemals gefragt

30 Beiträge und 29 davon sind unterschiedlich.
soll ichmir jetzt einen richtigen rauspicken?
wenn es wenigstens 5 oder 6 ähnliche beträgegeben würd, könnte man sich eventuell etwas darunter vorstellen.

tun hier die meisten als ob sie so viel ahnung hätten?

argl

nach den 30 unterschiedlichen Meinungen und Erklärung der Unterschiede kann man ja nur noch verwirrter werden

ja, weil man mit einer birnen und apäfel und fingern mentalität halt nicht alles erklären kann, manche aber nur birnen und äpfel verstehen

edit: 0wned.

gue schrieb am 01.09.2004 um 23:31

Zitat von SYSMATRIX
-> sehr wichtig für piplined d-signs da diese am meisten an höhreren latencies leiden.

Warum?

SYSMATRIX schrieb am 02.09.2004 um 10:07

deep piplined d-signs in action mögen hohe instruction latencies nicht da diese viele bubbles erzeugen und man wenig instructions in diesen pipelines sieht. geringere instruction latency bringt hier deutliche vorteile.