Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie schnell sind Mikroprozessoren für Mobilfunktelefone?
Gibt es dazu irgendwelche Daten, Benchmarks und Vergleiche?
Mich würde z.B. mal interessieren wie schnell die ARM CPU des iPhone im Vergleich zu einem OMAP 2420 oder OMAP 3430 ist, welche ebenfalls zur ARM Architektur gehören aber in Handys und Geräte von Nokia verbaut werden.
Und dann wäre da noch die Frage welchen Einfluß die Taktrate des verbauten Arbeitsspeichers auf die CPU Geschwindigkeit hat, denn große Caches dürften diese CPUs ja nicht gerade haben.
Spasstiger
2009-10-04, 23:20:43
Der Prozessor im iPhone 3G S (und zum Beispiel auch im Samsung Jet) ist ziemlich leistungsstark und beherrscht sogar Out-of-Order-Execution. Im Vergleich zu den anderen Mobilprozessoren dürfte das so wie ein Pentium 4 gegen einen Core 2 Duo sein, wobei der Core 2 Duo sogar noch höher taktet. ;)
/EDIT: Oder hab ich da was missverstanden und der Cortex A8 im iPhone 3G S unterstützt doch noch keine out-of-order-execution? Wird das erst beim Nachfolger Cortex A9 der Fall sein?
P.S.: Ein OMAP 3xxx hat doch einen Cortex-A8-Core.
Nein beherrscht er nicht. Das kann erst der Cortex A9.
Spasstiger
2009-10-04, 23:29:01
Nein beherrscht er nicht. Das kann erst der Cortex A9.
Ah, ok. Da hab ich wohl mal was missverstanden. Das nächste iPhone soll ja einen Cortex-A9-Core bekommen. Und ich sehe gerade, dass das Teil soviel Power hat, dass man es sogar in Linux-Netbooks einsetzen möchte.
Das heißt noch lange nicht, dass er in einem iPhone wo der SOC keine 2W verbraucht auch so schnell ist ;)
Und glaube ich auch nicht, dass das iPhone das einzige Smartphone mit Cortex A8 auf dem Markt ist.
Spasstiger
2009-10-04, 23:45:44
Und glaube ich auch nicht, dass das iPhone das einzige Smartphone mit Cortex A8 auf dem Markt ist.
Ist es auch nicht, das Samsung Jet hat z.B. auch einen Cortex-A8-CPU-Core und einen PowerVR-SGX-535-GPU-Core wie das iPhone 3G S. Hatte das Samsung Jet schon in der Hand. ;)
Hydrogen_Snake
2009-10-04, 23:59:35
Palm Pre hat den schon länger nur doof das es so spät kam.
BlackBirdSR
2009-10-05, 00:04:02
Gibt es dazu irgendwelche Daten, Benchmarks und Vergleiche?
Mich würde z.B. mal interessieren wie schnell die ARM CPU des iPhone im Vergleich zu einem OMAP 2420 oder OMAP 3430 ist, welche ebenfalls zur ARM Architektur gehören aber in Handys und Geräte von Nokia verbaut werden.
Und dann wäre da noch die Frage welchen Einfluß die Taktrate des verbauten Arbeitsspeichers auf die CPU Geschwindigkeit hat, denn große Caches dürften diese CPUs ja nicht gerade haben.
Ist kaum zu machen. Neben der eigentlichen CPU kommt dann noch die Software ins Spiel. Je nach OS und Zusatzfunktionen, wird die CPU ganz anders beansprucht. Einen umfassenden Benchmark, der alle gleich behandelt, kann es so nicht geben. Selbst wenn, dann hättest du auch nur normierte Ergenisse ohne Praxisbezug.
Die Angabe der reinen Leistungsdaten ist dann auch ziemlich nutzlos. Ist leider nicht so einfach
(del)
2009-10-05, 00:06:02
Der Prozessor im iPhone 3G S (und zum Beispiel auch im Samsung Jet) ist ziemlich leistungsstark und beherrscht sogar Out-of-Order-Execution.:| Gibt es noch irgendwelche anderen Verarbeitungsarten oder bedeutet das demnach, daß der A8 in-order ist?
BlackBirdSR
2009-10-05, 00:09:09
:| Gibt es noch irgendwelche anderen Verarbeitungsarten oder bedeutet das demnach, daß der A8 in-order ist?
Entweder du führst deine Befehle schön nach Reihenfolge aus, oder du fängst irgendwo an, Arbeitsschritte selbst umzuordnen. Wo und wie genau das passiert, ist dann natürlich wieder eine sehr facettenreiche Sache.
In diesem Fall ist gemeint, dass die Befehle strikt so durch die Ausführungs-Stufe kommen, wie sie vom Compiler angeordnet wurden. Das heißt natürlich nicht, dass es nicht hier und da ein paar Tricks gibt, so macht es Atom ja auch.
(del)
2009-10-05, 00:44:24
Nein schon ok. Ich wollte nur wissen, ob der A8 dann demnach also in-order ist. Weil Spasstiger out-of-order irgendwie als ein Leistungsfeature darstellte :|
Was so nicht stimmt. Wenn ich wie der Atom mit für out-of-order bestehenden Kompilaten kämpfen muß, dann ist das eine andere Geschichte als wenn ich vom Anfang an für in-order programmiere und kompiliere. Selbst nur rekompiliert rast so ein Power6 wie ein Wahnsinniger...
Out-of-order ist also kein Prädikat für irgendwas. Nur dumm für A8 Smartphone-User fände ich vorerst, daß der A9 wieder out-of-order ist. Weil wenn man den in 4G oder was auch immer nutzen wird, alte iPhone-Soft dadrauf wieder lahmer laufen wird (wegen Smartphone neu, Software mitnehmen) Genauso neue Soft auf altem iPhone usw.
Wenn man Abwärtskompatibilität anbietet, dann sollte man sich für eine Architektur imho halbwegs langfristig festlegen. Leistung im Überfluß hat man auf Smartphones noch lange nicht. Hier zählt für mich jeder MIPS.
Oder übersehe ich hier etwas?
Spasstiger
2009-10-05, 00:58:39
Was macht man, wenn mehrere Anwendungen parallel laufen? Dann bringt die beste Compileroptimierung auch nichts mehr, weil die Befehle nicht in der gewünschten Reihenfolge ankommen.
(del)
2009-10-05, 01:25:36
Was haben die Befehlsfolgen der einzelnen Anwendungen miteinander zu tun? :|
Power6 ist wie gesagt in-order. Das ist Dualcore mit auch noch 2fach SMT und das Teil geht brutal ab. Viel brutaler als man durch die Frequenzen gegenüber dem Power5+ erwarten würde.
Den kümmern deine Einwände überhaupt nicht. Da das Teil nicht von Intel stammt rockt es sogar den Kode für die out.of-order POWER, aber wirklich explodieren tut es nach einer Neukompilierung.
Jetzt nur weil Itanium für immer eine NischenCPU bleibt und Intel auch noch den Atom auf bestehenden x86-Kode losläßt, heißt das noch lange nicht, daß in-order allgemein ein Irrweg wäre.
Bis dann mal.
p.s.:
Klasse multithreaded, die rohe Leistung mal unbeachtet, ist schon mein W880i. Damit kann ich z.B. im Telefonbuch zappen, während eine längere SMS noch verschickt wird ;) Oder den MP3-Pat nutzen während ich welche tipper. Und das genauso schnell als wenn ich keine SMS während dessen verschicke. Das hat mit in-order oder out-of-order nichts zu tun.
Was macht man, wenn mehrere Anwendungen parallel laufen? Dann bringt die beste Compileroptimierung auch nichts mehr, weil die Befehle nicht in der gewünschten Reihenfolge ankommen.
Zwischen Taskwechseln vergehen einige tausend Takte ;)
Weil wenn man den in 4G oder was auch immer nutzen wird, alte iPhone-Soft dadrauf wieder lahmer laufen wird (wegen Smartphone neu, Software mitnehmen)
Das ist Quatsch. Eine OOO-Architektur mit gleicher Einheitenanzahl und gleichem Takt wird immer schneller sein als eine gleichwertige In-Order-Architektur, auch wenn der Code für IO kompiliert wurde. In welcher Reihenfolge die Befehle stehen ist dann schließlich egal.
Was so nicht stimmt. Wenn ich wie der Atom mit für out-of-order bestehenden Kompilaten kämpfen muß, dann ist das eine andere Geschichte als wenn ich vom Anfang an für in-order programmiere und kompiliere. Selbst nur rekompiliert rast so ein Power6 wie ein Wahnsinniger...
Natürlich "stimmt das so" bei gleicher Frequenz.
Darauf abgestimmter Code hilft In-Order Architekturen auch nur zum Teil, denn OOO erlaubt auch das vorziehen von Instructions wenn man auf den Speicher warten muss, und bei Schleifen und Sprüngen weiß der Compiler auch nicht welche Instruction auf welche folgt.
Da das Teil nicht von Intel stammt rockt es sogar den Kode für die out.of-order POWER
Was soll diese dämliche Anspielung jetzt? Jede In-Order-CPU hat potentiell das gleiche Problem mit Code der für eine OOO-Architektur kompiliert wurde, nämlich dass die Einheiten nicht so gut wie es möglich wäre ausgelastet werden.
IBM hat dort eine Designentscheidung getroffen die Ausführungseffizienz gegen höheren Takt tauscht. Ob diese Rechnung auch im Ultra-Low-Power embedded Bereich aufgeht ist eine ganz andere Frage. ARM wird nicht ohne Grund beim A9 damit anfangen Befehle umzusortieren.
Dein gehasster Itanium ist übrigens auch In-Order, wenn man von spekulativer Ausführung absieht.
(del)
2009-10-05, 01:54:26
Das ist Quatsch. Eine OOO-Architektur mit gleicher Einheitenanzahl und gleichem Takt wird immer schneller sein als eine gleichwertige In-Order-Architektur, auch wenn der Code für IO kompiliert wurde.Ok. Danach hab ich ja vorher schon gefragt, aber dann warst du noch nicht wieder im Thread.
Obwohl seitdem du mir erzählt hast, daß eine HD-ATI durch die schnelle Emu keine Probleme mit 2D haben wird, bin ich gegenüber jeglichen betonfesten fachmännischen Aussagen im Netz recht mißtrauisch geworden... ich guck mir das also heute abend alles selbst mal an im Netz.
Was soll diese dämliche Anspielung jetzt? Jede In-Order-CPU hat potentiell das gleiche Problem mit Code der für eine OOO-Architektur kompiliert wurde, nämlich dass die Einheiten nicht so gut wie es möglich wäre ausgelastet werden.Nein. Das ist Halbwissen aka große Klappe was den POWER6 angeht. Ich hab vorher noch kurz drübergeflogen und der Power6 ist auch keine 100% reine in-order, da es im Design paar Skills gibt, die den out-of-order Kode leicht aufmischen. Was Intel im auf Verbrauch getrimmten Atom nicht macht (oder es so nicht drauf hat).
Wie gesagt schau ich mir das abends nochmal genauer an, an den echten Quellen.
Mit Spasstiger Multitasking hats jedenfalls so oder so nichts zu tun.
Bis dann erstmal.
p.s.:
Ich weiß, daß Titanium in-order ist :| und ich mag den Nano auch viel lieber als den Atom. Mit geht es nur um die Grundsätze. Wenn aber in-order bei gleicher einheitenanzahl und gleichem takt auf out-of-order besser oder wenigstens gleichwertig perfomen kann, desto besser. Das war der "Anstoß" sich hier zu Wort zu melden (und was dazuzulernen, da die für mich interessanten Fragen im Thread bis dahin noch garnicht fielen).
Ok. Danach hab ich ja vorher schon gefragt, aber dann warst du noch nicht wieder im Thread.
Obwohl seitdem du mir erzählt hast, daß eine HD-ATI durch die schnelle Emu keine Probleme mit 2D haben wird, bin ich gegenüber jeglichen betonfesten fachmännischen Aussagen im Netz recht mißtrauisch geworden... ich guck mir das also heute abend alles selbst mal an im Netz.
ATI legt darauf leider nicht viel Wert in den Treibern. Im Gegenteil, sie entfernen da scheinbar sogar Dinge aus den XP-Treibern um wohl Kosten zu sparen. Aber das ist völlig OT.
Nein. Das ist Halbwissen aka große Klappe was den POWER6 angeht. Ich hab vorher noch kurz drübergeflogen und der Power6 ist auch keine 100% reine in-order, da es im Design paar Skills gibt, die den out-of-order Kode leicht aufmischen. Was Intel im auf Verbrauch getrimmten Atom nicht macht (oder es so nicht drauf hat).
Wie gesagt schau ich mir das abends nochmal genauer an an den echten Quellen.
Doch, auch Atoms können in gewissen Fällen eine Art OOO machen.
Spielt im Endeffekt auch keine große Rolle. Ein 3,2Ghz Nehalem und ein 5,0 Ghz Power6 bringen laut SPEC fast identische Performance.
Die Frage ist jetzt nur noch was weniger Strom verbraucht. Ich würde ja fast auf den Nehalem tippen ;)
Wenn aber in-order bei gleicher einheitenanzahl und gleichem takt auf out-of-order besser oder wenigstens gleichwertig perfomen kann, desto besser.
Natürlich. Das ist aber rein hypothetisch, weil es in der Praxis niemals passieren wird ;)
(del)
2009-10-05, 02:04:13
Ok dann noch was anderes dazu. Aus irgendeiner Sicht, da der Markt für den POWER nicht gerade PR-mäßig nur auf Ghz abfährt, mußte die Entscheidung auf in-order zu gehen für IBM schmackhaft gewesen sein. Aus welcher demnach? Die für POWER-Generationen gewöhnliche Leistungssteigerungen hätten sie beim 6er auch so erreichen können.
Hast du den "SPEC-Link" zu Power6. Danach hab ich vorher auch schon gesucht :(
Das musst du die Engineers fragen. Es hat alles seine Vor- und Nachteile. Einer von In-Order ist, dass die Schaltungen sehr viel einfacher werden.
SPEC-Ergebnisse gibt's hier: http://www.spec.org/cpu2006/results/
(del)
2009-10-05, 02:21:05
Natürlich. Das ist aber rein hypothetisch, weil es in der Praxis niemals passieren wird ;)Wenn der A9 aber mit weniger Takt den A8 Kode mindestens gleichschnell ausführt, läßt sich das daraus vernünftig ableiten ;)
Wichtiger wäre es aber, daß sie dabei den Verbrauch im Griff behalten. Akkus mit größerer Kapazität für gleichbleibende Laufzeiten sind nicht das Problem, aber das geht nachwievor immernoch sehr auf das Gewicht des Akkus und auf so eine "Neuentwicklung" bei Smartphones hab ich echt keinen Bock. Auf kürzere Ladeintervalle ebenfalls nicht.
Ok Nacht dann :freak:
Und glaube ich auch nicht, dass das iPhone das einzige Smartphone mit Cortex A8 auf dem Markt ist.
Richtig, denn das Nokia N900 ist auch noch da und frisch auf dem Markt.
Aber das ist jetzt zweitrangig, viel wichtiger wäre mir, wenn mal endlich einer Links zu Benchmarks oder ähnlichem liefern könnte.
Wage Aussagen wie "das ist schneller als das" helfen mir nicht besonders viel.
Ist kaum zu machen. Neben der eigentlichen CPU kommt dann noch die Software ins Spiel. Je nach OS und Zusatzfunktionen, wird die CPU ganz anders beansprucht. Einen umfassenden Benchmark, der alle gleich behandelt, kann es so nicht geben. Selbst wenn, dann hättest du auch nur normierte Ergenisse ohne Praxisbezug.
Aber ich hätte zumindest mal einen Vergleich des Gesamtsystems bestehend aus CPU und OS Overhead.
Und in der Praxis hätte ich den OS Overhead ja sowieso.
Entscheident wäre also nur noch, auf welchem Phone man besser Number Crunching machen kann.
Nein schon ok. Ich wollte nur wissen, ob der A8 dann demnach also in-order ist. Weil Spasstiger out-of-order irgendwie als ein Leistungsfeature darstellte :|
Also out-of-order klingt mehr nach Stromverschwender und das auf einem mobile Phone.
Eine leicht zu programmierende CPU Architektur wie eben die ARM Architektur und bessere Compiler macht da sicher mehr Sinn.
Das musst du die Engineers fragen. Es hat alles seine Vor- und Nachteile. Einer von In-Order ist, dass die Schaltungen sehr viel einfacher werden.
Und weniger Transistoren notwendig sind und somit viel mehr Energie gespart wird.
Solange es keine Akkus zum Klotzen gibt, wird OOO bei Handys jedenfalls keinen Sinn machen und neben der Akkulaufzeit muß man ja auch noch die Abwärme berücksichtigen.
Schließlich will niemand mit einem Bügeleisen telefonieren.
Und weniger Transistoren notwendig sind und somit viel mehr Energie gespart wird.
Solange es keine Akkus zum Klotzen gibt, wird OOO bei Handys jedenfalls keinen Sinn machen und neben der Akkulaufzeit muß man ja auch noch die Abwärme berücksichtigen.
Schließlich will niemand mit einem Bügeleisen telefonieren.
Eine OOO-Architektur braucht weniger Takt und damit auch weniger Spannung als IO um gleiche Leistung zu erreichen.
Prinzipiell zu sagen, dass OOO mehr Energie verbraucht halte ich für sehr kurzsichtig. Da kann es ab einer bestimmten Integrationsdichte sogar Vorteile für OOO geben.
robbitop
2009-10-05, 09:47:01
Ist der Power7 nicht bereits eine Rückkkehr zum OoO-Execution Prinzip? Beim Einsatzgebiet von solchen Serverprozessoren laufen oftmals Anwendungen, die von Anwendungen auf Privatgeräten stark abweichen. Datenbanken, Cruncher etc. sind hervorragend parallelisierbare Anwendungen mit wenig unsortiertem Code, so dass OoO eh wenig bringt. In Spielen oder ähnlichen Anwendungen aus dem privatem Bereich, hätten diese jedoch erhebliche Nachteile.
Der Cortex A9 scheint, nach bisherigen Aussagen von den Devboardusern, ein ziemlicher Stromschlucker zu sein. Ich hoffe, dass das bei der 40 nm Serienproduktion dann anders aussieht.
Limit
2009-10-09, 09:31:56
OoO dient in erster Linie den Grad an ILP (Instruction Level Parallelism) zu erhöhen. Vor allem bei sehr breiten Architekturen (mit vielen Ausführungseinheiten) macht das Sinn, da durchschnittlicher Code nur 1-2 Instruktionen pro Takt und Thread hergibt. Hat man also sowieso nur 2 Ausführungseinheiten wie z.B. Atom ist ein OoO Design nicht unbedingt notwendig. Bei Architekturen mit mehr Ausführungseinheiten (K10 3 ALUs, Core 4 ALUs) hilft es aber deutlich die Auslastung zu verbessern.
Für Low Power CPUs mit eher schmalem Design halte ich OoO für überflüssig. Der Zugewinn bei z.B. 2 Ausführungseinheiten ist im Vergleich zu den Kosten eigentlich nicht relevant. Natürlich ist OoO nicht immer gleich implementiert. Man könnte z.B. eine sehr einfache Variante implementieren, die nicht so viel Transistoren kostet und trotzdem die Auslastung verbessert.
Die hochgezüchteten Einheiten bei K10 oder Core sollten da sicherlich nicht der Maßstab sein.
Was so nicht stimmt. Wenn ich wie der Atom mit für out-of-order bestehenden Kompilaten kämpfen muß, dann ist das eine andere Geschichte als wenn ich vom Anfang an für in-order programmiere und kompiliere. Selbst nur rekompiliert rast so ein Power6 wie ein Wahnsinniger...
Das hängt praktisch nur am compiler, Assembler programmieren wohl die wenigsten.
Natürlich kann ein in order gleich schnell wie mit out of order sein, nämllich genau dann wenn der compiler die Instruktionen genau so anordnet wie es der OOO-Prozessor für die optimale durchführung machen würde.
Problematisch ist natürlich, dass man die Befehle nicht im vorraus für jeden Fall optimal sortieren kann, das betrifft natürlich insbesonders Sprungbefehle.
Das nächste ist, dass der "optimale" Code mit einer neuen CPU schon wieder ganz anders aussehen kann, im prinzip bräuchtest du also für jede CPU ein eigenes komplilat um sie perfekt auszunutzen.
Ist es auch nicht, das Samsung Jet hat z.B. auch einen Cortex-A8-CPU-Core und einen PowerVR-SGX-535-GPU-Core wie das iPhone 3G S. Hatte das Samsung Jet schon in der Hand. ;)
Welchen Chip vermutest du im Samsung Jet?
Aber das ist jetzt zweitrangig, viel wichtiger wäre mir, wenn mal endlich einer Links zu Benchmarks oder ähnlichem liefern könnte.
Wage Aussagen wie "das ist schneller als das" helfen mir nicht besonders viel.
schieb
robbitop
2009-10-15, 15:36:58
OoO dient in erster Linie den Grad an ILP (Instruction Level Parallelism) zu erhöhen. Vor allem bei sehr breiten Architekturen (mit vielen Ausführungseinheiten) macht das Sinn, da durchschnittlicher Code nur 1-2 Instruktionen pro Takt und Thread hergibt. Hat man also sowieso nur 2 Ausführungseinheiten wie z.B. Atom ist ein OoO Design nicht unbedingt notwendig. Bei Architekturen mit mehr Ausführungseinheiten (K10 3 ALUs, Core 4 ALUs) hilft es aber deutlich die Auslastung zu verbessern.
Für Low Power CPUs mit eher schmalem Design halte ich OoO für überflüssig. Der Zugewinn bei z.B. 2 Ausführungseinheiten ist im Vergleich zu den Kosten eigentlich nicht relevant. Natürlich ist OoO nicht immer gleich implementiert. Man könnte z.B. eine sehr einfache Variante implementieren, die nicht so viel Transistoren kostet und trotzdem die Auslastung verbessert.
Die hochgezüchteten Einheiten bei K10 oder Core sollten da sicherlich nicht der Maßstab sein.
Der P3 hatte 2x Pipelines, der C3/C7 von VIA auch. Die IPC-Differenzen waren enorm. Oder man vergleiche Pentium vs Pentium PRO.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.