Dynamic Multicore Architectures

[Syrakus]

http://research.microsoft.com/en-us/projects/e2/

Traditional power scaling methods such as dynamic voltage
and frequency scaling (DVFS) are becoming less effective
given the current trends of transistor scaling.

One possible direction is to use architectural innovations to
distribute execution of each thread across a variable number
of processing cores in a flexible manner


.pdf
http://research.microsoft.com/apps/pubs/default.aspx?id=180078

Na, wer traut sich? Daumen in den Wind, wie lange werden die brauchen bis wir was sehen. xD

[Shink]

E2 is configurable to provide:

- Many physical cores working independently
- Many physical cores working in parallel to perform the same operations on multiple data sets simultaneously
- Many physical cores composed together to form logical processors for quickly accelerating single-threads of execution
Mh... ist man da heute wirklich so weit weg?

Erinnert mich an:
Ein Modul ist in verschiedene einfach und doppelt vorhandene Einheiten aufgeteilt, die sich zudem manche Ressourcen teilen. Ein Modul verfügt über zwei Integer- (Ganzzahl) und eine 256-Bit-Floatingpoint-(Gleitkommazahl)-Einheit, die bei Bedarf in zwei 128-Bit-FPUs aufgeteilt werden kann. Die Fetch-und-Decode-Einheit sind ebenfalls nur einfach vorhanden und teilen die Last auf die jeweiligen Einheiten auf.

Ein Modul verfügt über die folgenden unabhängigen Einheiten:
- Zwei unabhängige Integer-Einheiten mit jeweils zwei ALUs und zwei AGUs, die maximal vier Arithmetik- und Speicheroperationen unabhängig pro "Core" und Takt ausführen können.
- Zwei symmetrische 128-Bit-FMAC-Gleitkommapipelines pro Modul, die bei Bedarf in eine 256-Bit-Einheit umfunktioniert werden können, und dadurch für einen FMA-Befehl verwendet werden können, der anders als der normale Multiply-Add-Befehl erst nach Ende der kompletten Berechnung das Ergebnis rundet.


Klar, dynamischer geht immer. Aber sooo weit weg sind wir dann auch wieder nicht....

[2phil4u]

Die Frage ist, wie die Zuteilung zur Runtime geschieht ?
Wenn bsp ein Thread 2 Berechnungen hintereinander ausführt, die unabhaengig voneinander sind, so müssten die Befehle quasi gleichzeitig in der CPU vorliegen, so dass diese die Berechnungen auf 2 unterschiedliche Cores verteilt.
Genial ware es natürlich, wenn die CPU quasi immer alle Cores voll auslastet und auch weiss, wie die Prioritaeten sind.
Bsp kann in einem Programm der eine Thread sehr wenig Ressourcen verbrauchen und quasi sehr wenig Rechenleistung verbrauchen, so dass er dann nur hin und wieder mit HT zusaetzlich berechnet wird, waehrend ein anderer Thread massgeblich limitiert und so bestmöglich auf unterschiedliche Cores aufgeteilt wird, bsp in Spielen.
Kann mir vorstellen, dass durchaus 100% mehr Performance drin sind.

[Tesseract]

Die Frage ist, wie die Zuteilung zur Runtime geschieht ?
Wenn bsp ein Thread 2 Berechnungen hintereinander ausführt, die unabhaengig voneinander sind, so müssten die Befehle quasi gleichzeitig in der CPU vorliegen, so dass diese die Berechnungen auf 2 unterschiedliche Cores verteilt.
Genial ware es natürlich, wenn die CPU quasi immer alle Cores voll auslastet und auch weiss, wie die Prioritaeten sind.
Bsp kann in einem Programm der eine Thread sehr wenig Ressourcen verbrauchen und quasi sehr wenig Rechenleistung verbrauchen, so dass er dann nur hin und wieder mit HT zusaetzlich berechnet wird, waehrend ein anderer Thread massgeblich limitiert und so bestmöglich auf unterschiedliche Cores aufgeteilt wird, bsp in Spielen.
Kann mir vorstellen, dass durchaus 100% mehr Performance drin sind.

das machen compileroptimierungen und der system-scheduler seit jahren. das problem an der sache ist, dass die feststellung von unabhängigkeit in vielen fällen nicht trivial ist und eine analyse mehr performance kosten würde als man damit gewinnt.

