News HiSilicon Kirin 950: 16-nm-FinFET und Cortex-A72-Kerne noch dieses Jahr

[Marcel55]

Sehe ich genau so.
Der perfekte SoC wäre doch eigentlich sehr einfach:
-4 A72 Kerne, kein big.LITTLE Schnickschnack.
-Grafik gibt es mehrere Möglichkeiten, ich denke die die auch im Apple A9 ist sollte gehen.
-LPDDR4 RAM, 4GB.
-Rest nach aktuellen Standards.

Mit diesem SoC hätte man mehr als genug Leistung, die Entwicklungs und Herstellungskosten halten sich im Rahmen und Updates können dank hoher Verbreitung schnell gemacht werden.

Es wäre so einfach, aber nein...man muss es ja unnötig kompliziert machen.

 

[Beyazid]

@Marcel
Die einzige Änderung die ich vorschlagen würde wäre die, dass statt 4 A72 Kernen 2 A72 + 2 A53 gebündelt werden. Man hätte den Vorteil, dass man die Kerne niedriger takten kann mit größerer Fläche pro Kern. Quasi ein sinnvolles "rüberschielen" in Richtung Apple SoC.
Android sollte meiner Meinung nach auch nicht so eine Phase durchmachen wo dann versucht wird so viele Kerne rein zu hauen wie es nur geht statt wenige kräftige zu entwickeln die beide Enden des Leistungsspektrums abdecken und sinnvoll genutzt werden (können)

 

[Cirrus]

Sehe ich genau so.
Der perfekte SoC wäre doch eigentlich sehr einfach:
-4 A72 Kerne, kein big.LITTLE Schnickschnack.
-Grafik gibt es mehrere Möglichkeiten, ich denke die die auch im Apple A9 ist sollte gehen.
-LPDDR4 RAM, 4GB.
-Rest nach aktuellen Standards.

Mit diesem SoC hätte man mehr als genug Leistung, die Entwicklungs und Herstellungskosten halten sich im Rahmen und Updates können dank hoher Verbreitung schnell gemacht werden.

Es wäre so einfach, aber nein...man muss es ja unnötig kompliziert machen.

Mit deiner Lösung wirst du keinen Spass haben! Denn das Smartphone wird dann nach einem halben Tag leer sein.
Eben deswegen gibt es das big.Little Konzept. Einzige Alternative wäre die Lösung von Qualcomm jeden Kern unabhängig von einander und dynamisch runtertakten zu können. Das ist auch meiner Meinung nach der Hauptvorteil eigener Kerne von Qualcomm, bzw. den Krait-Kernen (deren Energieeffizienz wurde hier bereits angesprochen).
Deine 4 A72 Kerne mit dem Krait-Nachfolger und ich bin dabei

 

[Shadow Complex]

geil endlich kommt einer auf die idee einen ganz kleinen core bei den monster soc von heute auf das die zu machen der reicht für das klein zeug incl start bildschierm normal aus und spart somit extreme strom.

M8 Co-Prozessor von Apple oder der Companion Core des Tegra 3 von Nvidia sagen dir nichts? Den Tegra 3 gibt es seit 2011, also wirklich keine allzu neue Idee mehr.

 

[modena.ch]

@marcel55

Die A53er in einem big.Little Verbund machen schon Sinn, erstens sind sie extrem klein und sparsam,
brauchen also nur wenig Saft und Chipfläche. Und es gibt viele Aufgaben wie SMS oder Messaging oder Musik
und Filme abspielen (wird ja heut gerne mal auf einem eigenen Videoprozessor gemacht) etc., wo es sich nicht lohnt die
A72er oder A57er anzuschmeissen.
Bei den A57ern mit A53ern im Verbund verhält es sich so, dass die A57er etwa doppelt so schnell sind,
aber 5X soviel Energie benötigen. Da wird ein A72er zwar noch einiges schneller werden, aber trotzdem 3-4x soviel
Saft benötigen.

Das kann man im Samsung Tap Pro oder Note 3 sehr gut sehen, die gibts mit denselben Specs einmal mit
Snap 800 und einmal mit Exynos 5420.
Unter hoher Last hält die Snapdragon Variante länger durch, weil die Cortex A15 (32Bit Vorgänger der A57) im Exynos doch arg am Akku nuckeln
und unter niedriger Last hält der Exynos viel länger durch, aufgrund der Cortex A7 Kerne im Exynos (32 Bit A53er Vorläufer), wo selbst
die Krait Kerne nicht so effizient heruntergetaktet/deaktiviert werden können.

