Archiv verlassen und diese Seite im Standarddesign anzeigen : unreal engine -> 64bit. wird da id nachziehen?
[EF]peppa
2002-11-21, 01:37:22
laut den 3dc-news( bzw. Planet 3Dnow! (http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1037804171)) vom 20. soll epic die unreal engine an die 64bit architektur vom hammer angepasst haben.
wird da id (und andere? wer noch?) mit der doom3 engine nachziehen?
wieviel performance bringt das?
mfg peppa
nagus
2002-11-21, 08:03:45
Originally posted by [EF]peppa
laut den 3dc-news( bzw. Planet 3Dnow! (http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1037804171)) vom 20. soll epic die unreal engine an die 64bit architektur vom hammer angepasst haben.
wird da id (und andere? wer noch?) mit der doom3 engine nachziehen?
wieviel performance bringt das?
mfg peppa
wahrscheinlich schon (hoffentlich)
zeckensack
2002-11-21, 08:08:35
Bringt schon was. Voraussetzung ist aber auf jeden Fall ein OS mit x86 64-Support. Also das nächste Upgrade von M$ oder eine entsprechende Linux-Distri.
*edit*
Das Hämmerchen selbst läuft natürlich auch mit alten Betriebssystemen, nur liegen dann halt die Erweiterungen brach :)
betasilie
2002-11-21, 13:47:44
Soweit ich weiß hat j.C. mal was positives zu 64bit bei neuen CPUs gesagt. Ich denke mal, da will J.C. seine Vorreiterposition nicht verlieren.
Demirug
2002-11-21, 13:53:28
Wenn nicht so viel in Assembler programiert wurde und man an ein paar bestimmten stellen auf die Datentypen aufgepasst hat sollte es kein alzu grosses Problem sein den Code auf 64 bit umzustellen.
Damit ist AMd auf jeden Fall DER grosse Wurf gelungen. Die allseits beliebte Unreal Engine auf 64Bit - das bedeutet die hälfte der Benchmarks in Reviews sind Hammerfreundlich :D
BlackBirdSR
2002-11-22, 01:38:00
tja die Frage ist ,,was bringts?
selbst im 64Bit Modus bleiben die Long Datentypen per default bei 32Bt.
Man hat zwar doppelt so viele Register, aber hat man auch einen Kompiler der dies ausnutzen kann? Per hand?.. hmm in ner Woche?.
Ansonsten hat man noch Skalares SSE2 welches beim Hammer zwar sehr gut läuft, aber wieviel Skalare SSE2 optimierungen wird die Warfare Engine enthalten?
Und letztenendes haben wir noch die FP Multiplikation die im 64Bit Modues langsamer arbeitet als im 32 Bit Modus, da der Durchsatz halbiert ist.
Die Frage ist da, ob UT2003 für AA64 so viel schneller sein wird?
[EF]peppa
2002-11-22, 02:15:48
das hab ich noch gar nicht bedacht das die compiler ja auch auf 64bit optimiert werden muessen.:stareup:
es gibt datentypen die 64 bit gross sind (8 bytes):
bei c++:
__int64: -2^63 +1 bis 2^63 -1
CURRENCY: -9,22337 · 10^14 bis 9,22337 · 10^14
bei delphi:
Comp: -2^63 + 1 bis 2^63 - 1
Currency: -9,22337 · 10^14 bis 9,22337 · 10^14
da muesste der compiler ebenfalls drauf optimiert sein.
oder mann verwendet assembler und definiert eigene typen.
Ansonsten hat man noch Skalares SSE2 welches beim Hammer zwar sehr gut läuft, aber wieviel Skalare SSE2 optimierungen wird die Warfare Engine enthalten?
sse2 hat bei spielen sowieso fast keinen sinn. sinn hats bei dvd, video,... kurz multimedia!
Und letztenendes haben wir noch die FP Multiplikation die im 64Bit Modues langsamer arbeitet als im 32 Bit Modus, da der Durchsatz halbiert ist.
klingt logisch.
aber (vorsichtige ueberlegung):
in jedem cpu sind techniken eingebaut um rechenoperationen zu vereinfachen (die decoder).
waere es moeglich das der hammer 64bit und extra 32bit fpu's hat? dann koennte der decoder entsprechend filtern. wieviel die-flaeche braucht ein 32bit fpu? bzw wieviel transitoren?
nur so ne ueberlegung.:D
mfg peppa
zeckensack
2002-11-22, 02:32:19
Originally posted by BlackBirdSR
Und letztenendes haben wir noch die FP Multiplikation die im 64Bit Modues langsamer arbeitet als im 32 Bit Modus, da der Durchsatz halbiert ist.Öh :|
Bei Integer-Multiplikationen liegst du richtig.
Bei FP nicht. Alle FPUs spätestens seit dem 387 können 64bittige FP-Zahlen schleudern. Mittlerweile (mit'm Pentium 1) ist die interne Präzision auf 80 Bit gestiegen.
Da wird sich überhaupt nichts ändern. K8 verarbeitet floats (32), doubles (64) und long doubles (80), genau wie der Vorgänger.
[EF]peppa
2002-11-22, 02:37:37
Originally posted by zeckensack
Öh :|
Bei Integer-Multiplikationen liegst du richtig.
Bei FP nicht. Alle FPUs spätestens seit dem 387 können 64bittige FP-Zahlen schleudern. Mittlerweile (mit'm Pentium 1) ist die interne Präzision auf 80 Bit gestiegen.
Da wird sich überhaupt nichts ändern. K8 verarbeitet floats (32), doubles (64) und long doubles (80), genau wie der Vorgänger.
und ich dachte die von mir oben genannten typen werden irgendwie kompliziert aufgeteilt.
EDIT: hiermit aendere ich meine "vorsichtge ueberlegung" von fpu auf integer-multiplikationen:D
[EF]peppa
2002-11-22, 02:41:46
wieso rechnen konsolen-cpu's mit 128bit wenn schon 32bit auf 64bit kein vorteil bringen soll. oder wieso ist ab 80386 32 bit wenn es denn nicht schneller sein sollte?
Originally posted by zeckensack
Mittlerweile (mit'm Pentium 1) ist die interne Präzision auf 80 Bit gestiegen.
Da wird sich überhaupt nichts ändern. Ich hörte, der P4 kann "nur" noch 64 Bit.
zeckensack
2002-11-22, 03:22:02
Originally posted by aths
Ich hörte, der P4 kann "nur" noch 64 Bit. AFAIK rechnet er intern auch noch mit 80 Bit.
Du hast trotzdem Recht, da die 'normale' FPU des P4 eigentlich für die Tonne ist und man FP-Operationen so oft wie möglich auf der SSE2-Einheiten ausführen sollte (geht auch skalar, ie non-SIMD).
Und da hat's dann nur noch 64 Bit.
Originally posted by [EF]peppa
wieso rechnen konsolen-cpu's mit 128bit wenn schon 32bit auf 64bit kein vorteil bringen soll. oder wieso ist ab 80386 32 bit wenn es denn nicht schneller sein sollte?
Eine "128-Bit CPU" rechnet nicht mit 128-Bit-Werten. Was genau diese Bezeichnung aussagt... tja, da scheint irgendwie keine Einigkeit zu herrschen. Interner Datenbus, SIMD-Operationen, Breite der GP-Register...
Der Schritt von 16 Bit (80286) zu 32 Bit (80386) war viel mehr als nur eine Erhöhung der Präzision.
Originally posted by [EF]peppa
das hab ich noch gar nicht bedacht das die compiler ja auch auf 64bit optimiert werden muessen.:stareup:
es gibt datentypen die 64 bit gross sind (8 bytes):
bei c++:
long (ist bei einem 64-bit Compiler 64 Bit breit)
long long (ist auch bei einem 32-bit Compiler 64 Bit breit)
BlackBirdSR
2002-11-22, 10:09:54
DAs meine ich doch Alles nicht was ihr hier aufbringt ;)
@peppa@ALL
Ich habe es nicht extra erwähnt sorry:
DER HAMMER nutzt im 64Bit Long mode per default 32bit longs und 32bit operanden im Generellen.
Nur per override kann man auf 64Bit operanden bestehen.
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Software_Porting_-_Rich_Brunner.pdf
@Z-Bag
Ich weiss dass CPUs mit bis zu 80Bit arbeiten und der Durchsatz dabei gleich belibt.
Aber nach AMD halbiert sich der Throughput im 64Bit Long Modus bei jeglicher 64Bit Operanden FPMUL Operation. Egal ob nun 32bit 64bit oder 80bit Genauigkeit. weswegen die Operanden eben auf 32Bit bleiben und man damit im Long Mode die Performance der FPMUL des 32Bit Modes bekommt (die sogar noch schneller als beim K7 ist).. bla bla bla ;)
@peppa: konsolen:
nutzen zum Großen Teil Vektor CPUs.. diese können 128bit Vektoren bvearbeiten, und werden daher als 128Bit CPUs ausgeschildert.
Allerdings kann das der P4 eigentlich auch (2x64) oder der G4(128 am Stück).
Deswegen ist es an sich keine 128Bit CPU wie sie hier gerade definiert ist.
@SSE2...
beim Hammer hat(soll) SSE2 Skalar ca den 4fachen Durchsatz gegenüber dem P4 bei seinen skalaren SSE2 Operationen.
Das dürfte etwas helfen, da SSE2 Vektor operationen nicht immer leicht zu finden sind.
Dafür schenken sich hammer und P4 bei vektor SSE2 wohl nicht allzuviel.
StefanV
2002-11-22, 13:20:53
Originally posted by Xmas
Eine "128-Bit CPU" rechnet nicht mit 128-Bit-Werten. Was genau diese Bezeichnung aussagt... tja, da scheint irgendwie keine Einigkeit zu herrschen. Interner Datenbus, SIMD-Operationen, Breite der GP-Register...
Der Schritt von 16 Bit (80286) zu 32 Bit (80386) war viel mehr als nur eine Erhöhung der Präzision.
Jo, da wurden noch einige Features wie der Protected Mode hinzugefügt...
Es gibt halt einige Programme, die aufm 286 nicht mehr laufen.
Nicht aus Performance Gründen sondern weil der 286 einige Features nicht beherrschte...
Demirug
2002-11-22, 13:23:38
Originally posted by Stefan Payne
Jo, da wurden noch einige Features wie der Protected Mode hinzugefügt...
Es gibt halt einige Programme, die aufm 286 nicht mehr laufen.
Nicht aus Performance Gründen sondern weil der 286 einige Features nicht beherrschte...
Protected Mode gab es schon beim 286. Der war nur etwas unhandlich in der benutzung. Deshalb wurde er auch beim 386 stark erweitert. Es aber trotzdem noch eine ewigkeit gedauert bis er wirklich benutzt wurde.
Originally posted by Stefan Payne
Jo, da wurden noch einige Features wie der Protected Mode hinzugefügt...
Es gibt halt einige Programme, die aufm 286 nicht mehr laufen.
Nicht aus Performance Gründen sondern weil der 286 einige Features nicht beherrschte...
Nein, den protected mode hat schon der 286 (sonst koennte er auch keine 16MB RAM ansprechen). Neu ist der VM86 Mode beim 386er.
/edit: demi war schneller.:D
betasilie
2002-11-22, 15:37:57
Originally posted by [EF]peppa
wieso rechnen konsolen-cpu's mit 128bit wenn schon 32bit auf 64bit kein vorteil bringen soll. oder wieso ist ab 80386 32 bit wenn es denn nicht schneller sein sollte?
PS2---> CPU 64bit
GC----> CPU 32bit
X-Box-> CPU 32bit
Originally posted by BlackBirdSR
@Z-Bag
Ich weiss dass CPUs mit bis zu 80Bit arbeiten und der Durchsatz dabei gleich belibt.
Aber nach AMD halbiert sich der Throughput im 64Bit Long Modus bei jeglicher 64Bit Operanden FPMUL Operation. Egal ob nun 32bit 64bit oder 80bit Genauigkeit. weswegen die Operanden eben auf 32Bit bleiben und man damit im Long Mode die Performance der FPMUL des 32Bit Modes bekommt (die sogar noch schneller als beim K7 ist).. bla bla bla ;)
Der Betriebsmodus der FPU hat doch absolut gar nichts mit dem 64-Bit-Modus des Hammer zu tun.
BlackBirdSR
2002-11-23, 10:05:20
Originally posted by Xmas
Der Betriebsmodus der FPU hat doch absolut gar nichts mit dem 64-Bit-Modus des Hammer zu tun.
nein ob sie 32bit oder 80bit genau rechnet sicherlich nicht.
Dass sie bei 64Bit Operanden die hälfte des Throughputs einbüßt schon.
Wenn ich jetzt die PDF finden würde.
zeckensack
2002-11-23, 10:39:12
Originally posted by BlackBirdSR
nein ob sie 32bit oder 80bit genau rechnet sicherlich nicht.
Dass sie bei 64Bit Operanden die hälfte des Throughputs einbüßt schon.
Wenn ich jetzt die PDF finden würde. Eins von denen hier (http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_739_7044,00.html)?
Ich bilde mir ein, die alle zumindest überflogen zu haben, aber ich habe nichts dergleichen gefunden ???
BlackBirdSR
2002-11-23, 11:15:21
Originally posted by zeckensack
Eins von denen hier (http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_739_7044,00.html)?
Ich bilde mir ein, die alle zumindest überflogen zu haben, aber ich habe nichts dergleichen gefunden ???
nein das stand in einer dieser Präsentationen, nicht in den Programing Manuals.
Naja ich frag mal nach ;)
Originally posted by BlackBirdSR
nein ob sie 32bit oder 80bit genau rechnet sicherlich nicht.
Dass sie bei 64Bit Operanden die hälfte des Throughputs einbüßt schon.
Wenn ich jetzt die PDF finden würde.
Bei 64-Bit Operanden? Die gibts doch eh nur vom Speicher aus, was langsamer ist. Die Werte auf dem FPU-Stack sind doch immer 80-Bit, aber wie schnell/genau gerechnet wird hängt eben vom FPU-Betriebsmodus ab.
BlackBirdSR
2002-11-23, 12:05:03
Originally posted by Xmas
Bei 64-Bit Operanden? Die gibts doch eh nur vom Speicher aus, was langsamer ist. Die Werte auf dem FPU-Stack sind doch immer 80-Bit, aber wie schnell/genau gerechnet wird hängt eben vom FPU-Betriebsmodus ab.
um die 80BitFPU 64Bit SSE2 und 32Bit SSE gehts doch gar nicht.. es sei denn ich verstehe nicht auf was du hinauswillst ;)
zeckensack
2002-11-23, 12:36:42
Originally posted by BlackBirdSR
um die 80BitFPU 64Bit SSE2 und 32Bit SSE gehts doch gar nicht.. es sei denn ich verstehe nicht auf was du hinauswillst ;) Er will darauf hinaus, daß alle Fließkommazahlen im Prozessor 80bittig sind. Weil das eben die Registerbreite der x87-FPU ist.
Von daher kann die Unterscheidung 32/64/80 sowieso nur auf Speicheroperanden zutreffen, nicht auf Reg/Reg-Operationen.
BlackBirdSR
2002-11-23, 12:43:34
Originally posted by zeckensack
Er will darauf hinaus, daß alle Fließkommazahlen im Prozessor 80bittig sind. Weil das eben die Registerbreite der x87-FPU ist.
Von daher kann die Unterscheidung 32/64/80 sowieso nur auf Speicheroperanden zutreffen, nicht auf Reg/Reg-Operationen.
naja.. wenn man zu blöd zum lesen ist hat mans eben schwer ;)
ich hab die PDF gefunden uns ich hab mich vertan.
Aus FMUL wird mal eben schnell IMUL... sorry.
Also, IMUL ist beim Hammer im 32Bit Modues schneller da doppelter Durchsatz bei 3 vs 5 Taktzyklen.
Im 64Bit Modus geht dieser Vorteil verloren.
DIe Register sind dann selbst im 64Bit Long Mode 32Bit breit...
also Sorry für den Aufstand -> weiter gehts mit IMUL :D
:O Link vergessen http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Optimization_-_Tim_Wilkens.pdf
zeckensack
2002-11-23, 12:47:09
Aha!
Sag' ich doch :D
Originally posted by zeckensack
Öh :|
Bei Integer-Multiplikationen liegst du richtig.
Bei FP nicht.
:P
;)
BlackBirdSR
2002-11-23, 13:03:17
Originally posted by zeckensack
Aha!
Sag' ich doch :D
:P
;)
schande über meine Tragflächen
:bäh:
Brillus
2002-11-24, 01:57:58
Bei der umstellung von 16 auf 32 wurde nicht Primär die Präzisson erhöht sonder der möglich Arbeitsspeicher bei den 16Bitter waren es 1MB (eigentlich müssten es 64kb sein aber da hat Intel etwas getricks weis aber nicht genau wie)bei den Heutigen 32 Bit Prozessorn sind es 4Gbyte und bei dem Hammer wären es rund 16000000Terrabyte.
Ps nach meinem wissen ist der GC 64bit kann aber wenn der Progrmmierer es will statt einer 64 Bit berechnung 2 32Bit Berchnungen machen.
Legolas
2002-11-24, 02:08:13
Originally posted by Brillus
Bei der umstellung von 16 auf 32 wurde nicht Primär die Präzisson erhöht sonder der möglich Arbeitsspeicher bei den 16Bitter waren es 1MB (eigentlich müssten es 64kb sein aber da hat Intel etwas getricks weis aber nicht genau wie)bei den Heutigen 32 Bit Prozessorn sind es 4Gbyte und bei dem Hammer wären es rund 16000000Terrabyte.
Getrickst wurde da eigentlich nicht. es wurden ganz einfach mehr Adressleitungen für den Hauptspeicher realisiert. Nämlich 20 beim 8086 (entspricht 1MB RAM) und 24 beim 80286 (entspricht 16MB RAM). Soviel ich weiß nutzt der Hammer nicht 64 Leitungen für die Speicheraddressierung, aber 100%ig sicher bin ich mir da nicht.
BlackBirdSR
2002-11-24, 11:13:18
Originally posted by Legolas
Getrickst wurde da eigentlich nicht. es wurden ganz einfach mehr Adressleitungen für den Hauptspeicher realisiert. Nämlich 20 beim 8086 (entspricht 1MB RAM) und 24 beim 80286 (entspricht 16MB RAM). Soviel ich weiß nutzt der Hammer nicht 64 Leitungen für die Speicheraddressierung, aber 100%ig sicher bin ich mir da nicht.
40 physikalisch 48Bit virtuelle adressierung.
reicht auch..
64Bit ist einfach zu übertreieben und kostet nur
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.