[sloth9]

http://research.microsoft.com/en-us/projects/e2/



.pdf
http://research.microsoft.com/apps/pubs/default.aspx?id=180078

Na, wer traut sich? Daumen in den Wind, wie lange werden die brauchen bis wir was sehen. xD

schon da:
big.little bei ARM.
Für das OS transparent.
Geht ja in den Links um die Grenzen von Stromsparmechanismen wie TAkten und SPannung verändern, wie hier einige wohl nicht gelesen haben..

[Syrakus]

MS werkelt hier an etwas für Sie großem. Die Referenzen aus der 2010 Publikation verweisen gleich an erster stelle zum Phoenix (compiler framework) und lassen erahnen das sie auf ARM Cortex Basis experimentieren. In der 2013 Publikation ist Qualcomm Research gleich an erster Stelle aufgelistet. Wenn man jetzt MS strategische exklusiv Partnerschaft mit Qualcomm dazu nimmt wirft das schon ein interessantes Licht, aber ja nur ein Bauchgefühl xD

http://en.wikipedia.org/wiki/Phoenix_%28compiler_framework%29

big.little, AMDs HSA usw sind alles nur Auswüchse asymmetrischer Chip Integration.

MS will hier die Entscheidung ob seriell oder parallel zukünftig direkt von der Hardware treffen lassen. Das soll eine komplett neue Architektur werden. Der Unterschied zwischen cpu und gpu würde zum Teil fallen.

[Ailuros]

MS will hier die Entscheidung ob seriell oder parallel zukünftig direkt von der Hardware treffen lassen. Das soll eine komplett neue Architektur werden. Der Unterschied zwischen cpu und gpu würde zum Teil fallen.

Zumindest aus dem geliefertem wikipedia link oben kann ich nichts dergleichen herauslesen. Was verpass ich gerade? :confused:

[PatkIllA]

schon da:
big.little bei ARM.
Für das OS transparent.Das OS muss auch noch mitspielen. Idealerweise kennt es alle Cores. Dann kann er die kleinen und großen sogar parallel benutzen.

[sloth9]

Nein, muss es nicht.
Es sieht nur ein Core pro Paar, und je nach Last wird gewechselt. Parallel-Benutzung ist unerwünscht, da der kleinere eh kaum Performance bringt. Bitte mal einlesen!
Bei 4+4 werden 4 Cores erkannt, der Wechsel ist P-State abhängig, jeder CPU-Pärchen teilt sich Cache.

[PatkIllA]

Damit das funktioniert muss das auf OS auf jeden Fall die "richtigen" Powerstates anfordern. Wenn das nicht ordentlich passiert dürfte der Vorteil sowohl bei Performance als auch der Stromverbrauch leiden.
In a big.LITTLE SoCs, the OS kernel dynamically and seamlessly moves tasks between the 'big' and 'LITTLE' CPUs. In reality this is an extension of the operating system power management software in wide use today on mobile phone SoCs.

Most OS kernels already support Symmetric Multi-core Processing (SMP) and those techniques can easily be extended to support big.LITTLE systems.

Außerdem gibt es auch einen Modus, wo sich das OS komplett des big.Little Ansatz bewusst ist und entsprechend die Tasks auf die Cores verteilt. Da können dann sogar alle Cores gleichzeitig arbeiten und es muss kein 1:1 Verhältnis eingehalten werden.

[mboeller]

das hier kennt ihr aber schon:

http://www.cs.virginia.edu/~skadron/Papers/federation_dac08.pdf

gibt aber noch mehr PDF's dazu.

Ist zwar nicht ganz das selbe, passt hier IMHO aber rein.....aus 2 A7 wird 1 "A14"

[Skysnake]

Zumindest aus dem geliefertem wikipedia link oben kann ich nichts dergleichen herauslesen. Was verpass ich gerade? :confused:
Das ist das HSA Konzept ;)

[Affinator]

Hat sich hier überhaupt schon jemand die Mühe gemacht die verlinkten Paper zu lesen?

Auf den ersten Blick sieht das durchaus interessant aus. Es scheint als wollen sie dynamisch Cores so anordnen, dass der DAG (s. Compilerbau) direkt durch die Cores abgebildet wird. D.h. nicht mehr ein Befehl pro Takt, sondern mehrere ABHÄNGIGE Befehle parallel. (Also als Steigerung zum klassischen multi-skalar bzw. OutOfOrder).