Was die GPU angeht, die PVR Varianten für das iP6s oder iPad Air 2 sind Sonderkonfiguratiionen die wohl nur Apple bekommt.
Ein Mali T880 MP8 oder gar MP16 dürfte locker für alles reichen, was man sich am Smartphone vorstellen kann. auch dürften inzwischen
die Treiber für Mali besser sein als für PVR.

@Bayazid

Apples Soc macht nur für iOS wirklich Sinn. Mit etwa 30-50% mehr Leistung als ein Cortex A57, ist er wohl nicht viel schneller als A72
und doch deutlich in der Unterzahl. Denn im Gegensatz zu iOS machen viele Kerne unter Android sehr viel Sinn. Weil viel mehr gleichzeitig
läuft und man die Arbeit gut verteilen kann.

 

[smalM]

Die Chips sind durch die Fertigung limitiert. Die entwickelt sich längst nicht mehr so schnell, wie es nötig wäre. Der SD810 in einem ziemlich schlechten 20nm Prozess war so bestimmt niemals geplant. Entweder hätte man schon direkt 16nm im Blickfeld oder hat auf einen 20nm Prozess mit besseren Eigenschaften gehofft.

Ach ja, der pöse pöse 20SOC-Prozeß...

Seltsam nur, daß Apples A8 und A8X beide überhaupt kein thermisches Problem haben.
Auch Qualcomms LTE-Modems aus der 20SOC-Fertigung sind nie auffällig geworden.

Qualcomm hat die A57 bei der holter-die-polter Entwicklung des 810 schlicht nicht richtig in den Griff bekommen.

 

[Mextli]

Würden die Handy Hersteller auch mindestens 2y lang Updates liefern, wäre es total egal wenn der Chip Hersteller nichts rausrückt (wie bei Mediathek & Kirin leider üblich). Da das aber nicht der Fall ist präferiere ich auch Handys mit Qualcomm.

Seltsam nur, daß Apples A8 und A8X beide überhaupt kein thermisches Problem haben.

Chipgröße, lediglich 2 Kerne und am Sweetspot betrieben, ja kein Wunder das es keine thermischen Probleme gibt...

 

[Darkseth88]

Denn im Gegensatz zu iOS machen viele Kerne unter Android sehr viel Sinn. Weil viel mehr gleichzeitig
läuft und man die Arbeit gut verteilen kann.

Komisch, mein Snapdragon 801 gerät nimmt DEUTLICH (!) an Performance ab, nur weil eine App im hintergrund runtergeladen und geupdatet wird über den Play Store. Ergebnis: Selbst im Menü scrollen ruckelt es deutlich stärker, als wenn nichts geupdatet wird.

@ Apple A8/A8x: Kein wunder... Was soll da schon überhitzen bei 1.3 - 1.4 Ghz?

 

[modena.ch]

Der Updateprozess unter Android ist auf hohen Durchsatz und Performance ausgelegt.
Damit kannst du auch einen 8 oder 10 Kerner gut auslasten und nicht nur 4.

iOS würde, während gescrollt wird, den update Prozess fast anhalten, dass ja nix ruckelt.

Android macht wie ein PC eben alles gleichzeitig und ist damit schnell fertig, egal obs ruckelt oder nicht.
Und seit Android 5 muss wegen Art beim Update die App auch gleich kompiliert werden und nicht
erst wenn sie gestartet wird wie früher. Das brauch eben viel Leistung.


http://anandtech.com/show/9518/the-mobile-cpu-corecount-debate/11

Lösung wir brauchen 12-16 Kerne.

http://anandtech.com/show/9518/the-mobile-cpu-corecount-debate

 

[Marcel55]

Naja okay big.LITTLE von mir aus macht ja nix

Aber das muss dann auch gut umgesetzt sein.
Mein Tablet z.B. hat auch den Exynos 5420 und läuft damit soweit ganz OK.
Aber gehen wir nun zum Browser: Der Samsung-Browser läuft auf den 4 A15 Kernen und hat damit eine gute Performance, z.B. Sunspider 1.0.2 braucht ~500ms.
Nehme ich jetzt einen anderen Browser und führe den Test aus, kommen mindestens 1000ms bei rum, eben weil der Browser auf den falschen Kernen läuft, zum surfen reichen die Energiesparkerne zumindest beim Laden und Scrollen nicht aus.
Auf meinem Smartphone habe ich den Intel Z3560 mit 4 recht starken Kernen, da ist es egal welchen Browser ich nehme. Besonders bei Firefox merkt man es, läuft auf meinem Smartphone sehr gut und auf den Tablet eher ruckelig wobei die Gesamtperformance der beiden SoCs recht ähnlich ist.

