Ist 64 Bit schneller?
-
6432 schrieb:
Frage steht oben.
Was meinst du mit 64 Bit genau? Die Breite des Adressbusses? Dann würde ich mal sagen, dass es eher langsamer wird, da der Code größer wird.
Andere Eigenschaften sind aber sicher interessanter. Wenn man mehr Arbeitsspeicher haben kann, kann eine Anwendung die viel Arbeitsspeicher braucht natürlich schneller sein, da weniger geswappt werden muss. Wenn man den Umstieg auf eine 64Bit-Architektur nutzt, um die verkorkste Architektur der 32Bit-Version wenigstens ein bisschen aufzuräumen, dann kann es auch schneller sein. Wenn man eine 64Bit-Integerunit einführt, dann sind Operationen auf Integer-Datentypen mit 64 Bit schneller etc.
6432 schrieb:
Und: Warum hat sich IA-64 nicht durchgesetzt?
Weil er nicht kompatibel zu x86 ist.
-
Je breiter die CPU, desto mehr RAM brauchst du!
32bit 1GB RAM <=> 64bit 2GB RAM
lol... scheisse deswegen funktioniert mein P4 nicht hab nur 512 mb
-
Ist 64 Bit schneller?
Ja. Du kannst zB mit einem Transfer 64 Bit schieben anstatt 32. Inwiefern sich das aber auswirkt, hängt letztendlich von der Speicheranbindung ab.
x86-64 bietet gegenüber x86-32 zudem den Vorteil, dass es mehr Register gibt. Und das wiederum verringert die Notwendigkeit für Speicherzugriffe.6432 schrieb:
Und: Warum hat sich IA-64 nicht durchgesetzt?
ZB war keine Kompatibilität zu x86-32 vorhanden bzw. mit Kompatibilität zu lahm. Und da blieb eigentlich nur der Serverbereich übrig. Und dort ist Itanium auch alles andere als prickelnd.
-
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
-
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?
-
128+82+64 Register (Integer/Fließkoma/Prädikat)
-
Der IA-64 ist schlecht. Deshalb ist er auch nicht sonderlich weit verbreitet.
-
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
-
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
-
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.
-
@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.