Ich kann hier nicht so schnell drüberschauen, aber das sieht weitaus komplizierter aus als simples Big.Little und etc.

[Coda]

Das Problem was ich diesem Ansatz sehe ist, dass Daten auf dem Chip zu verschieben das ist was heutzutage am meisten Energie verbraucht. Ich kann deshalb mir nicht vorstellen, dass eine so völlig konfigurierbare CPU auch nur annäherend bei der Energieeffizienz mithalten kann.

Das Abhängigkeiten bereits vom Compiler in die Instruction-Sequenz kondiert werden ist übrigens nichts neues. Itanium macht das zum Beispiel auch.

[Skysnake]

Naja, wenn CPU und iGPU sehr feingranular verschmelzen, also das jeweils 1CPU Kern xGPU-CUs hat, dann kann man das auch mit recht wenig Aufwand machen. Man stelle sich z.B. auch vor, CPU-Core und iGPU-CUs würden sich den L2 teilen. Da kann man dann schon verdammt viel Schindluder treiben, um das effizienter zu machen.

Nehmen wir doch z.B. mal die Skalarunit bei GCN raus, und ersetzen das durch einen x86 CPU Core ;) Hört sich das nicht verdammt interessant an?

Das könntest du dann auch von SFF bis hin zu den fettesten SMP-Maschinen skalieren. Für SFF nimmste zur Not halt nen ARM-Core rein, der nochmals effizienter ist.

Also Möglichkeiten gibt es da, man muss sich nur mal darauf einigen, was die Hardware, Compiler und Programmierer übernehmen sollen.

Verdammt cool wäre aber auch nen "FPGA" Design, in dem man einfach nur "massig" Register/Cache hat, und ansonsten die ganzen ALUs eben direkt zur Laufzeit "programmiert". Fragt sich halt nur, wie viel Energie man fürs umprogrammieren brüchte.

Für "Programmierer" wäre es aber wohl die Hölle, bis mal wirklich leistungsfähige und! umfangreiche (funktionierende!!!) Bibliotheken da wären.

[Affinator]

Naja, die Arbeiten zu solchen "adaptiven" Rechnern (z.B. auf FPGA-Basis) sind ja schon einige Jahre (bis Jahrzehnte) alt. Eines unserer Institute war da mal sehr aktiv. Es existiert auch ein interner Compiler der bei passender Annotation die entsprechenden Codeblöcke auf den FPGA schiebt und schneller ausführt. (Die Anlaufgeschwindigkeit ist entsprechend übel.)

Das Problem sind da eher die Kontextwechsel in modernen Betriebssystemen, bei denen man jedes Mal die Einheiten neu konfigurieren muss (bei vorgegebener FPGA-Struktur). Hier existiert zwar immer noch Potenzial (live unrolling of loops), aber da eine Serienreife zu erreichen ist wohl nicht umsetzbar. Proprietäre Geschichten (s. Konsolen) sind da durchaus spannender. Die Netzwerkgeschichten die Nvidia jetzt nach ihrem Einkauf in den neuen Tegras machen, gehen da ja "grob" in so eine Richtung.

[Skysnake]

Naja, bisher war das aber eher etwas uninteressant, da du so einfach nicht zur Laufzeit den FPGA umprogrammieren konntest früher.

[Affinator]

Dynamisches Rekonfigurieren geht auf FPGAs jetzt aber schon einige Jahre. Es macht nur einfach zu wenig Sinn, wenn häufig gewechselt werden muss. Für SmartTVs und Settopboxen wird das meines Wissens aber schon teilweise zum Wechseln der Codecs eingesetzt (in den teuren Geräten).

[Coda]

Nehmen wir doch z.B. mal die Skalarunit bei GCN raus, und ersetzen das durch einen x86 CPU Core ;) Hört sich das nicht verdammt interessant an?
Nein, es hört sich verdammt dämlich an.

[Skysnake]

Dynamisches Rekonfigurieren geht auf FPGAs jetzt aber schon einige Jahre. Es macht nur einfach zu wenig Sinn, wenn häufig gewechselt werden muss. Für SmartTVs und Settopboxen wird das meines Wissens aber schon teilweise zum Wechseln der Codecs eingesetzt (in den teuren Geräten).
Da haste aber im Normalfall das Image, und musst es dann drauf laden. Dafür ist meist noch ein kleiner Extrachip verbaut, der das übernimmt. Die FPGAs an sich können das meist nicht.

