ARM: Android-Lager beschleunigt Wechsel auf 64-Bit

Die Gerätehersteller beeilen sich nach Angaben der Chipschmiede ARM mit dem Wechsel auf neue 64-Bit-fähige SoCs für Smartphones und Tablets. Noch in diesem Jahr sei mit den ersten Geräten auf Basis von Android zu rechnen, so ARM. mehr... Snapdragon, Qualcomm Snapdragon, Qualcomm Snapdragon 810, Qualcomm Snapdragon 800, Qualcomm Snapdragon 801, Qualcomm Snapdragon 808, Qualcomm Snapdragon 805 Bildquelle: Qualcomm Snapdragon, Qualcomm Snapdragon, Qualcomm Snapdragon 810, Qualcomm Snapdragon 800, Qualcomm Snapdragon 801, Qualcomm Snapdragon 808, Qualcomm Snapdragon 805 Snapdragon, Qualcomm Snapdragon, Qualcomm Snapdragon 810, Qualcomm Snapdragon 800, Qualcomm Snapdragon 801, Qualcomm Snapdragon 808, Qualcomm Snapdragon 805 Qualcomm

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Apple hats erfunden und ARM macht es nach.
 
@azuram20: Apple nutzt ARM-Designs - nur so zur Info xD

und 64Bit gab es bei Intel und AMD laaaaaaaaaaaaange vorher..
 
@DRMfan^^: Apple hat aber als erstes in smartphone eingebaut!
 
@azuram20: Zwischen "als erstes einbauen" und "erfinden" gibt es Unterschiede. Just sayin.
 
