Ich habe gelesen, dass eine 64 bit cpu bei smartphones selbst in einer 32 bit software umgebung eine bessere performance zeigen als 32 Bit prozessoren. Wie ist das möglich? http://www.connect.de/news/android-smartphones-64-bit-cpu-ab-ende-2014-2250789.html ich dachte immer, dass es so ist. Ein LKW ist voll beladen und braucht zum Transport eine gewisse Zeit. Dann braucht ein halb so großer LKW die doppelte Zeit, da er zwei mal fahren muss. Reicht die Ladung nur um den kleinen LKW zu füllen, so sind beide gleich schnell. 64 bit hat ja vorteile z. B. beim verschlüsseln, grafikberechnungen ich hoffe, das mir jemand das erkären kann. gruß Flo
:
Bearbeitet durch User
Moderne Proz in der Klasse arbeiten alle mit Cache, Pipeline und Branchperdiktion. Das heiß das immer mehr aus dem Speicher gelesen wird als für die aktuelle Ausführung benötigt wird. Dieses mehr ist optimaler Weise das was als nächstes ausgeführt werden soll. Da oftmals die nächste Instruction im Speicher direkt die folgende Adresse ist, ergibt sich daraus das im 32Bit Umfeld die doppelte Anzahl an Intructions in den Cache, Pipeline und Branchperdiktion geladen werden kann. Wenn diese damit dann auch umgehen können ergibt das einen Geschwindigkeitsvorteil.
Flo Haber schrieb: > Ich habe gelesen, dass eine 64 bit cpu bei smartphones selbst in einer > 32 bit software umgebung eine bessere performance zeigen als 32 Bit > prozessoren. > Wie ist das möglich? Die Aussage lautet im Kern so:
1 | Lantzsch betonte in dem Interview, dass die neuen 64-Bit-Prozessoren |
2 | ... eine bessere Performance zeigen als 32-Bit-Prozessoren. |
Und das bedeutet nur: der neue Prozessor ist schneller als der Alte. Der Grund: eine überarbeitete Prozessorarchitektur. Und das ist eigentlich EXAKT das, was ich unter Weiterentwicklung verstehe und was seit Beginn der Prozessortechnik laufend passiert. Fazit: nichts wirklich Neues, nur Evolution.
:
Bearbeitet durch Moderator
64-Bit-Prozessoren haben oft mehr Register. Damit können mehr "Variablen" schnell angesprochen werden.
Ralph schrieb: > Da oftmals die nächste Instruction im Speicher direkt die folgende > Adresse ist, ergibt sich daraus das im 32Bit Umfeld die doppelte Anzahl > an Intructions in den Cache, Pipeline und Branchperdiktion geladen > werden kann. Es besteht keinerlei Zusammenhang zwischen der Bandbreite des Instruction Fetch und der offiziellen "Bitbreite" des Prozessors. So ist auch die Anzahl parallel dekodierter und ausgeführten Befehle nicht von der Bitbreite abhängig, sondern nur von der Architektur der Implementierung. Aber neuere Prozessoren und insbesondere die 64-Bit Highend-Versionen besitzen breitere interne Busse und Cache Anbindungen und auch eine breitere Anbindung des externen DRAM. Nicht weil sie 64-Bittig sind, sondern weil die bisherigen Versionen eher für Handys auf günstig und sparsam getrimmt waren und die Speicheranbindung deshalb sehr schmal ausfiel.
:
Bearbeitet durch User
Beispiel: "The first three generations of Tegra SoCs had an embarrassingly small amount of memory bandwidth, at least compared to Apple, Samsung and Qualcomm. Admittedly, Samsung and Qualcomm were late adopters of a dual-channel memory interface, but they still got there much quicker than NVIDIA did. With Tegra 4, complaints about memory bandwidth can finally be thrown out the window. The Tegra 4 SoC features two 32-bit LPDDR3 memory interfaces, bringing it up to par with the competition. The current max data rate supported by Tegra 4’s memory interfaces is 1866MHz, but that may go up in the future." http://www.anandtech.com/show/6787/nvidia-tegra-4-architecture-deep-dive-plus-tegra-4i-phoenix-hands-on/5 Zum Vergleich: Aktuelle PC/Server-CPUs besitzen 2-4 Speicherkanäle mit je 64 Bits. Der Tegra 3 hatte einen mit 32 Bits, selbst der Tegra 4 hat nur 2 mit 32 Bits.
Lothar Miller schrieb: > Der Grund: eine überarbeitete Prozessorarchitektur. Die 64-Bit ARMs haben sowohl eine völlig neue Befehlssatzarchitektur mit mehr Registern, als auch eine aufwendiger gestaltete Implementierung als viele Vorgänger-Cores. Ob die Befehlssatzarchitektur derzeit eine Rolle spielt ist mir grad unklar - immerhin müssen dazu Betriebssystem und Anwendungen völlig neu auf 64 Bits portiert werden, sonst hat man einen 64-Bit Prozessor mit 32-Bit System wie über viele Jahre in Windows üblich war. Wie die Implementierung bei gleicher Befehlssatzarchitektur durchschlägt kann man beim Vergleich der Cortexe A7 und A15 sehen. Der Befehlssatz ist identisch, der Entwicklungszeitpunkt auch. Aber die Zielsetzung ist anders, der A7 ist für Handys vorgesehen (sehr beliebt bei den Chinesen), der A15 für Tablets. Der A15 ist schon bei gleichem Takt viel schneller als der A7, frisst aber auch viel mehr Strom. Um beides unter einen Hut zu bekommen hatte ARM schon bisher bei der 32-Bittern eine Doppelstrategie vorgesehen (BIG little): sowohl A7 Cores als auch A15 Cores auf den gleichen Chip zu packen und bei geringem Leistungsbedarf von den A15 auf die A7 umzuschalten. Die A15er sind dann samt Caches takt- und stromlos. Das ist ökonomisch machbar, da der Platzbedarf eines A7 Cores relativ zum gesamten SoC-Die gering ist.
:
Bearbeitet durch User
ok also kann man sagen, dass es nicht an 64 bit liegt, sondern generell an den verbesserungen der architektur und speicheranbindung..?
Ja. Wobei da ein ganzer Rattenschwanz an Details der Implementierung mit hineinspielt, von denen ich mir mit der Speicheranbindung nur eines rausgepickt hatte. Da sind beispielsweise noch Caches, Sprungvorhersage, Out-of-Order, uvam.
:
Bearbeitet durch User
Schau nach, wenn von den ersten Smartphones berichtet wird, die bei ÜBLICHER Benutzung NICHT TÄGLICH an das Ladegerät müssen. - DANN kannst du Fortschritt kaufen. Wenn ein Executive Vice President was verlauten lässt, macht er Versprechungen für sein Produkt. Das ist nur sein Job. Also: Wieder hinlegen und den Puls abklingen lassen...
A. K. schrieb: > Ja. Wobei da ein ganzer Rattenschwanz an Details der Implementierung mit > hineinspielt, von denen ich mir mit der Speicheranbindung nur eines > rausgepickt hatte. Da sind beispielsweise noch Caches, Sprungvorhersage, > Out-of-Order, uvam. ok danke für die erklärungen, jetzt verstehe ich es besser.
:
Bearbeitet durch User
Der Vergleich eines 32-Bit Kernes mit einem 64-er ist fast immer Sinnlos. So weit mir bekannt, gibt es keinen Prozessor, bei dem alles gleich geblieben ist, nur die Register "breiter" geworden sind. Normalerweise vergleicht man den "veralteten" Vorgänger mit dem weiterentwickelten Nachfolger. Diesen Ausgang kann man sich wohl denken. Interessant wird aber der Vergleich, wenn man annimmt, dass der Neue immer ein doppelt so großes Datenvolumen schaufeln muss wie der Vorgänger. Also doppelte Datenbreite, doppelte Befehlslänge und doppelt solange Adresse.
Bernie schrieb: > Schau nach, wenn von den ersten Smartphones berichtet wird, > die bei ÜBLICHER Benutzung NICHT TÄGLICH an das Ladegerät > müssen. - DANN kannst du Fortschritt kaufen. > > Wenn ein Executive Vice President was verlauten lässt, > macht er Versprechungen für sein Produkt. Das ist nur sein > Job. > > Also: Wieder hinlegen und den Puls abklingen lassen... Sehr interessant, mein gut vier Jahre altes Smartphone lade ich etwa einmal pro Woche auf, bei nur wenig unter "typischem Nutzungsverhalten".
Amateur schrieb: > Interessant wird aber der Vergleich, wenn man annimmt, dass der Neue > immer ein doppelt so großes Datenvolumen schaufeln muss wie der > Vorgänger. Also doppelte Datenbreite, doppelte Befehlslänge und doppelt > solange Adresse. Was nicht zutrifft. Die Befehlslänge ist völlig unabhängig von der Datenbreite. Ein 64-Bitter hat keine 64 Bit breiten Befehle, auch in Befehlen codierte Konstanten sind nicht unbedingt breiter. Ebenso sind die verarbeiteten Daten nicht doppelt so breit. In den beiden gängigsten 64-Bit Datenmodellen in C (LP64 und LLP64) ist "int" nur 32 Bits breit. Streng doppelt breit sind tatsächlich nur die Adressen in Registern und im Speicher - nicht aber in den Befehlen. Der RAM-Verbrauch von ansonsten gleichen 64-Bit Programmen steigt hauptsächlich durch breitere Adressen im RAM, d.h. Pointer. Die Befehlscodierung zu vergleichen kann auch noch eine gewisse Rolle spielen, aber deren Bilanz ist schwerer abzuschätzen, da man dann sowohl bei PCs als auch bei ARM effektiv verschiedene Architekturen vergleicht und die grössere Anzahl Register ein 64-Bit Programm auch kürzer machen kann. Am besten vergleichbar ist hier noch amd64 vs x32 bei PCs mit Linux. Die kompakteste und schnellste Variante bei PCs ist nicht selten x32 - es verknüpft die Vorteile der amd64 Architektur mit dem reduzierten Speicherverbrauch durch 32-Bit Adressen. Zudem sollte man beachten, dass Fliesskommarechnung und SIMD-Befehle von der Adressbreite und der Datenbreite der Integer-Operationen völlig unbeeinflusst sind. Weshalb sich beispielsweise die Breite von Cache-Ports und der Durchsatz des Speichers schon länger eher an solchen Operationen als an Integer-Operationen orientiert.
:
Bearbeitet durch User
Bei x86 zeigt sich allerdings dass die modernen, 64-Bit Ausführungen mit 64-Bit Software mindestens gleich schnell laufen wie mit 32-Bit. Selbst dann wenn die Programme nicht mit grossen Datenmengen hantieren. Bei identischer HW wohlgemerkt - wenn es nicht gerade ein Atom ist. Dass der RAM Bedarf sich erhöht war zu erwarten. Erwartet wurde aber auch dass "normale" Programme eher langsamer werden, da mehr Daten schon wegen der 64-Bit Pointer über den Bus müssen. Das ist jedoch nicht eingetreten. Wie so oft laufen die Theoretiker der Realität hinterher und tun anschließend so als wenn sie es immer gewusst hätten ;).
Stefan schrieb: > Bei x86 zeigt sich allerdings dass die modernen, 64-Bit Ausführungen mit > 64-Bit Software mindestens gleich schnell laufen wie mit 32-Bit. Selbst > dann wenn die Programme nicht mit grossen Datenmengen hantieren. Wenn du das in dieser Form vergleichen willst, musst du auf der gleichen Hardware die gleiche Befehlssatzarchitektur vergleichen. Das ist bei x86 aber i.d.R. nicht der Fall, denn mit der 64-Bit Erweiterung amd64 hat sich die markant verbessert: (1) Mehr Register, alle auch byteweise verwendbar. (2) PC-relative Adressierung von Daten (markant bei -fPIC). (3) SSE statt x87 bei Fliesskommarechnung. Im x86 Modus dieser Hardware können (1) und (2) nicht genutzt werden, und (3) wird aufgrund historischer Systemkonventionen in normaler Programmierung meist unterschiedlich gehandhabt. Das einzige Szenario, wo ein realistischer Vergleich bei PCs gut möglich ist, ist amd64(=x64) gegenüber dem in Linux unterstützten x32 Modell. Da sind Befehlssatz/Register identisch, der Unterschied ist einzig die Nutzung als 64-Bit v. 32-Bit Architektur.
:
Bearbeitet durch User
Soweit ich weis, laufen programme unter Android in ner Java-VM. Weiss net wie das bei Apple is, aber das könnte ein grund sein, warum "32-Bit" programme auf nem 64-Bit prozessor schneller laufen.
Lukas Straub schrieb: > Soweit ich weis, laufen programme unter Android in ner Java-VM. Weiss > net wie das bei Apple is, aber das könnte ein grund sein, warum "32-Bit" > programme auf nem 64-Bit prozessor schneller laufen. Apple verwendet Objective C, also einen herkömmlichen Compiler. ARMs 64-Bit Architektur ist freilich mit ARMs 32-Bit Architekturen inhaltlich nicht verwandt, sondern komplett neu entstanden. Es ist daher nicht möglich, aus Vergleichen zwischen 64-Bit ARMv8 und 32-Bit ARMv7 Systemen und Programmen allgemeine Aussagen über die Performance von 64-Bit und 32-Bit Programmierung abzuleiten, da eben nicht nur die Breite sondern auch die Befehlssatzarchitektur eine andere ist. Interessanter wären da Erfahrungen mit IBMs Power Architektur auf Systemen, in denen diese in beiden Spielarten verwendet wird, wie etwa AIX. Da ist wirklich nur die Breite unterschiedlich.
:
Bearbeitet durch User
Lukas Straub schrieb: > Soweit ich weis, laufen programme unter Android in ner Java-VM. Weiss Nein, sie laufen in einer Dalvik-VM.
A. K. schrieb: > Am besten vergleichbar ist hier noch amd64 vs x32 bei PCs mit Linux. Die > kompakteste und schnellste Variante bei PCs ist nicht selten x32 - es > verknüpft die Vorteile der amd64 Architektur mit dem reduzierten > Speicherverbrauch durch 32-Bit Adressen. Meine Beobachtung ist, dass auf x86-Systemen rechenintensive gcc-kompilierte Software im der 64-Bit-Version schneller ist als die gleiche Software der 32-Bit-Version. Auf einem Mehrprozessorsystem unter Solaris ist die 64-Bit-Version ca. 30% schneller. Auf Einprozessor-Linux-Systemen kommt ebenfalls die 64-Bit-Version schneller zum Ergebnis. Demgegenüber ist auf einem Solaris-SPARC-System kein Unterschied zwischen 32- und 64-Bit-Version feststellbar. Bei den Vergleichen wurden die 32- und 64-Bit-Version auf jedem System mit dem gcc erstellt. Die gleiche Software unter Windows mit MSVC kompiliert weist keine Performanz-Unterschiede in den 32- und 64-Bit-Versionen auf. Der Vergleich zwischen Windows und Linux bzw. Solaris macht in diesem Fall keinen Sinn, da einerseits die Hardware der Solaris-Systeme nicht mit dem Rest vergleichbar ist und andererseits auf den Windows-Systemen die üblichen Desktop-Rechner-"Beigaben" (Virenschutz etc.) mitlaufen.
A. K. schrieb: > Das einzige Szenario, wo ein realistischer Vergleich bei PCs gut möglich > ist, ist amd64(=x64) gegenüber dem in Linux unterstützten x32 Modell. Da > sind Befehlssatz/Register identisch, der Unterschied ist einzig die > Nutzung als 64-Bit v. 32-Bit Architektur. PS: Bei der Suche drauf achten, dass viele Leute x32 und x86 verwechseln.
ich kenne mich nicht so gut aus, aber wäre es möglich die 64 bit in 2x 32 bit aufzuteilen um 2 32 werte gleichzeitig zu berechnen?
Flo Haber schrieb: > ich kenne mich nicht so gut aus, aber wäre es möglich die 64 bit in 2x > 32 bit aufzuteilen um 2 32 werte gleichzeitig zu berechnen? Das geht so einfach nicht. Dafür braucht es Dinge, wie die SSE/MMX Erweiterung (SIMD) Ansonsten ist es schwierig weil Überläufe, Vergleiche, etc extra betrachtet werdebn müssen. Nur für einen kleinen Teil von Operationen (z.B. Bitweise Logik ohne Flagprüfung) kannst du so einen Vorteil herausholen. Aber z.B. ein simpler 32 Bit Addierer: 0x88888888 + 0x88888888 -> 0x11111110 + Flags 0x00000000 + 0x11111111 -> 0x11111111 in einem simplem 64 Bit Addierer konkateniert: 0x0000000088888888 + 0x1111111188888888 -> 0x1111111211111110 Den Überlauf da auszuklamüsern ist aufwendiger als es direkt in 2 ALU Operationen zu machen.
Flo Haber schrieb: > ich kenne mich nicht so gut aus, aber wäre es möglich die 64 bit in 2x > 32 bit aufzuteilen um 2 32 werte gleichzeitig zu berechnen? Das geschieht seit langem im Rahmen von zunächst MMX, später SSE Befehlen. Aber dafür werden separate ALUs verwendet, denn ALUs einzusparen lohnt nicht, wenn die Daten deshalb einen weiten Weg durch verschiedene Teile eines Prozessors nehmen müssten. Das braucht nämlich Raum und Zeit.
:
Bearbeitet durch User
Maxx schrieb: > Den Überlauf da auszuklamüsern ist aufwendiger als es direkt in 2 ALU > Operationen zu machen. Da die ganzzahligen SSE Befehle ihre Operanden in wählbar 8, 16 oder 32 Bit breite Teile aufdröseln, sind dort vermutlich schon entsprechend konfigurierbare Recheneinheiten im Einsatz. > Den Überlauf da auszuklamüsern ist aufwendiger als es direkt in 2 ALU > Operationen zu machen. Das sehe ich bei Addern eigentlich nicht als arg kompliziert an.
:
Bearbeitet durch User
ARMv8 ist für 32Bit (oder kleiner) eher noch schlechter als die Vorgänger, weil auch hier nur max 32 OPcode-bits möglich sind! (Man musste also vom Vorgänger Befehle für 64Bit (nur LD/ST) abzwacken)
MCUA schrieb: > (Man musste also vom Vorgänger Befehle für 64Bit (nur LD/ST) abzwacken) Nein. ARMv8 basiert nicht auf der Codierung von ARMv7, das ist keine Erweiterung, sondern ein Neudesign. Es gab also nichts abzuzwacken.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.