Meines wissens nach können das nicht mal die meisten aktuellen Karten.

Nein, es hört sich verdammt dämlich an.
Wieso?
Du hast ja weiterhin die normale FPU, falls du darauf anspielst.

[Gipsel]

Wieso?
Du hast ja weiterhin die normale FPU, falls du darauf anspielst.
Die Skalar-ALU bei GCN ist recht eng in die ganze Scheduling-Geschichte der 4 SIMD-Einheiten eingepaßt. Jeden Takt kann eine Instruktion aus einem der Scheduler abgearbeitet werden, so daß am Ende genau ein 1:1 Verhältnis von vALU- und sALU-Issuekapazität herauskommt. Das ist mit dem Round-Robin-Scheduling zwischen den 4 Schedulern/SIMDs auch zyklusgenau mit der Skalareinheit synchronisiert. Die vALUs können ja z.B auch direkt auf Skalarregister zugreifen (wird per Broadcast an alle Slots der vALU verteilt). Das funktioniert sehr effizient, weil man unspekulativ und in order arbeitet. Das tut ein (moderner) x86er Prozessor nun mal nicht. Der verschwendet also entweder massig Resourcen für nichts (die SIMDs und durchsatzoptimierter Code haben nichts davon, wenn die Skalareinheit spekulative OoOE könnte) oder man kocht ihn soweit herunter, daß der Sinn eines x86er-Kerns weg wäre. Und da GCN eine ISA mit mehr oder weniger konstanter Instruktionslänge benutzt (Instruktionen sind entweder 4 Byte oder 8 Byte lang) und man daraus einen großen Teil der Einfachheit von Decode/Issue erhält, wäre die Implementation von x86 für Skalarinstruktionen ziemlich hirnverbrannt.
Und wenn man es andersrum sieht, nämlich daß Decoding auf der x86er-CPU vonstatten gehen soll, verliert man den Vorteil des verteilten Schedulings mit den bis zu 40 gleichzeitig verwalteten Instruction-Pointern pro CU (was das Instruktion-Scheduling und die Erreichung der relativ niedrigen Latenzen erschweren würde) und man muß die x86-CPU mit 40fach SMT aufbohren, was wohl auch eher wenig Sinn macht.

[mksn7]

Was an ILP da ist, dürfte doch durch OoO und Superskalarität doch schon ganz gut ausgenützt werden. Die dann noch eher spärlich vorhandene ILP dann auch noch auf zwei Kerne zu verteilen, dürfte nicht viel Sinn machen.

Beim Lesen des Threads hab ich erstmal aufs Datum geschaut. Klingt wie ein typisches Konzept aus der Anfangszeit der Dualcores, als kaum ein Programm parallel skaliert hat. Da war doch mal was mit Scouting threads, die schonmal die nächst benutzten Speicherbereiche vorladen sollen.

[Ailuros]

Fuer die "jack of all trades, master of none" Schnappsidee der Vereinigung bzw. Verschmelzung von CPU und GPU cores kann ich nAo (wie schon etliche Male in der Vergangenheit) voll zustimmen:

http://forum.beyond3d.com/showpost.php?p=1720641&postcount=134

I keep thinking we all live in separate and non communicating universes. In the universe where I live power is the N.1 concern, from phones to peta or exascale machines. Fixed function HW won't be replaced by programmable HW in any significant way any time soon. One day the (in)famous wheel of reincarnation will spin again but that day doesn't seem to be exactly around the corner.

Sonst wenn Ihr Sarkasmus bzw. Komoedie im feinstem lesen wollt dann:

http://forum.beyond3d.com/showthread.php?t=63229

posts #18 bis #21:

