Ist 64 Bit schneller?

Warum baut man nicht einfach einen Prozessor mit 1024 Registern, damit alles schneller wird?

Kannst du für so etwas eine compiler bauen der das ausnutzt?
imho wären ~20 eine sehr gute zahl

rüdiger

Frage5 schrieb:

Warum baut man nicht einfach einen Prozessor mit 1024 Registern, damit alles schneller wird?

tut man doch. x86-32/64 ist eben eine krüppel Architektur. Aber etwas gutes wie IA64 wird ja sofort abgesägt

Was soll denn an AMD64 schlechter sein als an IA-64, abgesehen davon, dass es den x86-Kompatibilitätsmodus enthält? In AMD64 gibts doch auch Register ohne Ende.

nur 16.

Wie viel hat der IA64?

Zeus

128+82+64 Register (Integer/Fließkoma/Prädikat)

Der IA-64 ist schlecht. Deshalb ist er auch nicht sonderlich weit verbreitet.

groovemaster

rüdiger schrieb:

tut man doch. x86-32/64 ist eben eine krüppel Architektur.

Nope. Mal abgesehen davon, ist x86 heutzutage sowieso nicht vielmehr als eine Schnittstelle, die lediglich während der Dekodierungsphase in Erscheinung tritt. x86-64 hat imo ausreichend Register. Zu viele sind letztendlich Overkill, zumindest für die Marktsegmente, wo x86 von Bedeutung ist. Eine gut funktionierende Cache Hierarchie bringt auch weitaus mehr, um Speicherzugriffe ausreichend abzupuffern. Klar kann man eine bessere Architektur entwerfen, aber im Consumerbereich kannst du sowas halt schwer durchsetzen. Und wirklich notwendig ist es momentan auch nicht.

rüdiger schrieb:

Aber etwas gutes wie IA64 [...]

Der war gut. Intel hat doch Itanium selbst abgesägt. Die Idee mag ja nett gewesen sein. Die Realisierung ist aber einfach nur Müll. Der fehlende Support ist da eigentlich noch das geringste Problem. Itanium hat praktisch keinen Markt. Im Desktop- und Mobilbereich unbrauchbar. Im Server und HPC Markt kaum konkurrenzfähig. Gegen IBM sieht Intel hier kein Land. Selbst AMD hat mit Barcelona eine weitaus bessere Plattform. Und bei Mainframes wie der zSeries von IBM ist Itanium einfach nur chancenlos. Selbst der Xeon basierend auf der Core Architektur hat dem Itanium den Rang abgelaufen.
Naja, vielleicht können sie ja mit 45nm noch etwas retten. Allerdings glaube ich nicht daran. Mit Nehalem, Silverthorn und Tera-Scale zeigt Intel eigentlich recht deutlich, wo sie hinwollen. Itanium bzw. IA-64 hat da keinen Platz. Es ist einfach nur ein total verkorkstes Konzept und wird früher oder später wohl verschwinden. Mal schauen, wie lange Intel braucht, um sich dieses Scheitern einzugestehen. Bei Netburst hat das immerhin recht lange gedauert.

dynamic_cast sind viel langsamer.

http://blogs.msdn.com/junfeng/archive/2006/10/17/dynamic-cast-is-slow-in-x64.aspx

EinerDerBestenCoder schrieb:

dynamic_cast sind viel langsamer.

http://blogs.msdn.com/junfeng/archive/2006/10/17/dynamic-cast-is-slow-in-x64.aspx

dynamic_casts verwendet man doch eh nicht, genausowenig wie RTTI

groovemaster

EinerDerBestenCoder schrieb:

dynamic_cast sind viel langsamer.

dynamic_cast ist implementationsspezifisch. Da macht eine Bewertung für langsamer oder schneller keinen Sinn. Die Beobachtungen dort sind rein auf die Implementierung zurückzuführen, nicht auf 64 Bit.

DerBessereCoder schrieb:

EinerDerBestenCoder schrieb:

dynamic_cast sind viel langsamer.

http://blogs.msdn.com/junfeng/archive/2006/10/17/dynamic-cast-is-slow-in-x64.aspx

dynamic_casts verwendet man doch eh nicht, genausowenig wie RTTI

ja

groovemaster schrieb:

EinerDerBestenCoder schrieb:

dynamic_cast sind viel langsamer.

dynamic_cast ist implementationsspezifisch. Da macht eine Bewertung für langsamer oder schneller keinen Sinn. Die Beobachtungen dort sind rein auf die Implementierung zurückzuführen, nicht auf 64 Bit.

immerhin die Implementierung des Weltmarktführers

Slidemaster17

brauchst aber auch ein 64 bit OS system

groovemaster schrieb:

rüdiger schrieb:

tut man doch. x86-32/64 ist eben eine krüppel Architektur.

Nope. Mal abgesehen davon, ist x86 heutzutage sowieso nicht vielmehr als eine Schnittstelle, die lediglich während der Dekodierungsphase in Erscheinung tritt.

Naja, aber diese Schnittstelle ist schon trotzdem nicht mehr geil. Man hat jahrzehntelang da neues drangebastelt, ohne mal Sachen zu entfernen, die man heute nicht mehr braucht. Die Rückwärtskompatibilität ist schon nicht schlecht, dass es sie gibt, aber verfrickelt ist es halt schon. Und es wird mit 128 Bit oder NX-Bit 2.0 oder SSE 23 dann nicht besser.

Ich bin aber auch der Meinung, dass es im Moment nicht sinnvoll wäre, dass jetzt ersetzen zu wollen.

rüdiger

@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.

Zeus

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.

groovemaster

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.

rüdiger

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).

groovemaster

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.

rapso

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.