Ist 64 Bit schneller?
-
@groovemaster
Das größte Problem des IA64s dürfte einfach gewesen sein, dass die Intel-Leute kein x86-Frontend oder -Coprozessor gebaut haben. So konnte AMD mit dem x86_64 einfach punkten, weil sie Kompatibilität anbieten konnten. Aber der x86_64 ist einfach die schlechtere Architektur verglichen mit anderen Prozessoren.Und ja, der IA64 hatte Probleme. Aber es ist nun mal nett vom Konzept, wenn man Parallelisierung geschenkt bekommt.
-
rüdiger schrieb:
Und ja, der IA64 hatte Probleme. Aber es ist nun mal nett vom Konzept, wenn man Parallelisierung geschenkt bekommt.
Wo bekommt man was geschenkt, der x86 hat nen Scheduler der die Befehle analysiert und sie paralleliert. Beim IA64 ist das der Compiler, der Befehle in Gruppen markiert. Das Konzept vom IA64 ist wirklich sehr nett, aber ich glaub Intel will selbst nicht, dass er sich gegem x86 durchsetzt. Immerhin wird der nur im 90nm-Fertigungstechnik hergestellt.
-
Optimizer schrieb:
Naja, aber diese Schnittstelle ist schon trotzdem nicht mehr geil.
Mag sein. Nur verursacht das momentan nicht wirklich Bauchschmerzen. CPUs zerfrickeln x86 Code sowieso entsprechend, so dass die CPU Architektur optimal damit arbeiten kann. Und an anderen Altlasten, wie dem BIOS, wird ja durchaus gearbeitet. Die Frage sollte eigentlich eher sein, ob man nicht aktuelle CPU Architekturen über den Haufen werfen und mit etwas neuem beginnen sollte. Ein Problem heutzutage ist doch, dass Anwendungen von der verfügbaren Rechenleistung von Multicore CPUs keinen Gebrauch machen können, wenn sie ihre Rechenlast nicht auf mehrere Threads aufteilen. Warum? Nun, die Entwickler machen es sich relativ einfach, entwickeln einen Kern, duplizieren diesen x-mal und basteln drumherum ein Kommunikationsinterface. Übrig bleibt Hardwarethreading auf Kernbasis. Dort sollte man mal ansetzen. Und dann kann man immer noch entscheiden, ob x86 für die Umsetzung ausreicht oder eine neue Architektur gebraucht wird.
rüdiger schrieb:
Das größte Problem des IA64s dürfte einfach gewesen sein, dass die Intel-Leute kein x86-Frontend oder -Coprozessor gebaut haben. So konnte AMD mit dem x86_64 einfach punkten, weil sie Kompatibilität anbieten konnten.
Ob das geholfen hätte, ich glaube es fast nicht. Itanium hatte ja zeitweise Hardware Support für x86, nur mit "echten" x86 CPUs konnte man sich damit nicht messen. Mittlerweile ist wohl nur noch ein Software Layer verfügbar, geändert hat sich nicht wirklich etwas. Transmeta hatte doch ein ähnliches Schicksal. Die wollten x86 CPUs bauen, hatten aber keine Lizenz. Was haben sie also gemacht? Eine Eigenentwicklung aus dem Boden gestampft und über einen Software Layer x86 Kompatibilität gewährleistet. Das hat sogar recht gut funktioniert, war nur dummerweise einfach zu lahm.
rüdiger schrieb:
Und ja, der IA64 hatte Probleme. Aber es ist nun mal nett vom Konzept, wenn man Parallelisierung geschenkt bekommt.
Was meinst du denn mit "Parallelisierung"? VLIW? Ähnliche Techniken gibt es doch mittlerweile auch ausreichend bei x86 CPUs. Ich würde mich wundern, wenn es da noch grossartig Unterschiede gibt. Und dynamische Abhängigkeiten kann Itanium mit VLIW auch nicht auflösen. Vielleicht war auch das eines der gravierenden Itanium Probleme, der komplexe Compiler. Ich halte ehrlich gesagt nicht viel davon, entsprechende Optimierungen auf einen Bereich auszulagern. x86 macht das imo schon recht gut, sowohl aus Compiler als auch CPU Scheduler das Optimum rauszuholen. Wo letztendlich mehr Komplexität liegt, ist sowieso Glaubensfrage.
-
groovemaster schrieb:
rüdiger schrieb:
Das größte Problem des IA64s dürfte einfach gewesen sein, dass die Intel-Leute kein x86-Frontend oder -Coprozessor gebaut haben. So konnte AMD mit dem x86_64 einfach punkten, weil sie Kompatibilität anbieten konnten.
Ob das geholfen hätte, ich glaube es fast nicht. Itanium hatte ja zeitweise Hardware Support für x86, nur mit "echten" x86 CPUs konnte man sich damit nicht messen. Mittlerweile ist wohl nur noch ein Software Layer verfügbar, geändert hat sich nicht wirklich etwas. Transmeta hatte doch ein ähnliches Schicksal. Die wollten x86 CPUs bauen, hatten aber keine Lizenz. Was haben sie also gemacht? Eine Eigenentwicklung aus dem Boden gestampft und über einen Software Layer x86 Kompatibilität gewährleistet. Das hat sogar recht gut funktioniert, war nur dummerweise einfach zu lahm.
Kommt halt darauf an, wie man die Sache angeht. x86(_64) ist ja selbst, wie Du hier richtig betont hast, kein x86 aus den 80ern mehr, sondern nur noch ein Interface für die "modernere" Architektur. Man hätte nur eine bessere Architektur anbieten sollen als x86_64. Die Itanium-Leute wären sicher erfolgreicher gewesen, wenn sie ein x86-Interface von Anfang an angeboten hätten. Man hätte ja auch einen Kern Pentium4 machen können, aber damals war Intel noch nicht so weit und heute ist es für solche Experimente zu spät, da x86_64 etabliert ist.
groovemaster schrieb:
Was meinst du denn mit "Parallelisierung"? VLIW? Ähnliche Techniken gibt es doch mittlerweile auch ausreichend bei x86 CPUs. Ich würde mich wundern, wenn es da noch grossartig Unterschiede gibt. Und dynamische Abhängigkeiten kann Itanium mit VLIW auch nicht auflösen. Vielleicht war auch das eines der gravierenden Itanium Probleme, der komplexe Compiler. Ich halte ehrlich gesagt nicht viel davon, entsprechende Optimierungen auf einen Bereich auszulagern. x86 macht das imo schon recht gut, sowohl aus Compiler als auch CPU Scheduler das Optimum rauszuholen. Wo letztendlich mehr Komplexität liegt, ist sowieso Glaubensfrage.
Compiler waren wohl in der Tat ein Problem des Itaniums. Das ist natürlich auch ein Problem, wenn man eine revolutionäre Änderung einführt, dass die Tools drumherum sich erst nach und nach entwickeln. Aber im Grunde gab es das Itanium-Konzept ja schon beim HP PA-RISC.
btw. können nicht gerade x86(_64) schlecht schedulen, da sie eine strenge Ordnung im Speichermodel haben? (Stichwort Memory Barrier).
-
rüdiger schrieb:
Kommt halt darauf an, wie man die Sache angeht. x86(_64) ist ja selbst, wie Du hier richtig betont hast, kein x86 aus den 80ern mehr, sondern nur noch ein Interface für die "modernere" Architektur. Man hätte nur eine bessere Architektur anbieten sollen als x86_64.
Besser inwiefern? Was stört dich denn an x86-64?
rüdiger schrieb:
btw. können nicht gerade x86(_64) schlecht schedulen, da sie eine strenge Ordnung im Speichermodel haben? (Stichwort Memory Barrier).
Memory Barrier sagt mir im Moment nichts. Was genau meinst du damit?
Die x86 Scheduler sind mittlerweile ziemlich gut, wenn auch recht komplex. Der Core2 von Intel beherrscht zB, zumindest unter x86-32, ein Feature namens Macro Fusion. Dort wird der Instruktionsstream ausgewertet und dann passende Instruktionen zusammengefügt, um dies in einem Rutsch zu verarbeiten. Also praktisch das gleiche Prinzip wie VLIW. Nehalem wird das dann wohl auch für x86-64 bieten. Aktuell limitiert da der Fetch Buffer, iirc.
-
x86 haben mit die besten sheduler die es gibt, man muss keine manuelle memory barrier setzen, sie haben intern wege um das problem zu umschiffen. gerade core2duo und nun phenoms sind darin sehr gut. sie loesen das auf die selbe weise wie register hazards, deswegen koennen sie bei sonst schlecht zu optimierenden code sehr effizient arbeiten, weit besser als z.b. PowerPC oder MIPS, die einfach nur stallen bzw nen pipeline flush haben.
dass das recht komplex ist, sieht man ja jetzt am phenom (barcelona) kern und am penryn. beide haben bei manchen konstelationen mit hoher taktung fehler in dieser optimierungslogik und mussten fuer ein neues stepping verzoegert werden.man muss sich nur mal vorstellen wie komplex die logik darin ist, die 96 befehle gleichzeitig mit all ihren dependencies, latenzen und resourcen verwaltet.
-
Deswegen ist doch der IA64 so ein guter Konzept gewesen. Da hat man den Compiler die Arbeit gelassen die Instruktionen in Gruppen einzuteilen und dafüer spart man die Komplexität des Schudeler.
-
Zeus schrieb:
Deswegen ist doch der IA64 so ein guter Konzept gewesen. Da hat man den Compiler die Arbeit gelassen die Instruktionen in Gruppen einzuteilen und dafüer spart man die Komplexität des Schudeler.
dieses gute konzept verfolgen viele CPUs, neuerdings wandelt sich dieses konzept in 'unglaublich viele hardwarethread pro core' um, was auch ein sehr gutes konzept ist.
leider sind beide konzepte in der realitaet nur sehr sehr bedingt von erfolg gekroent, weil die idealisierte sandbox in der sie gut sind in der realitaet nicht existiert und die realitaet dann sehr kontraproduktiv ist.
-
Meine Meinung ist IMT(Interleaved-Multithreading) auch nur für einige Anwendungen geeigenet.
-
Wird es denn jetzt eigentlich schneller, wenn man ein Programm für x64 compiliert? In der ISA stehen meines Wissens nach dadurch mehr Register zur Verfügung. Das sagt natürlich nichts über die interne Anzahl von Registern aus, aber zumindest kann der Compiler dann wahrscheinlich einen größeren Teil der Registerbelegung zur Compilezeit planen (wo viel Zeit dafür ist). Macht das dann in der Praxis was aus?
-
Leicht OT: Gibt es einen AMD64-optimierten Firefox-Build?