It's probably best to design for SIMD/MIMD hybrid ala Dally's proposal (with MIMD coming at increased power consumption) and then allow some kind of pipeline linking for VLIW similar to what AMD had at reduced performance (with the same staggered register access to allow you to keep the number of ports down). A processor designed to extract a little extra parallelism at a cost of adding a whole lot more ports to the register file are probably never going to be ideal for GPUs (which is not to say Intel's process advantage might still not be able to pull it out ahead of course).

Dally's proposal is still the closest to the ideal from anyone with some authority to appeal to.

But Dally's proposal also included a bunch of latency optimized cores in addition to the SIMD/MIMD throughput cores

You can tie those cores to SIMD/MIMD arrays and then leave the arrays doing nothing when you're running single threaded code on them ... then you can call them unified too.

Then Nick would be stretching his definition of "unified" to the point where this "unification" defeats its supposed purpose.

:D;D:freak:

[Gipsel]

Sonst wenn Ihr Sarkasmus bzw. Komoedie im feinstem lesen wollt dann:

http://forum.beyond3d.com/showthread.php?t=63229

posts #18 bis #21Du kannst auch direkt den Post 18 im Thread verlinken (http://forum.beyond3d.com/showthread.php?p=1718225#post1718225). ;)

[Syrakus]

http://www.cs.wisc.edu/multifacet/papers/hpca08_keynote_amdahl.ppt

Ab Seite 33 wird es interessant.


Von der tu-dresden gibt es auch was. die verweisen aber nur auf die keynots von 08
Seite 29

http://tu-dresden.de/die_tu_dresden/fakultaeten/fakultaet_informatik/tei/vlsi/lehre/vortr_pro_haupt/folder.2010-04-30.7782863372/amdahl_final.pdf

Resultat und Schlussfolgerungen:
-dynamische Multikerne können höhere Beschleunigungen liefern als asymmetrische Systeme

-mit der Einteilung in sequentiell und parallel kann eine höhere Beschleunigung nur durch dynamische Techniken erreicht werden

-es müssten dazu mehr Kerne zur Bearbeitung des sequentiellen Anteils zusammengefügt werden als momentan möglich ist

-Entwickler sollten daher Methoden untersuchen die dynamische Multikerne annähern

[Gipsel]

http://www.cs.wisc.edu/multifacet/papers/hpca08_keynote_amdahl.ppt

Ab Seite 33 wird es interessant.


Von der tu-dresden gibt es auch was. die verweisen aber nur auf die keynots von 08
Seite 29

http://tu-dresden.de/die_tu_dresden/fakultaeten/fakultaet_informatik/tei/vlsi/lehre/vortr_pro_haupt/folder.2010-04-30.7782863372/amdahl_final.pdfDas Problem mit der Veröffentlichung von Hill und Marty, auf die sich das Ganze wesentlich bezieht, ist daß schon ihre wichtigste Voraussetzung nicht hinhaut: "we assume that (micro-) architects have techniques for using the resources of multiple BCEs to create a core with greater sequential performance" (BCE steht bei denen für "base core equivalent" und gibt die Menge an Resourcen für einen normalen seriellen Kern an). Weiterhin nehmen sie an, daß für serielle Probleme die Zusammenschaltung von n Kernen eine Performance von sqrt(n) ergibt. Das ist schon eine recht schräge Annahme, vor allem, da man das nie verallgemeinern kann. Bei strikt seriellem Code (keinerlei Parallelität) ist es sogar schlicht Schwachsinn. Egal wie viele Kerne man da kombinieren würde, die Performance läuft da in ein sehr hartes Limit (welches bei normalen Kernen bei der Performance eines einzelnen liegt).

Und wie jemand anders hier im Thread bereits angemerkt hat, berücksichtigt dieses krude Modell auch keinerlei Auswirkungen auf den Stromverbrauch (die es sicherlich geben würde, falls es möglich wäre, die Resourcen von Kernen so zu kombinieren, wie sie es annehmen).

Edit:
Achja, falls das irgendwer nicht mitgeschnitten hat, die oben verlinkte Präsentation im Design der TU Dresden ist ein Seminarvortrag, den ein Student da am 21.07.2010 gehalten hat (http://tu-dresden.de/die_tu_dresden/fakultaeten/fakultaet_informatik/tei/vlsi/lehre/vortr_pro_haupt/haupts_prosem) (habe jetzt keine Lust rauszusuchen, welches Semester der war). ;)

[Syrakus]

Das Interesse an dieser Technologie scheint aber zu steigen, immerhin kann man dem Dokument von 2013 entnehmen das amd, nvidia, Qualcomm usw, mit ins Forscher Boot gesprungen sind. Intel hat bestimmt auch irgend ein Forschungsprojekt in die Richtung am laufen. Die implementieren doch nicht x86 in ihre MICs wenn sie sich nicht erhoffen würden irgend wann mal paar Transistoren durch das Universalisieren von Teilen ihrer verschiedenen Pipelines einsparen zu könnten.

Ich würde gern die Figuren auf Seite 10 der 2013 Veröffentlichung verstehen. Muss mir mal die Zeit nehmen, der Tobak ist aber schon Hart xD

[Gipsel]

Die implementieren doch nicht x86 in ihre MICs wenn sie sich nicht erhoffen würden irgend wann mal paar Transistoren durch das Universalisieren von Teilen ihrer verschiedenen Pipelines einsparen zu könnten.Transistoren sparen war sicher nicht der Beweggrund dafür. ;)
Zumal die Anzahl der Transistoren ein eher nachgeordneter Punkt für die Zukunft sein dürfte, entscheidend sind andere Sachen (Performance/Watt).
Ich würde gern die Figuren auf Seite 10 der 2013 Veröffentlichung verstehen. Muss mir mal die Zeit nehmen, der Tobak ist aber schon Hart xD
Na ist doch ganz einfach. Dort ist aufgetragen, wie hoch die Performance und der Energieverbrauch beim Zusammenschalten einer variablen Anzahl von Kernen (ihr Design ist der T3) in SpecInt2k und SpecFP2k wären (ist ja eine Simulation). und zwar beim Vergleich zu einem recht alten Atom (zwischen 0,8 und 1,6GHz) und einem ebenso altem Core2 (zwischen 1,6 und 2,4GHz).

Im besten bzw. schnellsten Fall kommen 16 kombinierte "T3"-Kerne in SpecInt auf die Performance eines einzelnen ~2GHz Core2-Kerns bei in etwa gleichem Energieverbrauch (die 1 entspricht jeweils einem einzelnen T3-Kern). Man sieht aber deutlich, daß eine weitere Steigerung der Kernanzahl nicht mehr viel bringen würde (der Sprung von 8 auf 16 bringt vergleichsweise wenig bis gar nichts). Dies ist genau das, was ich oben schon mal angesprochen habe: bei wirklich seriellen bzw. beinahe seriellen Workloads kann ein einzelner Kern beinahe alles extrahieren, was mit vertretbaren Mitteln erreichbar ist. Die Kombination von Kernen bringt da keine Mehrperformance, nur ein mehr an Overhead und schlußendlich ein unnötig kompliziertes Design.

In SpecFP sieht es aus Performancesicht etwas besser aus. Dort können mehrere kombinierte Kerne einen Core2-Kern deutlich schlagen. Das bei mäßig höherem oder sogar gleichem Energieverbrauch für die Aufgabe. Dies bedeutet aber, daß die Verlustleistung um ziemlich genau den Faktor der Beschleunigung höher ist, Performance/Watt ist also nicht besser. Dies ist letztendlich lediglich Ausdruck der relativ hohen Parallelität in SpecFP. Diese kann allerdings viel effizienter über etwas breitere SIMD-Einheiten genutzt werden. Im Vergleich zu einem neueren IvyBridge oder gar Haswell-Kern dürfte das Ding alt aussehen (in SpecInt vermutlich auch).

[Syrakus]

(der Sprung von 8 auf 16 bringt vergleichsweise wenig bis gar nichts)

Also doch nur mal wieder eine Bestätigung von Amdal und kein revolutionärer Versuch die Gesetze neu auszulegen xD

Naja wenn man sich die magere Performance von ARM Franchis überkernten Soc's anschaut ist das ja zu begrüßen.
Nur scheint der Performance Sprung von Appels A5 zu A6 doch die bessere Strategie zu beinhalten, momentan zumindest xD

[Iruwen]

Imo kein gutes Beispiel für Amdahl. Und Gustafson nicht vergessen.

[Ailuros]

Also doch nur mal wieder eine Bestätigung von Amdal und kein revolutionärer Versuch die Gesetze neu auszulegen xD

Naja wenn man sich die magere Performance von ARM Franchis überkernten Soc's anschaut ist das ja zu begrüßen.
Nur scheint der Performance Sprung von Appels A5 zu A6 doch die bessere Strategie zu beinhalten, momentan zumindest xD

Was genau haben Apple's A5/6 SoCs mit dem obrigen zu tun?