Also big.LITTLE gutes Konzept aber funktioniert nicht immer richtig, wenn man selbst entscheiden könnte dass eine Anwendung z.B. nur die Performance-Kerne nutzen soll wäre das nicht schlecht (ähnlich wie bei nVdia Optimus). Und natürlich muss es auch möglich sein dass beide Cluster gleichzeitig verwendet werden können.

Achja einige Fragen sich wozu noch mehr Performance...nunja, es fängt beim Browser an, da geht definitiv mehr. Mittlerweile ist es aber immerhin auf einem akzeptablen Niveau.

 

[Cirrus]

Naja okay big.LITTLE von mir aus macht ja nix

Aber das muss dann auch gut umgesetzt sein.
Mein Tablet z.B. hat auch den Exynos 5420 und läuft damit soweit ganz OK.
Aber gehen wir nun zum Browser: Der Samsung-Browser läuft auf den 4 A15 Kernen und hat damit eine gute Performance, z.B. Sunspider 1.0.2 braucht ~500ms.
Nehme ich jetzt einen anderen Browser und führe den Test aus, kommen mindestens 1000ms bei rum, eben weil der Browser auf den falschen Kernen läuft, zum surfen reichen die Energiesparkerne zumindest beim Laden und Scrollen nicht aus.
Auf meinem Smartphone habe ich den Intel Z3560 mit 4 recht starken Kernen, da ist es egal welchen Browser ich nehme. Besonders bei Firefox merkt man es, läuft auf meinem Smartphone sehr gut und auf den Tablet eher ruckelig wobei die Gesamtperformance der beiden SoCs recht ähnlich ist.

Also big.LITTLE gutes Konzept aber funktioniert nicht immer richtig, wenn man selbst entscheiden könnte dass eine Anwendung z.B. nur die Performance-Kerne nutzen soll wäre das nicht schlecht (ähnlich wie bei nVdia Optimus). Und natürlich muss es auch möglich sein dass beide Cluster gleichzeitig verwendet werden können.

Achja einige Fragen sich wozu noch mehr Performance...nunja, es fängt beim Browser an, da geht definitiv mehr. Mittlerweile ist es aber immerhin auf einem akzeptablen Niveau.

Ich gebe dir auf jeden Fall recht! Konzept allein reicht nicht...
Ich denke, dass das big.LITTLE Konzept recht simple und funktional ist, hier aber gleichzeitig noch viel luft nach oben hat. Wenn hier Qualcomm kein Potential sehen würde, dann würden Sie das Konzept nicht "komplett" über den haufen werfen...

Zunächst einmal ist das Betriebsystem hier gefordet die richtigen Anforderungen an den SoC zu liefern. Ansonstens kann hier nicht das optimale Ergebnis in deinem Browserbeispiel heraus kommen...
Es gibt immer wieder Apps die mit mehreren threads nicht anfangen können! Hier braucht man sehr performante Kerne (wenn auch nicht viele davon nötig sind). Mehr Performance ist also immer gut!
Ich denke um unterschiedlich starke Kerne in einem SoC wird man bei den leistungsfähigsten SoCs nicht mehr herum kommen (Energiesparen). Aber gleichzeitig die Kerne individuell Takten zu können, kann sicherlich nicht schaden den Stromverbrauch dann zu senken, wenn man nur wenig Leistung benötigt.

Beispiel: Eine kleine Aufgabe die im Hintergrund läuft.
Bei 4 A72 Kernen muss ein kompletter A72 Kern mit voller Leistung aktiv sein
Bei 2 A72 + 2 A53 Kernen muss nur ein kompletter A53 Kern mit voller Leistung aktiv sein (schon deutlich besser)
Aber wenn man den A53 noch so weit runter takten könnte, dass er nur das nötig an Energie verbrät, wäre das die optimale Lösung.

Ich könnte mir sogar 3 verschieden starke Kerne in einem SoC vorstellen...

 

[modena.ch]

So wie im Helio X20 2x A72, 4x A53 mit viel Takt und 4x A53 mit wenig Takt,
dürfte kein schlechtes Konzept sein.

Ich hab den Exynos 5420 ebenfalls in 2 Tabs, einmal im Tab Pro mit Android 4.4, da gibts schon hier und da mal
Hängerchen beim Browsen, sonst ist die Performance sehr gut und das mit dem Fremdbrowser kann ich bestätigen.

Und einmal hab ich den 5420 im Tab S mit Android 5.0, da ist die Performance mit demselben Chip in allen Lebenslagen um Klassen besser.
Alles reagiert super schnell. Dürfte wahrscheinlich an dem sehr viel moderneren Kernel liegen, der auch besser mit HMP (alle Kerne gleichzeitig)
umgehen kann.

Da muss man also nur etwas abwarten, die Tab Pro und Note Varianten sollen ja nächstens die 5.1.1 bekommen.

 

[SaschaHa]

Mit deiner Lösung wirst du keinen Spass haben! Denn das Smartphone wird dann nach einem halben Tag leer sein.
Eben deswegen gibt es das big.Little Konzept. Einzige Alternative wäre die Lösung von Qualcomm jeden Kern unabhängig von einander und dynamisch runtertakten zu können. Das ist auch meiner Meinung nach der Hauptvorteil eigener Kerne von Qualcomm, bzw. den Krait-Kernen (deren Energieeffizienz wurde hier bereits angesprochen).
Deine 4 A72 Kerne mit dem Krait-Nachfolger und ich bin dabei

Das dynamische Heruntertakten sollte kein Problem sein. Auch jetzt schalten sich ja die überflüssigen Kerne dynamisch ab (auch innerhalb des Clusters).

Ich denke aber auch, dass das 4+4-Prinzip schon relativ sinnvoll ist, jedoch muss an der Umsetzung und dem Core-Management noch gewaltig gepfeilt werden.

Alternativ würde ich sogar ein A72 Hexacore-Prinzip vorschlagen, wobei die einzelnen Kerne deutlich geringer takten sollten. Und dann ähnlich wie beim Hyperthreading (falls es das ist, was ich meine), genau einen Kern im Extremfall höher takten lassen (für Aufgaben, die nicht für mehrere Kerne optimiert sind).
Wenn man bewerkstelligt, dass im Idle auch nur ein Kern bei niedrigem Takt eingeschaltet ist, sollte das eigntlich noch relativ effizient sein.
Aber ich schätze das meiste geht ohnehin für die GPU drauf, schließlich sind wir bereits bei QHD angelangt.

Ich behaupte mal, dass ein A72 6-Kerner effizienter arbeiten kann als so mancher 4+4er, weil diese derzeit weit unter ihrem Potential arbeiten und oftmals höher takten, als sie es müssten, bzw. zu viele Kerne eingeschaltet sind.

 

[SaschaHa]

Komisch, mein Snapdragon 801 gerät nimmt DEUTLICH (!) an Performance ab, nur weil eine App im hintergrund runtergeladen und geupdatet wird über den Play Store. Ergebnis: Selbst im Menü scrollen ruckelt es deutlich stärker, als wenn nichts geupdatet wird.

@ Apple A8/A8x: Kein wunder... Was soll da schon überhitzen bei 1.3 - 1.4 Ghz?

Bei Installertionen werden vor allem der Speicher und der Ram sehr stark beansprucht, wodurch die Ruckler entstehen. Bedenke, dass es sich um Archive handelt, die entpackt werden.

Chipgröße, lediglich 2 Kerne und am Sweetspot betrieben, ja kein Wunder das es keine thermischen Probleme gibt...

Damit geht Apple auch genau den richtigen Weg. Extrem starke Kerne, die bei niedrigem Takt betrieben werden. So sollte es sein.

 

[Darkseth88]

Aber sollte das nicht 1-2, oder 3 Kerne erledigen?
Während die letzten 1-2 kerne immer noch flüssig zwischen den Homescreens scrollen können? Für letzteres sollten doch nicht 4 kerne gleichzeitig benötigt werden?!
Oder seh ich das falsch..

 

[modena.ch]

Wie schon geschrieben, der Updateprozess kann locker 8-10 Kerne auslasten.
Vor allem die Kompilierung für ART braucht ne Menge Leistung und Rambandbreite.

Da ist einfach nichts mehr übrig für die Scrollelrei.

 

[SaschaHa]

Aber sollte das nicht 1-2, oder 3 Kerne erledigen?
Während die letzten 1-2 kerne immer noch flüssig zwischen den Homescreens scrollen können? Für letzteres sollten doch nicht 4 kerne gleichzeitig benötigt werden?!
Oder seh ich das falsch..

Siehe den Kommentar meines Vorredners.
Zudem wird das Ruckeln weniger durch die Auslastung der CPU herbeigeführt, als vor allem durch die Auslastung des Rams, da dieser dabei ununterbrochen gelesen und beschrieben wird. Dadurch wird dessen volle Bandbreite genutzt und somit entstehen die Ruckler.