Archiv verlassen und diese Seite im Standarddesign anzeigen : Wird durch 64 Bit (x86-64) tatsächlich alles schneller (Beispiel Far Cry)?
Sith_TirEilo
2004-10-13, 18:20:56
Hi,
der Bericht in der aktuellen PCGH (11/04) über die für 64Bit optimierte Version von Far Cry, hat ja für einiges Aufsehen gesorgt. Nun frage ich mich, ob denn durch x86-64 (und nur druch x86-64) wirklich 32Bit Software schneller wird?
Im folgenden gehe ich mal "nur" von 32Bit (normaler x86 Code) Software aus, die für x86-64 (im folgenden als 64Bit bezeichnet) portiert wird. Das 64Bit gut und sinnvoll ist will ich hier gar nicht in Frage stellen, sondern mir geht es ehr um die Frage inwiefern portierte 32Bit Software von 64Bit profitiert und vor allem (aus der technischen Sicht) warum dies so ist. Also bitte keinen Flamewar über den Sinn von 64Bit starten ;)
Die PCGH schreibt dazu, das der Athlon64 über 16 Integer- und 16 SSE2-Register verfügt, jedoch im 32 Bit Betrieb nur 8 davon genutzt werden. Dadurch entstand wohl auch der größte Performanceschub in der 64Bit Version von Far Cry. Die restlichen Leistungsteigerungen entstehen dann durch Optimierungen.
Was genau kann man unter solchen Optimierungen verstehen? Wäre z.B. eine Schleife, die mehr als 4,2 Millarden mal ( > 32Bit Integer) durchläuft, bei der man dann zwei Schleifen bräuchte (eine von 0-4,2Mill, und eine die den Rest abdeckt), bei 64Bit eben nur eine, bei der der Schleifenzähler dann > ~4,2 Millarden werden dürfte. Oder was kann man unter solchen 'Optimierungen' verstehen?
Nehmen wir mal an der Athlon64 könnte in 32Bit, genau wie in 64Bit, alle 16 Integer- und SSE2-Regsiter nutzen würde sich dadruch der Geschwindigkeitsvorteil nicht (erheblich?) relativieren? Demnach könnte man den Geschwindigkeitsvorteil aufgrund der zusätzlich Register doch nicht direkt der 64 Bit Erweitrung anrechnen. Mehr Register bedeuten doch das mehr Datenwörter (ob 32Bit oder 64Bit ist doch eigentlich egal) in der CPU gehalten werden können, ergo muss weniger in die Caches (bzw. dann im RAM, danach dann auf die Platte ins Swap File) ausgelagert werden. Auslagern dauert ja immer relativ lange, ergo bleibt bei weniger Auslagerungen die CPU "kürzer" untätig, wodruch sich ein Vorteil in der Geschwindigkeit ergibt. Aber das kann man doch nicht der 64Bit Erweiterung anrechen, da es doch IMHO unabhängig von der Regsiterbreite ist, oder doch? Vielleicht kann das ja mal jemand genauer ausführen, der davon mehr versteht.
Ein weiter Punkt ist doch, daß z.B. eine Schleife von 0-500 nicht unbedingt schneller druchläuft nur weil mit 64Bit gerechnet wird. Außerdem braucht der Athlon64 AFAIK im 32Bit Mode 3 Takte für die Multiplikation, bei 64 Bit sind es 5 Takte (Quelle c't, genaue Ausgabe muss ich raussuchen). So gesehen bringt dort 64 Bit doch erstmal gar nichts, oder übersehe ich da was? Wohlgemerkt alles auf protierte 32 Bit Anwendungen bezogen.
Des weiteren werden Gleitkommazahlen (doppelte Genauigkeit) schon immer in 64 Bit berechnet, also würde ich sagen, daß dort 64 Bit auch keine Verbesserungen, im Sinne von Geschwindigkeitsvorteilen, mit sich bringt, oder ist das falsch (wenn ja warum?)?
Also irgendwie blick' ich da nicht so wirklich durch. Ich hoffe da kann mich mal jemand drüber aufklären, wie das intern aussieht (und hoffentlich habe ich nicht zuviel Mist geschrieben ;)).
Grüße,
Sith
StefanV
2004-10-13, 18:24:38
nein, 32bit Software wird nicht wirklich schneller.
Die läuft aber auch nicht wirklich langsamer.
Sobald ein Programm aber auf x86-64 umgesetzt wird, sind schon recht starke Steigerungen möglich, miest so um die 20%, unter umständen auch mehr, je nach dem, wie gut der Hersteller Hand an legt.
Hauptsächlich dürfte die Steigerung der verdoppelten Anzahl an Integer und SSE GPRs sein...
Sith_TirEilo
2004-10-13, 18:50:34
Hi,
Sobald ein Programm aber auf x86-64 umgesetzt wird, sind schon recht starke Steigerungen möglich, miest so um die 20%, unter umständen auch mehr, je nach dem, wie gut der Hersteller Hand an legt.
Hauptsächlich dürfte die Steigerung der verdoppelten Anzahl an Integer und SSE GPRs sein...Dann kann man die Steigerung, also nicht der 64 Bit Erweiterung des Athlons anrechnen, sondern den zusätzlich zur Verfügung stehenden Registern!?
Achtung Fiktion:
Angenommen AMD bringt einen A64 raus bei dem man auch im 32 Bit Modus die zusätzlichen Register nutzen könnte, würde sich dort der Geschwindigkeitsvorteil dann nicht deutlich verringern bzw. fast verschwinden? (Wenn nein warum nicht?)
Wahrscheinlich ne dumme Frage, aber warum hat AMD nicht die zusätzlichen Register auch im 32 Bit Modus freigeschaltet? Der A64 würde dadurch doch noch schneller werden, was AMD doch nur reicht sein kann?
Grüße,
Sith
zeckensack
2004-10-13, 19:18:49
Was genau kann man unter solchen Optimierungen verstehen?Da gibt's nicht viel zu beachten.
1)die zusätzlichen Register ausnutzen, um somit Speicher- und Cache-Zugriffe zu reduzieren; so weit waren wir ja schon :)
Das lässt man am sinnvollsten den Compiler machen.
2)konsequent SSE2 nutzen. Jeder x86-64-Prozessor hat SSE2. Ich will dich jetzt nicht mit Details nerven, aber die "alte" x87-FPU hat einige Macken im Design, die allesamt Effizienz kosten. Das geht so weit, dass Microsoft Code für die klassische FPU nicht mehr "duldet", dh solche Software läuft auf WinXP64 nur innerhalb der 32 Bit-Kompatibilität, nicht aber als "nativer" 64 Bit-Prozess.
3)Manipulation langer Integer entsprechend anpassen. Das betrifft fast ausschliesslich Kryptographie und Numerik-Spielchen, dürfte für Endanwender allerdings keinerlei Nutzwert haben (kürzere Laufzeiten in SuperPi würde ich nicht unbedingt als "Nutzwert" bezeichnen btw).
Davon abgesehen wüsste ich nicht was man sonst noch groß "optimieren" könnte. Es gelten die gleichen Spielregeln wie für alle anderen modernen x86-Prozessoren auch: baue kompakten Code, verschwende keinen Speicher, pass auf die Caches auf, halte "Prefetch" im Hinterkopf, sei sparsam mit branches, etc. Nichts davon gilt allerdings nur für den K8, das sind ganz universelle Weisheiten.
Nehmen wir mal an der Athlon64 könnte in 32Bit, genau wie in 64Bit, alle 16 Integer- und SSE2-Regsiter nutzen würde sich dadruch der Geschwindigkeitsvorteil nicht (erheblich?) relativieren?Kann er nicht. Darf er auch nicht können, denn er soll ja gerade vollständig zu 32 Bit-Software (OS+Applikationen) kompatibel bleiben. Ein 32 Bit-OS weiss aber nicht, dass der Prozessor mehr ISA-Register hat, und deswegen werden sie bei Thread-Wechseln auch nicht gesichert. Es würde im Desaster enden. Du könntest theoretisch einen einzigen Thread laufen haben, der mehr als die acht "bekannten" x86-Register nutzt. Sobald du einen zweiten startest, würde unweigerlich mindestens einer sofort wieder absemmeln.
Diese Übung bleibt auch theoretisch, weil sowas niemand haben will, und deswegen die "neuen" Register im 32 Bit-Modus nicht verfügbar sind.
Demnach könnte man den Geschwindigkeitsvorteil aufgrund der zusätzlich Register doch nicht direkt der 64 Bit Erweitrung anrechnen.Doch. Es ist eine gravierende Änderung an der ISA, und sowas macht man nicht einfach so aus Jux. Du müsstest für mehr Register alleine genauso ein neues OS nehmen, und genauso die Applikationen neu kompilieren, wie jetzt für den vollen 64 Bit-Modus des K8. Nur dafür wäre das aber zu viel Aufwand.
Es ist durchaus sinnvoll, sich solche Änderungen aufzusparen, bis man ein ordentliches Paket zusammenhat, und dann alles auf einen Rutsch einzuführen. Also einerseits ja, die Registerzahl hätte man auch irgendwie ohne 64 Bit-Fähigkeiten erhöhen können, andererseits nein, du bekommst es aktuell nur im Paket mit 64 Bit, und nur weil der K8 sowieso einen gesondert unterstützenswerten Betriebsmodus (eben die 64 Bit ...) hat.
Ohne 64 Bit-Erweiterung wären die Chancen quasi gleich Null, die nach außen sichtbare Registeranzahl zu erhöhen (und die meinerseits sehr erfreuliche ABI-Änderung "red zone" einzuführen btw).
Ein weiter Punkt ist doch, daß z.B. eine Schleife von 0-500 nicht unbedingt schneller druchläuft nur weil mit 64Bit gerechnet wird. Außerdem braucht der Athlon64 AFAIK im 32Bit Mode 3 Takte für die Multiplikation, bei 64 Bit sind es 5 Takte (Quelle c't, genaue Ausgabe muss ich raussuchen). So gesehen bringt dort 64 Bit doch erstmal gar nichts, oder übersehe ich da was? Wohlgemerkt alles auf protierte 32 Bit Anwendungen bezogen.Mit Schleifen hat das erstmal nicht viel zu tun.
Die 64 Bit-Multiplikation ist nicht wirklich langsamer ... sie multipliziert zwei 64 Bit-Operanden und erzeugt ein 128 Bit-Ergebnis. Im 32 Bit-Modus kann man das prinzipiell auch, aber man muss "stückeln". Insgesamt vier Multiplikationen, und noch ein paar Additionen brauchst du dafür.
Und wenn man tatsächlich nur "wie im 32 Bit-Modus" multiplizieren möchte, geht das auch, und dauert dann ebenfalls nur drei Takte.
Spasstiger
2004-10-13, 19:23:47
Was ist denn die maximale Geschwindigkeitssteigerung, die mit 64 Bit gegenüber 32 Bit erreichbar ist?
Ich hab mal Benches von Videoencoding gesehen, wo ein Athlon 64 in 64 Bit 2,7 mal so schnell war wie in 32 Bit. Ist das möglich oder eher utopisch?
zeckensack
2004-10-13, 19:26:20
Was ist denn die maximale Geschwindigkeitssteigerung, die mit 64 Bit gegenüber 32 Bit erreichbar ist?
Ich hab mal Benches von Videoencoding gesehen, wo ein Athlon 64 in 64 Bit 2,7 mal so schnell war wie in 32 Bit. Ist das möglich oder eher utopisch?IMO Faktor vier. Das ist die bereits angesprochene Multiplikation großer Integer (Krypto-Krempel).
Sith_TirEilo
2004-10-13, 19:58:47
Hi
@zeckensack
Danke für die auführlichen und vor allem verständlichen Ausführungen, daß hat mir sehr zum Verständnis geholfen. Mir war es vorher gar nicht bewußt das zusätzliche Register + Erweiterung der Register auf 64 Bit gemeinsam das x86-64 "Paket" bilden und das AMD es zwar einzeln hätte machen können, es aber vermutlich sehr unvorteilhaft gewesen wäre (sowohl technisch als auch wirtschaftlich). Danke dafür, zeckensack!
Also kann man abschließend sagen, das portierte 32Bit Anwendungen, in erster Linie von den zusätzlichen Registern profitieren und nicht von der erweiteren Breite der Register auf 64Bit?
Grüße,
Sith
BlackBirdSR
2004-10-13, 20:28:38
Hi
und das AMD es zwar einzeln hätte machen können, es aber vermutlich sehr unvorteilhaft gewesen wäre (sowohl technisch als auch wirtschaftlich). Danke dafür, zeckensack!
Also kann man abschließend sagen, das portierte 32Bit Anwendungen, in erster Linie von den zusätzlichen Registern profitieren und nicht von der erweiteren Breite der Register auf 64Bit?
Grüße,
Sith
Was heisst unwirtschaftlich. Heutige 32Bit CPUs bauen alle auf die IA-32 x86 ISA. Die Programme ebenso.
Selbst wenn du einen K7 baust, der die zusätzlichen Register sichtbar hätte, die Software wüsste nichts damit anzufangen.
Man bräuchte also wie bei x86-64 ein neues/angepasstes Betriebsystem.
Den Aufwand würde man nur sehr sehr ungern machen.
Koppelt man das mit ein bischen 64Bit hype, geht das schon viel besser.
Unter dem Deckmanetel 64Bit laufen die zusätzlichen Register dann quasi mit.
Und ja: gerade bei Spielen werden die Register wohl (zu Beginn) den größten Einfluss haben.
marco42
2004-10-13, 20:41:22
Was heisst unwirtschaftlich. Heutige 32Bit CPUs bauen alle auf die IA-32 x86 ISA. Die Programme ebenso.
Selbst wenn du einen K7 baust, der die zusätzlichen Register sichtbar hätte, die Software wüsste nichts damit anzufangen.
Man bräuchte also wie bei x86-64 ein neues/angepasstes Betriebsystem.
Den Aufwand würde man nur sehr sehr ungern machen.
Koppelt man das mit ein bischen 64Bit hype, geht das schon viel besser.
Unter dem Deckmanetel 64Bit laufen die zusätzlichen Register dann quasi mit.
Und ja: gerade bei Spielen werden die Register wohl (zu Beginn) den größten Einfluss haben.
AFAIK kann man durch einen trick auf auf die oberen 8 register auch im 32 bit modus zugreifen.
Das geht nur in DOS, weil man dort nicht aufpassen muss was die anderen Threads machen.
Wie gesagt ist das im Protected Mode absolut brandgefährlich. Sobald 2 Threads das machen semmelt einer davon zwangsläufig ab. Ich denke auch nicht das es dort geht.
OBrian
2004-10-28, 01:55:15
AMD hat ja auch - da sie eh ein neues OS brauchen und vieles umgeschrieben werden muß - einiges vom alten x86-Krempel über Board geworfen (im 64bit-Mode natürlich nur), was der Performance auch schon hilft, auch wenn es direkt nichts mit 64bit zu tun hat. Nur mal als Beispiel Segmentierung/Paging, jetzt gibt es einen einheitlichen Speicherraum, der leichter ansprechbar ist.
Diese Verbesserungen merkt man teilweise schon an (unveränderten!) 32bit-Programmen, die auf dem 64bit-OS schneller laufen - dabei ist das 64bit-Windows, was 32bit "beigebogen" bekommen hat über WoW (ein kleiner Umweg ggü. der direkten 64bit-Auführung), aber trotzdem noch schneller als das alte 32bit-Win.
Diese oben erwähnte 2,7fache Performance kriegt man natürlich meistens nicht durch einfaches Rekompilieren, da sollte man schon beim Schreiben davon ausgehen, daß es auf einer 64bit-Maschine laufen wird. Aber solche Sprünge werden viele Programmierer sicher ermutigen; bei der Gelegenheit werden vielleicht dann auch mal sowieso längst überfällige Redesigns vorgenommen, die dann auch nochmal Speed bringen.
GloomY
2004-10-28, 19:00:30
AMD hat ja auch - da sie eh ein neues OS brauchen und vieles umgeschrieben werden muß - einiges vom alten x86-Krempel über Board geworfen (im 64bit-Mode natürlich nur), was der Performance auch schon hilft, auch wenn es direkt nichts mit 64bit zu tun hat. Nur mal als Beispiel Segmentierung/Paging, jetzt gibt es einen einheitlichen Speicherraum, der leichter ansprechbar ist.Es wird (hoffentlich) immer noch segmentiert und ge-paged ;) Oder was soll sich bei x86-64 geändert haben?
Paging ist ein Mittel für die virtuelle Speicherverwaltung und die brauchen wir immer noch ;) Und Segmentierung gibt es für Code, Daten, Stack usw. imho immer noch.
Imho sind die Adressräume einfach "nur" größer geworden. Die zusätzlichen GPRs sind natürlich ganz besonders für Compilerbauer ein nettes Zuckerl ;)
Diese Verbesserungen merkt man teilweise schon an (unveränderten!) 32bit-Programmen, die auf dem 64bit-OS schneller laufen - dabei ist das 64bit-Windows, was 32bit "beigebogen" bekommen hat über WoW (ein kleiner Umweg ggü. der direkten 64bit-Auführung), aber trotzdem noch schneller als das alte 32bit-Win.Jein, das wäre mir neu. Wenn ein Programm unter einem 64 Bit OS schneller läuft, dann nicht weil das Programm schneller abgearbeitet wird, sondern weil die Zeit für die OS Aufrufe sinkt - also an der Zeit, die im (64 Bit) Kernel verbracht wird. Dort sind natürlich alle 64 Bit Features vorhanden und werden genutzt.
Das Programm an sich - also die "User"-Ausführungszeit (um das mal in *NIX Notation auszudrücken) ändert sich überhaupt nicht. Nur die "System"-Ausführungszeit wird entweder größer (WOW-Layer Overhead), bleibt gleich (64 Bit Features bringen so viel wie der Overhead schluckt) oder sinkt sogar (64 Bit Features bringen mehr als der WOW Overhead).
Es könnte also die insgesamte Ausführungszeit (das meinst du wahrscheinlich) unter Umständen sinken. Die Vorraussetzungen dafür sind, dass das Programm möglich viel Zeit "ausserhalb" des eigentlichen Programms in der hoffentlich schnelleren 64 Bit Umgebung verbringt.
Server-Workload ist dafür meist recht gut geeignet, der Anteil der Kernel-Ausführungszeit an der Gesamt-Ausführungszeit beträgt teilweise extreme 50%. :eek:
http://www.pcstats.com/articleview.cfm?articleid=1665&page=1
dort gibt es einige nette benches von 32 vs 64bit
Es wird (hoffentlich) immer noch segmentiert und ge-paged ;) Oder was soll sich bei x86-64 geändert haben?
Paging ist ein Mittel für die virtuelle Speicherverwaltung und die brauchen wir immer noch ;) Und Segmentierung gibt es für Code, Daten, Stack usw. imho immer noch.
Sicher?
PS: Übrigens hat AMD, da die Segmentierung praktisch sowieso nicht mehr benutzt wird (bzw. eigentlich überhaupt nie richtig benutzt wurde), AMD64 nur Paging mitgegeben - keine Segmente mehr. Im IA32 Kompatiblitätsmodus haben wir sie aber noch (sonst wäre die Sache ja nicht zum 386 kompatibel).
Quelle: http://www.planet3dnow.de/artikel/diverses/nx/8.shtml
Und:
When AMD's engineers started looking for legacy x86 features to jettison, the first thing to go was the segmented memory model. Programs written to the x86-64 ISA will use a flat, 64-bit virtual address space.
Quelle: http://arstechnica.com/cpu/03q1/x86-64/x86-64-4.html
Das bezieht sich wohl auf die "Segmente" im Real Mode. Denn:
These modes are set for each segment of code on a per-segment basis by means of two bits in the segment's code segment descriptor. The chip examines these two bits so that it knows whether to treat a particular chunk of code as 32-bit or 64-bit.
Ohne Segmentierung kein Speicherschutz. Und der ist absolut notwendig.
Ohne Segmentierung kein Speicherschutz. Und der ist absolut notwendig.Wieso sollte man Speicherschutz nicht mittels Paging realisieren können? Bei anderen Architekturen funktioniert das auch. Selbst wenn es bei IA-32 nicht gehen sollte (?), vielleicht wurde das Paging bei AMD64 entsprechend erweitert?
status
2004-10-30, 20:36:08
Die PCGH schreibt dazu, das der Athlon64 über 16 Integer- und 16 SSE2-Register verfügt, jedoch im 32 Bit Betrieb nur 8 davon genutzt werden. Dadurch entstand wohl auch der größte Performanceschub in der 64Bit Version von Far Cry. Die restlichen Leistungsteigerungen entstehen dann durch Optimierungen.
Sith
hi
Es reicht vollkommen das AMD64 nur 8 Register verarbeitet, denn es gibt nur 8 Register im SSE2 Befehlssatz Klick (http://www.hayestechnologies.com/de/techsimd.htm) Grössere Befehlssätze, beinhalten Intel interne angaben, mit dem der AMD64 sowiso nichts anfangen könnte.
greetz und schönes WE noch
status
Bokill
2004-10-30, 21:48:31
@status
Schon mal folgendes gesehen?
...
MD hat hardwaremässig den K8 nicht in der x87 FPU beschnitten. Nur andernorts hat AMD nun mal deutlich den anderen Einheiten (Integer & SSE) Beine gemacht.
Mir ist es langsam ein echtes Rätsel weswegen der uralte geniale Artikel (http://www.digit-life.com/articles2/amd-hammer-family/index.html) von Digit-Life (Facts & Assumptions about the Architecture of AMD Opteron and Athlon 64) immer noch kaum wahrgenommen wurde. Da steht vieles drin was immer noch aktuell ist. Immer und immer wieder und immer immer wieder wird die 64 Bit Geschichte bis zum Speierbrechen in immer wiederkehrenden Endlos-Schleifen Endlos-Schleifen Endlos-Schleifen wiederholt ... nur die echten Leistungsbeschleuniger werden kaum ausgepackt.
Die Rolle der Register:
http://www.ixbt.com/cpu/amd/hammer-series-arc/additional-regidters.gif
Nochmals: AMD hat die Hardware mit der x87 nicht beschnitten, aber sie hat den anderen Einheiten Integer sowie SSE mit erweiterten Registersatz Beine gemacht.
...
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2388819&postcount=35
Mit AMD64 hat intel formal nichts weiter zu schaffen, da gibt AMD den Ton vor ... bei IA32 hingegen ist AMD vollkompatibel, bis auf das Feature SMT "Hyperthreading".
Nachtrag:@status
Schau dir mal das Aktualisierungsdatum deiner angebenen Seite an ...
Copyright (C) 2001-2002 by Hayes Technologies - Alle Rechte vorbehalten - Rechtliche Information - English Homepage
Letzte Änderung: 16.11.2001
immerhin ist der "status" dieser Seite schon aus diesem Jahrtausend ...
Nachtrag2:
der AMD64
is übrigens die Bezeichnung der ISA AMD64 ... nicht der Prozessoren, die dies verstehen können.
Derzeit sind dies die Prozessoren der K8 Linie (beim Sempron mit K8-Kern derzeit deaktiviert) und mit Einschränkungen bald offiziell intel`s Prozessoren der Pentium4 Serie, die auf dem Kern des Prescott basieren (ohne Celeron) ... da sollen bald weitere Firmen folgen. Transmetas Efficeon und irgendwelche VIA CPUs, nur deren Bezeichnungen werden sogar firmenintern immer wieder abweichend bezeichnet. Stand Oktober 2004.
MFG Bokill
BlackBirdSR
2004-10-31, 01:25:51
hi
Es reicht vollkommen das AMD64 nur 8 Register verarbeitet, denn es gibt nur 8 Register im SSE2 Befehlssatz Klick (http://www.hayestechnologies.com/de/techsimd.htm) Grössere Befehlssätze, beinhalten Intel interne angaben, mit dem der AMD64 sowiso nichts anfangen könnte.
greetz und schönes WE noch
status
AMD64 nutzt aber 16 GPR/Integer und 16 SSE2 Register.
Eliot
2004-10-31, 07:06:25
Hi,
Achtung Fiktion:
Angenommen AMD bringt einen A64 raus bei dem man auch im 32 Bit Modus die zusätzlichen Register nutzen könnte, würde sich dort der Geschwindigkeitsvorteil dann nicht deutlich verringern bzw. fast verschwinden? (Wenn nein warum nicht?)
Diese Möglichkeit besteht jetzt schon, durch einige Tricks. Dazu müßten aber erst einmal alle Compiler angepaßt werden... und dann jede Software auch neu kompiliert werden - was, wie du annehmen kannst, niemand machen wird.
A64 bietet auch zwei SSE Einheiten, die aber ebensowenig genutzt werden... würden alle SSE lastigen Teile für AMD optimiert, würden auch die Multimedia-Benchmarks eine ganz andere Sprache sprechen...
Eliot.
Eliot
2004-10-31, 07:09:01
Kann er nicht. Darf er auch nicht können, denn er soll ja gerade vollständig zu 32 Bit-Software (OS+Applikationen) kompatibel bleiben.
Doch kann er :-)
Mit speziellem CPU-Setting ist es möglich, alle Register anzusprechen ;-)
Aber das ist wieder eine andere Geschichte *g*
Eliot.
Eliot
2004-10-31, 07:16:54
@status
AMD hat hardwaremässig den K8 nicht in der x87 FPU beschnitten
AMD hat im 64-Bit Modus TFP eingeführt (technical floating point) und x87 damit zu Grabe getragen.
Schönen Artikel dazu gibts hier:
http://www.realworldtech.com/page.cfm?ArticleID=RWT071800000000&p=2
Eliot.
StefanV
2004-10-31, 08:37:12
Nein, AMD hat die TFP begraben und durch SSE(2) ersetzt.
€dit:
Siehe mal die erste Zeile deines Artikels, ganz weit oben:
By: Paul DeMone
Updated: 07-18-2000
BlackBirdSR
2004-10-31, 09:24:01
Diese Möglichkeit besteht jetzt schon, durch einige Tricks. Dazu müßten aber erst einmal alle Compiler angepaßt werden... und dann jede Software auch neu kompiliert werden - was, wie du annehmen kannst, niemand machen wird.
A64 bietet auch zwei SSE Einheiten, die aber ebensowenig genutzt werden... würden alle SSE lastigen Teile für AMD optimiert, würden auch die Multimedia-Benchmarks eine ganz andere Sprache sprechen...
Eliot.
Kann es sein, dass du gerade durch die Threads ziehst, und irgendwelche Annahmen deinerseits als Fakten postest?
Weder die Sache mit der Redundanz war fundiert, noch der Zugriff auf die Register, noch die Sache mit den SSE2 Einheiten oder gar TFP.
Der K8 hat 2 FP_Einheiten für die Berechnung. Daraus folgen automatisch eine ADD und eine MUL Einheit für SSE2, die vollständig verwendet werden -> deshalb auch 2 dp Operationen pro Takt.
Der Pentium4 hat ebenfalls Zugriff auf eine ADD und MUL Einheit. Er besitzt eben höheren Takt. Das zeigt sich ausschlaggebend.
Also würden meiner Meinung nach, Multimediabenchmarks keine andere Sprache sprechen, es gibt keine andere Sprache.
Der K8 hat 2 FP_Einheiten für die Berechnung. Daraus folgen automatisch eine ADD und eine MUL Einheit für SSE2, die vollständig verwendet werden -> deshalb auch 2 dp Operationen pro Takt.
Der Pentium4 hat ebenfalls Zugriff auf eine ADD und MUL Einheit. Er besitzt eben höheren Takt. Das zeigt sich ausschlaggebend.
Also würden meiner Meinung nach, Multimediabenchmarks keine andere Sprache sprechen, es gibt keine andere Sprache.Stimmt es, dass der K7 eine FP-ADD und eine FP-MUL-Einheit hat? Hat der K8 zwei "volle" FP-Einheiten, die alles können? Wie sieht es beim P4 aus?
StefanV
2004-10-31, 10:29:16
http://hardtecs4u.com/reviews/2001/pentium4_2ghz/index5.php
http://hardtecs4u.com/reviews/2001/pentium4_2ghz/index7.php
Und
http://hardtecs4u.com/reviews/2003/amd_opteron/index2.php
Eliot
2004-10-31, 10:40:02
Der K8 hat 2 FP_Einheiten für die Berechnung. Daraus folgen automatisch eine .
Der K8 hat 3 FP Einheiten.
Eliot.
StefanV
2004-10-31, 10:42:32
kommt drauf an, was man als Einheiten bezeichnet ;)
Jo Load/Store ist nicht unbedingt eine "FPU Einheit", aber wenn man so will :rolleyes:
zeckensack
2004-10-31, 11:27:34
Stimmt es, dass der K7 eine FP-ADD und eine FP-MUL-Einheit hat?Ja. Und eine dedizierte "FSTORE"-Einheit hat er auch noch. Die bringt natürlich keinerlei Arithmetik-Leistung.
Ausschnitt aus dem Blockdiagramm im Anhang.
Quelle (PDF) (http://cdrom.amd.com/21860/22054.pdf), Seite 3.
zeckensack
2004-10-31, 11:36:35
Hat der K8 zwei "volle" FP-Einheiten, die alles können?Nein. Der FP-Block ist fast identisch zum K7. FMUL/FADD/FSTORE. Siehe Anhang.
Die einzige Diskrepanz ist dass die "FSTORE"-Einheit ab und zu "FMISC"-Einheit genannt wird, und diese Passage:The third pipe is known as the floating-point load/store (FSTORE), which handles floating-point
stores and many micro-op primitives used in VectorPath sequences.
Quelle (PDF) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF), Seite 257.
Nein. Der FP-Block ist fast identisch zum K7. FMUL/FADD/FSTORE. Siehe Anhang.
Die einzige Diskrepanz ist dass die "FSTORE"-Einheit ab und zu "FMISC"-Einheit genannt wird, und diese Passage:
Quelle (PDF) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF), Seite 257.Hm, hm.
Also kann K7/K8 pro Takt nur ein FP-MAD ausführen. (Kann mir jemand flüstern, wieso eine CPU nicht doppelt so viel FP-Power bekommt? Oder steht diese mittels 3DNow+ // SSE2 bereits zur Verfügung?)
Die K8-FSTORE-Unit kann aber nicht nur Adressrechnung machen, sondern auch für Arithmetik zweckentfremdet werden?
BlackBirdSR
2004-10-31, 13:35:11
Hm, hm.
Also kann K7/K8 pro Takt nur ein FP-MAD ausführen. (Kann mir jemand flüstern, wieso eine CPU nicht doppelt so viel FP-Power bekommt? Oder steht diese mittels 3DNow+ // SSE2 bereits zur Verfügung?)
Die K8-FSTORE-Unit kann aber nicht nur Adressrechnung machen, sondern auch für Arithmetik zweckentfremdet werden?
Naja.. es stellt sich als extrem großer Aufwand herraus, mal eben schnell 2FP-ADD und 2-FP MUL Einheiten einzubauen.
Das Ganze will ja durch das Front-End, durch die Scheduler und anschließend soll das ja auch wieder aus der CPU raus.
Und es können nur 3µOps/Cycle rausgeworfen werden.
2 ADDs 2 MULs + ALU Operation sind aber schon 5 Befehle.
Das lohnt sich nicht für den geringen Zuwachs. Man ist ja schon froh, wenn man im Schnitt 1.5 Befehle pro Takt durchbringt.
Bei anderen Architekturen wie Power oder IA64, wo die Einheiten gleich als FMACs ausgelegt sind, läuft das natürlich besser.
Eine Lösung ist eben SSE/2. Es lassen sich 2 oder 4 Operationen ausführen, ohne dass man ein Front/Back-End aufblähen müsste.
Allerdings leider nur bei Vectorcode, und der ist nicht unbedingt an jeder Straßenecke zu finden :)
Der P4 führt übrigens bei x87 entweder ein FP-ADD oder FP-MUL aus.
hat nur eine FP-Einheit und einen Port dafür. Allerdings ist die dann (in der ersten Stufe) 128Bit breit, damit mit SSE2 trotzdem 2 dp Werte berechnet werden können.
Edit:
The FP Store unit, more recently called the FP Miscellaneous unit handles not only the stores but also a number of other single operand functions such as Integer to Float and Float to Integer conversions. It further provides a lot of functions used by Vector Path generated micro code to handle more complex x87 operations. It contains the Floating Point Constant ROM that contains a range of floating point constants such as pi, e, log2 et-cetera
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html
Der A64 ist aber bei SSE2 taktnormalisiert trotzdem schneller als der P4. Der Grund ist dass der Pentium 4 die SSE2 Instructions erst in der FPU in zwei Teile zerlegt, der A64 aber eine Double Dispatch ausführt.
del_4901
2004-11-21, 03:06:35
Meine Meinung zum AMD64 und Spielen:
uint64 und seine Kumpanen brauchen nur Kryptodienste etc. -> (unnötig für Spiele)
float/double wird eh mit 32 bzw. 64 bit gerechnet (auch bei 32 bittern...ISSE2) -> (ändert an der Performance gar niks)
Die Zeiger werden länger(64bitZeiger) -> (das drückt sogar noch die Performance ... weniger Speicher+Bandbreite)
ein größerer Adressraum -> (für Spiele die mehr als 4GB RAM benötigen interessant und dort auch sehr Performant [Unreal3])
Die zusätzlichen Register -> (interessant für SW jeder Art)
Ack. Aber die zusätzlichen Register bügeln halt vieles aus.
Demirug
2004-11-21, 12:31:52
ein größerer Adressraum -> (für Spiele die mehr als 4GB RAM benötigen interessant und dort auch sehr Performant [Unreal3])
Selbst wenn man den Speicher eigentlich nicht braucht kann man mit dem grösseren Adressraum was anfangen.
Eine mögliche Nutzung besteht darin die Daten auf dem Datenträger direkt in den Speicher zu mappen. Damit muss man sich nicht mehr um das Laden kümmern sondern kann einfach auf die daten zugreifen. Wenn etwas noch nicht im Speicher ist greifen die gleichen Funktionen welche auch benutzt werden um Speicher welcher in das Swapfile ausgelagert wurden zu laden. Das ganze ist die schnellste Methode um etwas zu laden. Funktioniert bei 32Bit Systemen aber leider nicht weil man im Adressraum meist keinen Block findet der gross genug für sowas ist.
Und Speicherfragmentierung ist auch kein großes Thema mehr :)
BlackBirdSR
2004-11-21, 12:42:47
Selbst wenn man den Speicher eigentlich nicht braucht kann man mit dem grösseren Adressraum was anfangen.
Eine mögliche Nutzung besteht darin die Daten auf dem Datenträger direkt in den Speicher zu mappen. Damit muss man sich nicht mehr um das Laden kümmern sondern kann einfach auf die daten zugreifen. Wenn etwas noch nicht im Speicher ist greifen die gleichen Funktionen welche auch benutzt werden um Speicher welcher in das Swapfile ausgelagert wurden zu laden. Das ganze ist die schnellste Methode um etwas zu laden. Funktioniert bei 32Bit Systemen aber leider nicht weil man im Adressraum meist keinen Block findet der gross genug für sowas ist.
schonmal probiert?
Wieviel Zeit konntest du damit bei dir ca. einsparen?
Demirug
2004-11-21, 12:54:13
schonmal probiert?
Wieviel Zeit konntest du damit bei dir ca. einsparen?
Ja, aber das ist schon eine Weile her. Allerdings mit 32 Bit und einer kleineren Datenmengen damit sie noch in den Adressraum passt.
Da das ganze ein Versuch zum dynamischen nachladen war habe ich die Zeit nicht direkt gemessen. Auf jeden Fall wurde das ruckeln aber weniger und verschwand teilweise auch ganz. Wir haben das ganze dann aber aufgegeben weil wir merkten das uns der Adressraum dafür nicht reichen wird.
BlackBirdSR
2004-11-21, 12:56:48
Ja, aber das ist schon eine Weile her. Allerdings mit 32 Bit und einer kleineren Datenmengen damit sie noch in den Adressraum passt.
Da das ganze ein Versuch zum dynamischen nachladen war habe ich die Zeit nicht direkt gemessen. Auf jeden Fall wurde das ruckeln aber weniger und verschwand teilweise auch ganz. Wir haben das ganze dann aber aufgegeben weil wir merkten das uns der Adressraum dafür nicht reichen wird.
Könnte man doch eigentlich dafür Nutzen, um Levelladezeiten an sich zu verringern.
C&C Generals ZH spielt z.B ein Video ab, und macht zumindest den Anschein im Hintergrund schon mal zu laden.
Allerdings nur ca 10% der Rest wird nach dem Video geladen, und das eigentlich recht schnell.
Ich hätte nichts dagegen, während des Briefings schonmal das Level quasi im Speicher zu haben.
Demirug
2004-11-21, 13:06:17
Könnte man doch eigentlich dafür Nutzen, um Levelladezeiten an sich zu verringern.
C&C Generals ZH spielt z.B ein Video ab, und macht zumindest den Anschein im Hintergrund schon mal zu laden.
Allerdings nur ca 10% der Rest wird nach dem Video geladen, und das eigentlich recht schnell.
Ich hätte nichts dagegen, während des Briefings schonmal das Level quasi im Speicher zu haben.
Da wäre eher Multithreading angesagt. Aus meiner Erfahrung verliert man bei Laden von Levels viel Zeit im Memorymanager wenn man Speicher für die Objekte anfordert.
Ein bischen was sollte sich aber denoch sparen lassen weil man teilweise kopieraktionen sparen kann.
del_4901
2004-11-21, 21:33:35
Selbst wenn man den Speicher eigentlich nicht braucht kann man mit dem grösseren Adressraum was anfangen.
Eine mögliche Nutzung besteht darin die Daten auf dem Datenträger direkt in den Speicher zu mappen. Damit muss man sich nicht mehr um das Laden kümmern sondern kann einfach auf die daten zugreifen. Wenn etwas noch nicht im Speicher ist greifen die gleichen Funktionen welche auch benutzt werden um Speicher welcher in das Swapfile ausgelagert wurden zu laden. Das ganze ist die schnellste Methode um etwas zu laden. Funktioniert bei 32Bit Systemen aber leider nicht weil man im Adressraum meist keinen Block findet der gross genug für sowas ist.
Mhm, lade ich nicht eh die Geometrie Daten Texturen etc. vor dem Level?Dann sind doch die wichtigen Sachen im Speicher.
BTW: Ich bin dabei mir eine Speicherverwaltung für Games zu schreiben, die auch Swappen kann. Bei Texturen wird das nicht funktionieren, (die müssen ja vor dem Renderer in den Kontext geladen werden) oder kennst du eine Idee, wie ich Texturen auf die Platte kratzen kann. Bei den Geometriedaten sollte das kein Problem darstellen. Mit der Geometrie habe ich dann follgende Stufen: Platte / Speicher / VertexBuffer
Texturen können auch auf Frame Basis nachgeladen werden, wieso sollte das auch nicht gehen?
del_4901
2004-11-22, 07:38:17
Texturen können auch auf Frame Basis nachgeladen werden, wieso sollte das auch nicht gehen?
Mhm, krieg ich die Textur auch irgendwie wieder aus meinen GFXSpeicher raus, oder muss der irgendwann platzen?
Demirug
2004-11-22, 11:48:59
Mhm, krieg ich die Textur auch irgendwie wieder aus meinen GFXSpeicher raus, oder muss der irgendwann platzen?
Klar, einfach freigeben. Der Treiber wirft das ganze dann schon irgendwann aus dem Speicher. Genau wie bei Vertexdaten.
Und mit PBO ist das ganze sowieso kein Problem, leider ist ARB_pixel_buffer_object noch nicht verfügbar.
del_4901
2004-11-26, 02:31:09
So wenn ich einmal hier bin, könnt ihr mir das mit dem Texturen + Geometrie nachladen mal bitte genauer erklären, wie man das z.B in OGL macht, wo der Hacken dabei ist, wo es sin macht bzw. wo es unsinnig ist etc.
BTW: Müsste der A64 ein double nicht in einem Takt aus dem Speicher holen können (8byte alignment) als ein P4 mit 4byte alignment? Dann macht es vllt doch bei einigen Stellen (auch in Games) sin.
Bringt es mir dann was wenn ich alles mit double rechne, oder bricht dann die FPU bzw. ISSE zu stark ein? (mal abgesehen vom Speicherverbrauch)
Nachladen von Geometrie: ARB_vertex_buffer_object
Nachladen von Geometrie: Entweder EXT_pixel_buffer_object oder ganz normal.
Ich versteh nicht genau was du meinst, aber der Bus ist auch beim P4 schon 64 bit breit soweit ich weiß und die FPU sowieso.
Mit doubles rechnen kostet nur Performance und bringt bei 3D Engines sogut wie nie was.
del_4901
2004-11-26, 14:24:29
Nachladen von Geometrie: ARB_vertex_buffer_object
Nachladen von Geometrie: Entweder EXT_pixel_buffer_object oder ganz normal.
Ich versteh nicht genau was du meinst, aber der Bus ist auch beim P4 schon 64 bit breit soweit ich weiß und die FPU sowieso.
Mit doubles rechnen kostet nur Performance und bringt bei 3D Engines sogut wie nie was.
die PBOs funzen die mit jeder GPU? Brauch ich dafür OGL 2.0?
um das ganze mal zu Spezifizieren ich hab einen NV35.
Mhm der bus ist 64 bit breit, aber das ALIGNMENT ist unter Garantie 4byte (sonnst würde meine Speicherverwaltung alt aussehen) Bei einem 8Byte Alignment hab ich schon böhzen Verschnitt. ich hab ein Testprog da, wo du Allingments einstellen kannst, und der dir den Verschnitt anzeigt. (läuft aber nur unter Linux im mom) Bei Interresse kann ich dir das mal mailen.
PBOs gibt's z.Z. nur als Extension auf nVidia Grafikkarten, aber du kannst wie gesagt auch ganz normal Texturen hochladen.
Ich verstehe trotzdem nicht auf was du hinaus willst. Doubles sind auch auf nem AMD64 langsamer.
Alpha
2004-11-27, 05:43:07
PBOs gibt's z.Z. nur als Extension auf nVidia Grafikkarten, aber du kannst wie gesagt auch ganz normal Texturen hochladen.
Ich verstehe trotzdem nicht auf was du hinaus willst. Doubles sind auch auf nem AMD64 langsamer.
ne das mit den doubles ist dumm, das war auch blos eine theroretische frage. wegen der Rechenleistung. Die Frage ist nur noch ob der AMD 64 nen ALIGNMENT von 4(AMD32 P4) oder 8 hat.
Da gibt's keinen Unterschied zwischen Athlon und Athlon 64. Daten solltest du immer so alignen wie breit sie sind (also floats 4 bytes, doubles 8 bytes, etc.)
zeckensack
2004-11-27, 23:26:40
BTW: Ich bin dabei mir eine Speicherverwaltung für Games zu schreiben, die auch Swappen kann. Bei Texturen wird das nicht funktionieren, (die müssen ja vor dem Renderer in den Kontext geladen werden) oder kennst du eine Idee, wie ich Texturen auf die Platte kratzen kann. Bei den Geometriedaten sollte das kein Problem darstellen. Mit der Geometrie habe ich dann follgende Stufen: Platte / Speicher / VertexBufferIst IMO total kontraproduktiv.
1)Wieso willst du Daten, die du irgendwann mal von der Platte geladen hast, wieder auf der Platte ablegen? Dann hast du die Daten zweimal. Einmal reicht. Und darüberhinaus werden Daten von der Platte sowieso vom Betriebssystem gecacht, so weit der Speicher reicht.
2)Wenn du es trotzdem machen willst, dann lass die Daten einfach im Speicher (bzw die vom Treiber erzeugte Kopie; das "Original" kannst und solltest du nach der Übergabe freigeben). Daten die rumliegen ohne genutzt zu werden, kommen automatisch in die Swap-Datei, sobald der physikalische Speicher für andere Sachen gebraucht wird.
Erfahrungsgemäß bringt selbstgebautes (Software-)Caching nur dann was, wenn du entweder massive Latenzverbesserungen erreichen kannst (Daten direkt von CD-ROM), oder der Cache dir langwierige Berechnungen erspart (was im Grunde wieder nur eine Form von Latenz darstellt ...).
Ansonsten läuft's immer darauf hinaus, dass du identische Daten mehrfach rumfliegen hast, und das ist einfach nur Platzverschwendung.
Als recht effektiv hat sich die Taktik erwiesen, die Rohdaten in einem komprimierten Format vorzuhalten und erst bei Nutzung bröckchenweise zu dekomprimieren. Dadurch erreicht man dass die Caches des Betriebssystems effektiv mehr Daten fassen (nicht nur LRU, sondern auch look-ahead), und verringert die Fälle, in denen Kopfpositionierungslatenzen auftreten. Funktioniert eigentlich für alles, von Geometrie bishin zu Sound-Daten. Je nach Architektur macht man damit auch Gewinne in Bezug auf den Speicher, den man für "temporäre" Kopien belegt, die man garnicht direkt anfassen muss.
del_4901
2004-11-28, 03:56:33
Ist IMO total kontraproduktiv.
1)Wieso willst du Daten, die du irgendwann mal von der Platte geladen hast, wieder auf der Platte ablegen? Dann hast du die Daten zweimal. Einmal reicht. Und darüberhinaus werden Daten von der Platte sowieso vom Betriebssystem gecacht, so weit der Speicher reicht.
2)Wenn du es trotzdem machen willst, dann lass die Daten einfach im Speicher (bzw die vom Treiber erzeugte Kopie; das "Original" kannst und solltest du nach der Übergabe freigeben). Daten die rumliegen ohne genutzt zu werden, kommen automatisch in die Swap-Datei, sobald der physikalische Speicher für andere Sachen gebraucht wird.
Erfahrungsgemäß bringt selbstgebautes (Software-)Caching nur dann was, wenn du entweder massive Latenzverbesserungen erreichen kannst (Daten direkt von CD-ROM), oder der Cache dir langwierige Berechnungen erspart (was im Grunde wieder nur eine Form von Latenz darstellt ...).
Ansonsten läuft's immer darauf hinaus, dass du identische Daten mehrfach rumfliegen hast, und das ist einfach nur Platzverschwendung.
Als recht effektiv hat sich die Taktik erwiesen, die Rohdaten in einem komprimierten Format vorzuhalten und erst bei Nutzung bröckchenweise zu dekomprimieren. Dadurch erreicht man dass die Caches des Betriebssystems effektiv mehr Daten fassen (nicht nur LRU, sondern auch look-ahead), und verringert die Fälle, in denen Kopfpositionierungslatenzen auftreten. Funktioniert eigentlich für alles, von Geometrie bishin zu Sound-Daten. Je nach Architektur macht man damit auch Gewinne in Bezug auf den Speicher, den man für "temporäre" Kopien belegt, die man garnicht direkt anfassen muss.
Ich wollte eine Blockorientiere Speicherverw. machen ... alle Blöcke sind gleich groß (so das vllt die 1000 Polys eines BSP Blatts reinpassen)
Dann habe ich zwar nen übelen Verschnitt wenn ich mal keine 1000 Polys mehr habe, aber meine Verwaltung ansich ist sehr sehr einfach und kostet Xtreme wenig Laufzeit.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.