@DRMfan^^: 64bit cpu`s gab es schon laaaange bevor Intel und amd damit ums eck kamen....
 
@azuram20: Blöd nur, dass ARM die A57-Architektur schon im Oktober 2012 präsentiert hat. Da steckten in den damals aktuellen iPhones noch 32-Bit-Prozessoren. Der A7 wird, wie im Artikel steht, erst im iPhone 5S verwendet, was im September 2013 raus kam.
 
warum sind 32bit Apps schneller, wenn sie auf 64Bit CPUs laufen? das wäre mal interessant zu wissen?!
 
@DRMfan^^: Bezüglich x86 und AMD64/Intel 64 ist der Grund die generell verbesserte Prozessor-Architektur, welche auch 32-Bit-Anwendungen beschleunigt. Denke mal, das wird hier ganz ähnlich sein.
 
@DRMfan^^: Unser Softwarepaket für Fraktalberechnung musste man extra für 64 Bit optimieren. Jetzt läuft es flott. Komplexe Programme muss man optimieren, während man bei Browser, EMail Nutzung nichts merkt. Verstehe seine Aussage also auch nicht.
 
@gola: Fraktalberechnung ist aber auch was sehr spezielles und beinhaltet wohl viel »Low Level« Mathematik. Sorry, falls ich da falsch liege, kenn mich da nich so aus und kann mir persönlich grad kaum vorstellen, wo man so ein Softwarepaket braucht. Aber da is aus meiner Sicht klar, dass man wirklich optimieren muss, um aus einer 64-Bit-Architektur mehr rauszuholen.
Was andere Programme betrifft, wenn denn ein Geschwindigkeitszuwachs bei der neuen Architektur vorhanden ist, dann liegt das meistens nur an der neuen Architektur, nicht an der 64-Bit-Fähigkeit der neuen Architektur.
 
@DRMfan^^: möglicherweise aus deswegen, weil der 64 Bit Prozessor mehr Speicher hat und einem/jedem 32 Bit Prozess volle 4 GB zur Verfügung stellen könnte … sofern vorhanden natürlich
 
@DRMfan^^: Deswegen, weil bei einer 64 bit Architektur pro Takt deutlich mehr daten durchgeschaufelt werden können, als bei einer 32 bit Architektur. Der Effekt ist aber bei 32 bit anwendungen eher zu vernachlässigen. Bei echten 64 bit anwendungen kann das aber große Vorteile bringen.
 
@FatEric: Ja, kann man. Allerdings passiert das bei 32Bit Anwendungen meines wissen nicht automatisch, daher meine Verwirrung
@Der_da: Guter Punkt, da spart man die Auslagerung auf den sekundären speicher
 
@DRMfan^^: Bei x86-CPUs war es wirklich so, dass die Vor- und Nachteile sich gegenseitig ausgeglichen haben und wir solange genug RAM da war, beim Wechsel ungefähr die selbe Leistung wie vorher hatten. Bei ARMv8 kommen jedoch beim Wechsel eine neue Architektur mit etlichen Zusatzbefehlen dazu, die generell für eine höhere Leistung sorgen werden. Die 64-Bit Speicheradressierung ist dabei fast schon nur noch ein kleines Randdetail, welches sich allerdings ziemlich gut vermarkten lässt.
 
Komisch, ich dachte 64 Bit wäre jetzt nicht nötig? ... Moment mal, die Hersteller fühlen sich doch jetzt nicht von einem seit 20 Jahren insolventen Unternehmen aus Cupertino, dessen Untergang dank Innovationsmangel kaum aufzuhalten war, unter Druck gesetzt?
 
@gola: Siehe diese Anwendungen und den Bericht warum 64bit und nicht 32bit (beide sind Musikanwendungen auf einem ARM 64bit CPU): djay
With full support for the A7’s 64-bit architecture on iPhone 5s, djay 2 now brings desktop-class power to mobile DJing:

Up to 2x faster audio analysis on A7 using fully optimized 64-bit processing. djay auto-analyzes BPM, beat grids, waveforms, sound frequencies, gain, as well as the key of each song. With the iPhone 5s, users will now load and process tracks even faster, preparing the perfect transition in their performance without missing a beat.
Harmonic Match™: High precision key detection and key matching, leveraging 64-bit audio processing. This allows users to create pitch-perfect mashups by adjusting one song’s key to match another in real-time. For example, if one song is in D major and the other song in E major, djay can now transpose a song in real-time to match its key with that of the other song, for an even more seamless transition.
vjay
With full support for the A7’s 64-bit architecture on iPhone 5s, vjay now brings desktop-class power to mobile video mixing:

HD video playback, mixing, effects, and recording on iPhone 5s brings more than double the video render resolution, processing more than 4 times more video data in real-time. This is done by leveraging the A7’s 64-bit processor, including its significant graphics performance improvements. This allows vjay to playback, record, and mix videos in HD resolution with cutting-edge power rivaling desktop systems.
HD video and smoother playback at higher video frame rate when sharing vjay’s mixed video output via AirPlay using iPhone 5s. With this advancement, vjay users will experience stunning, low-latency connectivity to TV playback all without even connecting any wires.
 
@AlexKeller: ich versteh nicht, wieso Du nen Minus kassierst. 64Bit verdoppelt die Befehlslänge. Man kann jetzt also 8 statt nur 4 Befehle zeitgleich verarbeiten. Die Effizienz ist zwar nicht ganz doppelt so hoch, aber "up to 2x" stimmt technisch gesehen schon. Hinter 64 Bit steht halt bisschen mehr als nur Adressierung von Speicher, sondern eben auch Adressierung der Befehle etc.
 
@TurboV6: kann man. aber wie soll dass einfach so passieren? die Anwendung muss mW zumindest für x64 neu kompiliert werden, damit das klappt.
 
@DRMfan^^: nicht unbedingt. a) macht das Betriebssystem ja selbst viel und b) Apps parallel laufen lassen.
 
@TurboV6: "Man kann jetzt also 8 statt nur 4 Befehle zeitgleich verarbeiten." Theoretisch ja! Praktisch spielt Kausalität aber eine entscheidende Rolle!? Sprich die anstehenden Aufgaben müssen sich auch zeitgleich erledigen lassen und dürfen sich nicht bedingen. Dann funktioniert es. Aber eben nur dann! - Ein vielleicht blödes Beispiel, einen Baum pflanzen: Loch gragen -> Baum setzen -> Loch auffüllen -> gießen. Das sind 4 "Aufgaben" die Du wohl kaum gleichzeitig erledigen kannst, weil Eine die Andere bedingt!?
 
@OPKosh: ist ja nich so, dass ein Smartphone nur eine Aufgabe hat. Ist ja vieles, was da parallel läuft - auch heute schon. Und diese Aufgaben (Zeit, Wlan, App, Daten, Anzeige...) können nun effizienter parallel ablaufen. Geht ja um mehr als nur die App selbst.
 
@TurboV6: Was Du meinst ist Parallelisierung. Das hat aber nichts mit 32bit vs. 64bit zu tun. Bei 32bit vs. 64bit geht es nicht darum mehrere Apps parallel laufen zu lassen, sondern mehrere "Berechnungen" EINER App parallel laufen zu lassen. Das geht aber nur, wenn die eine Berechnung nicht das Ergebnis der Anderen voraussetzt!? - Ein erneutes, vielleicht wieder nicht so ganz perfektes, Beispiel: Wenn ich a+b=c berechnen will, aber a=x+y ist, kann ich c erst errechnen wenn ich vorher(!) a errechnet habe?! Egal also wie sehr es theoretisch möglich WÄRE beide Gleichungen gleichzeitig zu berechnen, weil die Rechenleistung da ist, es geht trotzdem nicht. - Nochmal! Mir ist bewußt, dass es kein perfektes Beispiel ist! ;-) (Man könnte natürlich (x+y)+b=c rechnen! ;-)) Aber ich denke Du verstehst trotzdem was ich meine.
 
@OPKosh: natürlich hat das was damit zutun. Weil mehr Befehle parallel abgearbeitet werden können. Das hat nichts mit einem Multitasking System zutun. Das sind technisch 2 paar Stiefel.
 
@TurboV6: Ein jeder Befehl in einem "Rechner" ist eine "Berechnung"!? Und du kannst eben nur Berechnungen gleichzeitig durchführen, wenn sie sich nicht gegenseitig bedingen!!! Ich kann zwei Berechnungen nicht zur selben Zeit durchführen, wenn ich zur Berechnung der Einen das Ergebnis der Anderen vorher brauch. Auch nicht wenn ich statt "Berechnung" "Befehl" dazu sage.
 
@OPKosh: nein. Hast Du noch nie Hardwarenah entwickelt? Ein CPU Befehl fürs ALU hat nichts mit Abhängigkeiten zutun. Klar, wenn Du eine Addition hast dann sind das bei Objective C nachher 4 Befehle und Java 7 Befehle (das, was nachher bei der ALU ankommt, nicht Zwischencode). Die 4/7 Befehle sind abhängig voneinander. Aber Du kannst problemlos die Befehle von Addition 1 und Addition 2 parallel in einem Befehlsregister laufen lassen, da diese atomar sind.
 
@TurboV6: Er meint wohl den Begriff Datenabhängigkeit, natürlich gibt es im Pipelining ein paar klevere Tricks, komplett lässt sie sich aber nicht aufheben. Er sagt einfach, die Chance einer Auslastung von 100% aller Recheneinheiten ist nahezu unmöglich.
 
@TurboV6: Ich hab nirgens geschrieben, dass es gar nicht ginge, oder?! Ich sagte, es kommt darauf an ob es geht oder nicht. Was Du beschreibst geht mit 16bit-Opperatoren auf 32bit-Prozessoren jetzt auch schon!? Und wenn Du von hardwarenah sprichst ist das eher eine Frage der Optimierung?! - Meine Programmierzeiten sind lang her. Da hat man einem noch beigebracht, dass man sich sehr genau überlegen sollte wie groß man eine Variable deffinieret. ;-) Und hier reden wir von "Apps" um Himmels Willen! Und nicht von Teilen wie 3DS Max?!
 
@OPKosh: klar. 32 Bit Prozessoren können - wie gesagt - 4 Befehle zeitgleich verarbeiten. Ein Befehl hat in einer ALU dieser relevanten Art eine Befehlslänge von 8 Bit. 16 Bit eben nur 2 Befehle. Hinzu kann dann halt noch der Bus kommen und der Cache aber im Prinzip ist das so. Es geht hier ja wie gesagt auch nicht direkt um die Vorteile der Apps; die sind nur minimal bei x64. Es geht um die Gesamtvorteile eines Systems sowie des Betriebssystems. Hinzu kommt eben die Möglichkeit, dass mehr Kerne integriert werden können (das wäre dnn das Thema Adressierung). Das hat wiederum einen Vorteil für den Akku: statt 2 große Kerne gibt es 8 kleine Kerne, die sic einzeln abschalten bzw drosseln lassen. Wenn also derzeit nichts gebraucht wird rennt nicht 1/2 Kernen, sondern 1/8 weils völlig ausreicht und so den Akku schohnt.
 
@floerido: natürlich. Aber x64 hat eben ein paar mehr Vorteile als dass nur eine App mehr als 2 GB adressieren kann (was die heutigen mobilen Betriebssysteme ohnehin selbst über virtuelle Adressräume regeln).
 
@TurboV6: x64 hat zwar unter Umständen ein paar Vorteile, aber es hat auch ein paar Nachteile: größeren Speicherbedarf aller Apps durch doppelte Adresslänge, verlangsamte Ausführung von 32-Bit Apps wenn keine Optimierung greift, erhöhter Akkuverbrauch. Die beschriebenen Vorteile greifen leider nur in sehr wenigen Fällen wie langjährige Erfahrung zeigt. Die Nachteile greifen aber immer. Das wird sich erst ändern, wenn angepasste Apps existieren, die die Vorteile eines 64-Bit Prozessors nutzen. Davon ist aber bisher rein gar nichts absehbar.
 
@Nunk-Junge: wie bitte? x64 mehr Speicherbedarf der Apps? Höher Akkuverbrauch? Langsamer? Hinsetzen, 6.
 
@TurboV6: Lol, denk erst einmal nach! Dank lies Fachartikel! Dann lösche einfach Deinen Kommentar!
 
@Nunk-Junge: ich bin u.a. in der direken Entwicklung von Embedded Software auf direkter Hardware tätig. Ich weiß wie das Spektrum funktioniert. Aber danke. Nur weil x64 verwendet wird heisst das noch lange nicht, dass ein einzeler Speicherbereich eine Variable etc größer wird. Was sind das für unlogische Aussagen.... Schule aus?
 
@TurboV6: *seufz* Ja, Schule aus - seit vielen, vielen Jahren. Das waren noch schöne Zeiten. Zum Thema: Beim Umstieg auf 64-Bit wird jede Speicheradresse doppelt so lang, also jede Variable, jede Codeadressierung, jedes Objekt. Dadurch steigt natürlich der Speicherbedarf. 64-Bit sind nunmal mehr als 32-Bit. Natürlich ändert sich nicht der Inhalt der Variablen, sondern die Adressierung. Nun kannst Du das umgehen, wenn Du eine 32-Bit-Umgebung für die Apps schaffst. Das iPhone machst das so ähnlich. Dann hast Du aber eine 32-Bit-Umgebung neben der 64-Bit-Umgebung im Speicher zu halten = höherer Speicherbedarf. Für Dich als Programmierer: Datentypen sind teilweise Archtitektur-abhängig. Ein Pointer wird auf einem 64-Bit-System eben 8 Byte brauchen, auf 32-Bit eben nur 4 Byte. Integer ist teilweise plattformabhängig (z.B. in C++), d.h. die werden auch doppelt so groß. ...
 
@TurboV6: Doch, es ging gerade um die Vorteile von 64bit für die Apps! Und die sind, wie Du jetzt selbst sagst(!), minimal. Eben! Genau darum ging es mir! - Und mit der Kernanzahl hat 64bit nun überhaupt nichts zu tun! Also was kommst Du jetzt damit? Es gibt jetzt auch schon "achtkernige" (weil eigentlich nur 2x4) 32bit-CPUs. Das kann den Akku schonen, ja, aber das geht und macht man eben auch schon länger mit 32bit?!
 
@TurboV6: weil im Text vom dem "Apfel" die Rede ist, klar ich hätte das raus löschen können, aber dann hätte ich den offiziellen Text verfälscht. Um wirklich nachvollziehen zu können welche Leistungsunterschiede vorhanden sind, muss man ein 32bit Tablet und ein 64bit Tablet mit der gleichen App in Betrieb nehmen. ist übrigens mit der gleichen App möglich da ein "Hybridmodus" vorhanden ist.
 
@AlexKeller: nein, das sind leider dann doch zwei verschiedene Paar Stiefel. Der Hybridmodus hat dann doch nur was mit der Kompatibilität zutun aber nicht mit der Unterstützung der längeren Befehlssätze. So einfach ist das dann in einer nativen Sprache doch nicht.
 
@TurboV6: Okay :-) bin erst am Anfang meiner Entwickerlaufbahn. Muss mich noch einlesen in die 32/64bit Geschichte auf der Dev. Seite. Habe erst seit letzter Woche das Air mit 64bit... lesen lesen lesen ist angesagt ;-)
 
@AlexKeller: bei modernen Programmiersprachen muss man sich um x64 und x86 eigentlich nicht mehr kümmern. Erst mit der Verbindung alter Elemente wie COM oder Contextübergriffen spielt das dann wieder eine Rolle.
 
@gola: man diese gleichziehung von 64 bit und innovation ist ja nun echt nur zum schnarchen. die 64 bit stellen eine evolution da, mittlerweile gibt es tatsaechlich android smartphones die 3 gb ram verbauen und in naher zukunft werden hier wohl auch die 4 gb gesprengt werden. und diese dann mit 32 bit paging gefrickel zu verwalten muss nun heute nicht mehr sein. also nein, es hat wirklich nix damit zu tun, dass apple bei seinen endgeraeten bereits 64 bit am laufen hat (was dort uebrigens total sinnbefreit erscheint - naja ausser die werbewirksamkeit, das hat ja bei dir super geklappt)
 
Welchen Sinn hat es eigentlich bei Smartphones auf 64Bit zu setzen?
 
@L_M_A_O: kostet kaum mehr, bringt etwas mehr performance, macht sich aber unfassbar gut auf dem Prospekt!
 
@FatEric: Wo soll es den mehr Performance bringen? Ich könnte mir eher vorstellen, das es durch 64Bit Adressierung bei einem Smartphone langsamer wird.
 
@FatEric: 64-Bit bringen KEINE Performance, sondern senken die Performance bei Ausführung von 32-Bit Apps (also praktisch allen). Eine Geschwindigkeitssteigerung wird aktuell erreicht durch verbesserte Prozessorarchitekturen, nicht durch den Umstieg auf 64-Bit.
 
@L_M_A_O: Mehr gleichzeitig bearbeitbare befehle. Dies steigert die Effizienz und somit erhöhte Leistung bei gleichem Energieverbrauch oder gleiche Leistung bei geringerem Energieverbrauch. Der Fortschritt mag zwar teilweise im Smartphone Sektor übertrieben sein. Aber da der Energieverbrauch begrenzt ist, wird stets versucht die Effizienz zu steigern. Auch Quad und Octacores versuche nichts anderes, als bessere Effizienz zu erzielen. Daraus resultiert eben immer niedrigerer Energieverbrauch bei bisherigen Aufgaben und mehr Leistung für neue Aufgaben bei gleicher Stromaufnahme.
 
@L_M_A_O: Für 96 % der Menschheit sind 64bit doppelt so so schnell wie 32bit und damit doppelt so gut. So ist der Mensch nun mal.
 
@L_M_A_O: Bei Apple bringt es wenig, weil der iKram weit weniger als 4 GB RAM hat. Bei den Android-Geräten ist es schon eher interessant.
 
@TiKu: So ein Blödsinn. 64-Bit hat weit mehr Vorteile als die Menge an Arbeitsspeicher, die verwendet werden kann.
 
@ger_brian: Kannst du diese, für ein Smartphone relevanten, Vorteile nennen?
 
@floerido: siehe o4:re3, da ist das recht gut beschrieben. Außerdem, wie in o4:re8 erwähnt eine effizientere grafikberechnung.
 
@ger_brian: danach hast du wie viel Leistungsgewinn auf dem Smartphone 0,01% ? Nur weil man die doppelten Befehle ausführen kann hat man nicht daraus resultierend gleich doppelte Leistung. Man hat ja gesehen wie viel das ganze auf dem Desktop bringt. Das war nicht viel.
 
@ger_brian: Ja, z.B. bei der Berechnung "größerer" Zahlen, oder extrem vieler Kommastellen. Die Frage ist aber eben ob das bei "Apps" auf einem SP so viel bringt? Ok, bei Spielen und vorallem deren Grafikberechnungen, ja! - Aber schau doch mal auf den PC. Wieviel, oder besser wie wenig, ist da selbst heute 64bit?! Bei Programmen wie 3DS Max, Photoshop, AfterEffects oder dergleichen, ok. Aber bei Apps auf nem SP?! Wirklich?!
 
@OPKosh: Spiele / Grafikberechnungen werden durch die GPU gemacht, nicht durch den Prozessor. Und die GPU ist schon lange auf 64-Bit...
 
Wieso wechselt den jetzt das Android lager auf 64bit? Laut dem Androidfanlager bringt 64 Bit nichts ausser eine größere Speicheradressierung. Jedenfalls wurde das von sehr vielen hier bei der 5s vorstellung behauptet. Und Androidfans müssen es ja wissen, weil das sich doch alles IT-Experten die täglich Ihr smartphone flashen um neue CM ausprobieren zu können... Wär doch jetzt mal lustig die Postings von Tiku und Co auszugraben...
 
@Fanel: gibt's die denn noch? Die sind sicherlich von den Usern selbst gelöscht. :-)
 
@Fanel: Das Android-Lager könnte ja auch weiter auf die 2004 veröffentlichte ARMv7-Architektur bauen, nur irgendwann ist das Design auch ausgereizt. Der Wechsel auf ARMv8 ist in den Roadmaps vorgesehen, sie wurde 2013 zuerst von AMCC umgesetzt und dann später von Apple. Wenn man ein aktuelles Layout bei ARM kaufen möchte, dann muss man eben zu ARMv8 mit allen Funktionen, zB. 64-Bit, greifen. Die 6. Generation hat gut 10 Jahre gehalten, die 5. nur 2 Jahre, die 5. Generation hat 5 Jahre und die 4. Generation auch etwa 5 Jahre. Das in der gerade im Moment gehypten Phase die Prozessorentwicklung so lange stillstehen konnte, ist erstaunlich. In dem neuen Design ist zB. big.LITTLE oder bessere Crypto nicht nachträglich integriert worden, sondern von Grund auf berücksichtigt worden.
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles