News Samsung zeigt Big.Little-SoCs im Februar

Patrick

Rear Admiral
Registriert
Jan. 2009
Beiträge
5.267
Mehr als ein Jahr nach der Vorstellung des Konzepts wird im kommenden Jahr mit Samsung einer der bekanntesten SoC-Hersteller Produkte auf Basis der Big.Little-Technik vorstellen. Dies geht aus dem Programm (PDF) der International Solid-State Circuits Conference (ISSCC) hervor, die im Februar in San Francisco stattfindet.

Zur News: Samsung zeigt Big.Little-SoCs im Februar
 
Endlich kann ich die Facebookgruppe "Mein Smartphone hat mehr Kerne als mein PC" aufmachen.
Spaß bei Seite, ich finde die Entwicklung gut. Mehr Akkulaufzeit und trotzdem mehr Leistung, sofern nötig, sind doch eine gute Sache.
 
@Burner87

Da sieht man das die PCs der entwicklung hinterherhinken. Noch immer wird praktisch nichts auf Multicore Systeme programmiert die mehr als 4 Kerne haben. Beim Handy werden 4 Kerne mittlerweile ziemlich gut unterstützt und dass obwohl 4 Kerner erst seit einem Jahr erhältlich sind. Schaut man sich mal PC Software an, stellt man fest dass auch nach 5 Jahren in denen es 4 Kerner gibt die Software häufig immernoch nicht suaber darauf programmiert wurde.
 
Bald werden Samsungs High-End-Smartphones wohl nicht nur leistungstechnisch zur Elite gehören, sondern zugleich auch eine enorm gute Akku-Performance liefern. Ich bin sehr gespannt! :)
 
Laut ARM sollen sich die Akkulaufzeit um bis zu 70 Prozent im Vergleich zu einem konventionellen Aufbau verlängern.
Das halte ich ja für ein Gerücht. Den meisten Strom verbraucht bei einem Smartphone/Tablett ja das Display. Man könnte die 70% also nichtmal erreichen, wenn die CPU gar keinen Strom verbrauchen würde.

Trotzdem finde ich die Entwicklung richtig gut. Damit wird mobile Hardware immer leistungsstärker und kann immer mehr Aufgaben übernehmen, wofür man früher ein stationäres System brauchte. (NAS, kleines Office Netbook, Multimedia Konsole, ...)
 
@Burner87

Ich sehe das eher als Anzeichen dafür, dass auch ARM nur mit Wasser kocht und sie es mehr oder weniger aufgegeben haben, ihre CPUs weiterhin auf den niedrigst möglichen Verbrauch zu trimmen.
Nachdem man sich jetzt mit dem Atom messen muss, weil der ENDLICH mal in Regionen abgestiegen ist, wo er als SoC taugen kann, geht man eben bei ARM mit A15 und Nachfolgern mehr auf die Leistung. Und weil das den Verbrauch negativ beeinflusst, müssen jetzt noch zusätzliche sparsame Kerne auf den SoC wandern, um das im Idle wieder auszugleichen.

Das wäre ja eigentlich auch kein Problem und ist sogar relativ genial, hat aber halt ein paar recht heftige Nachteile:
Man verbläst für die sparsamen Kerne noch einmal extra Die-Fläche, die SoCs werden also teurer, was die Fabs freuen, aber die Gerätehersteller ärgern dürfte.
Damit die Geräte beide Kerne ansprechen können ohne dass es zu Problemen kommt, müssen die beiden Kerne dieselben Befehlssätze unterstützen. Soll heißen, wenn mal im ARM Bereich solche Erweiterungen wie AVX bei Intel und AMD Einzug halten, dann muss der sparsame Kern das entweder auch unterstützen, oder das Feature liegt im schnellen Kern brach. Liegt es brach -> negativ für die Leistung. Kann es der langsame Kern auch -> höherer Verbrauch.

Für den Moment ist es ein ganz guter Workaround, aber ob das auf Dauer eine brauchbare Lösung ist, ist fraglich.
 
Polii schrieb:
@Burner87

Da sieht man das die PCs der entwicklung hinterherhinken. Noch immer wird praktisch nichts auf Multicore Systeme programmiert die mehr als 4 Kerne haben. Beim Handy werden 4 Kerne mittlerweile ziemlich gut unterstützt und dass obwohl 4 Kerner erst seit einem Jahr erhältlich sind. Schaut man sich mal PC Software an, stellt man fest dass auch nach 5 Jahren in denen es 4 Kerner gibt die Software häufig immernoch nicht suaber darauf programmiert wurde.

Das liegt nicht unbedingt am Unvermögen oder der Trägheit der Entwickler. Viele Dinge lassen sich halt nicht pauschal und mit wirklichem Vorteil parallelisieren. Für massive, "stupide" Parallelisierung gibt es die GPUs als (bessere) Konkurrenz. Dann muss man auch noch beliebig skalieren ohne dabei wieder die Vorteile der Parallelisierung zu verspielen: heute läuft noch y mit z Kernen nebenbei, da bleibt für x nurnoch 1,2,3,4... Kerne....

Nenn mal konkretes zu "ziemlich gut unterstützt" auf Smartphones?
 
Zuletzt bearbeitet:
Herrlich, schon wieder 70% weniger Verbrauch.
Das lese ich so oft, irgendwie sind die Handys trotzdem viel schneller leer, als die von vor 5 Jahren.
 
Radde schrieb:
Das halte ich ja für ein Gerücht. Den meisten Strom verbraucht bei einem Smartphone/Tablett ja das Display. Man könnte die 70% also nichtmal erreichen, wenn die CPU gar keinen Strom verbrauchen würde.

Trotzdem finde ich die Entwicklung richtig gut. Damit wird mobile Hardware immer leistungsstärker und kann immer mehr Aufgaben übernehmen, wofür man früher ein stationäres System brauchte. (NAS, kleines Office Netbook, Multimedia Konsole, ...)

Die 70% Ersparnis beruht sich auf die CPU-Leistung und nicht auf den gesmaten Energierverbrauch
 
Die 70% Ersparnis beruht sich auf die CPU-Leistung und nicht auf den gesmaten Energierverbrauch

Denk ich zwar auch aber trotzdem liest sich das aus dem Bericht falsch heraus:

Laut ARM sollen sich die Akkulaufzeit um bis zu 70 Prozent im Vergleich zu einem konventionellen Aufbau verlängern.

Akkulaufzeit heißt zumindest für mich die Gesamtlaufzeit des Akkus bevor er leer ist. Im Endeffekt also doch den gesamten Energieverbauch. Außer die hängen nur die CPU an einen Akku ohne den Rest des Smartphones.
 
Polii schrieb:
Beim Handy werden 4 Kerne mittlerweile ziemlich gut unterstützt und dass obwohl 4 Kerner erst seit einem Jahr erhältlich sind.
Am PC ist 1 Kern auch bei weitem schnell genug, um sämtliche alltäglichen Aufgaben zu erledigen. Spiele und alles was mit Grafik oder Video zu tun hat unterstützt da wo es Sinn macht schon längst Multicore.
 
Das Diagramm les ich so, dass der Energieverbrauch in keiner relation zur Leistung zunimmt.
Also Verbrauch steigt stärker als die Leistung, also eher negative Entwicklung.
Positiv wäre es, wenn es eine Gerade oder eine nach unten abknickende Kurve wäre.

Naja die werden schon wissen was sie machen, hoffe ich.

LG

PiEpS schrieb:
Ohne 8 Kerne und 6 Zoll Display kommt mir kein Smartphone mehr ins Haus.
:)

Mein nächstes soll mit Kernenergie betrieben werden.
 
Zuletzt bearbeitet:
Burner87 schrieb:
Mehr Akkulaufzeit und trotzdem mehr Leistung, sofern nötig, sind doch eine gute Sache.
Akku-Zeit hat nie wirklich was mit Leistung zu tun, wennn man die Kerne schon länger abschalten kann.

Es gibt in Smartphone-Bereich nunmal verschiedene Lastfälle (Idle, Telefonieren, mp3, SMS, Fotografieren, ... und Apps). Die Mehrkernversion ist typisch, wenn sowohl in Maximallast (Big-Cores) als ach in Teillast (little-Cores) entsprechende Cores zu verfügung stellt, um höchste Performance-Pro-Watt in allen Lastfallen zu bekommen.

dgschrei schrieb:
@Burner87

Ich sehe das eher als Anzeichen dafür, dass auch ARM nur mit Wasser kocht und sie es mehr oder weniger aufgegeben haben, ihre CPUs weiterhin auf den niedrigst möglichen Verbrauch zu trimmen.
Guter Gedanke.
Aber ob das wirklich so kommt, muss sich eigentlich noch zeigen, da ARM zukünftige Kerne präsentierte, die wesentlich effizienter als auch performanter werden sollen.

Das wäre ja eigentlich auch kein Problem und ist sogar relativ genial, hat aber halt ein paar recht heftige Nachteile:
Man verbläst für die sparsamen Kerne noch einmal extra Die-Fläche, die SoCs werden also teurer, was die Fabs freuen, aber die Gerätehersteller ärgern dürfte.
ARM-Coregrößen sind mit 1-3 mm² schon irrelevant klein geworden. Wesentlich mehr verbraucht da die iGPUs, wo MP2 oder MP4 gleich +10 bis30mm² bedeuten.

Damit die Geräte beide Kerne ansprechen können ohne dass es zu Problemen kommt, müssen die beiden Kerne dieselben Befehlssätze unterstützen. Soll heißen, wenn mal im ARM Bereich solche Erweiterungen wie AVX bei Intel und AMD Einzug halten, dann muss der sparsame Kern das entweder auch unterstützen, oder das Feature liegt im schnellen Kern brach.

Für den Moment ist es ein ganz guter Workaround, aber ob das auf Dauer eine brauchbare Lösung ist, ist fraglich.
Wenn die Hardware-Lösung sinnvoll ist, dann wird sich die Software IMO recht schnell drauf einstellen. Vorallem, wenn Samsung als absoluter Handy und Smartphone (und vielleicht bald Tablet) - Marktführer auf so eine Lösung setzt.
Nachdem Nvidia-Tegra schon in diese Richtung geht und AMD-Kaveri mit dem ARM-Core auch schon unterschiedliche Cores haben wird, könnte so ein Multi-Kulti-Core-Die eine zukünftige Entwicklung sein.
 
alles was den verbrauch senkt ist gut, denn irgendwann ist auch mal schluss mit immer größeren akkus

wenn das zweite diagramm so der realität entspricht, dann ist der cortex a15 ein stück scheiße, exponentieller anstieg beim verbrauch zu kaum mehrleistung, mit augenmass siehts nach 6mal mehr verbrauch aus als der alte cortex a7, wobei nur die leistung verdoppelt wird? sorry aber das ist doch ein schlechter witz oder? da würde ja ein 2000mAh bei voller leistung nicht mal ne stunde halten

ich hoffe echt, dass das diagramm nicht der realität entspricht
 
Naja bis zum 70% Verbrauch heißt für mich im idealsten Fall.
Das würde bedeuten, wenn das Handy ganze Zeit nur im Idle läuft.
Sicherlich wird es in der Realität weniger sein, aber kann durchaus bemerkbar werden, denn die meisten Zeit ist es eben im Idle.
 
Radde schrieb:
Das halte ich ja für ein Gerücht. Den meisten Strom verbraucht bei einem Smartphone/Tablett ja das Display. Man könnte die 70% also nichtmal erreichen, wenn die CPU gar keinen Strom verbrauchen würde.
Da ist schon was dran. Die Werte sind sicherlich marketingwirsam ausgeschlachtet.
Aber der A15 soll ja wirklich deutlich mehr verbraten als bisherige A9 Kerne. Da ist das Verhältnis vielleicht schon wieder etwas anders.

dgschrei schrieb:
Für den Moment ist es ein ganz guter Workaround, aber ob das auf Dauer eine brauchbare Lösung ist, ist fraglich.
Ich frag ich auch ob das der richtige Ansatz ist.
Beim Tegra3 sah es noch plausibel aus. Im IDLE, bzw. sehr geringer Teillast reicht der 5. LP-Kern aus, beim Rest werden die anderen Kerne genutzt.

Hier sieht es ja so aus als ob die A7 Cores fast alles erledigen und die hungrigen A15 nur bei absoluter Spitzenlast einschreiten. Da fragt man sich ob es nicht mehr Sinn macht eher konservativer, wie bisher, zu entwickeln. Sprich mäßig schnellere Kerne die aber weiterhin eine gute Effizienz bieten. (wie Krait?)

Für den Smartphone bin ich da mit den A15 etwas skeptisch. Generell ist es aber schon gut, dass ARM auch leistungsfähigere Cores anbietet. Im Tabletbereich ist der Stromverbauch zwar auch wichtig, aber bei weitem nicht so kritisch. Dort macht das Display noch mehr aus und es steht auch mehr Platz für den Akku zur Verfügung.
 
Schon wieder -70%!
Zum Glück sind 100 mal -70% nicht -7000%.
Sonst hätt ich schon ein schönes Kraftwerk daheim.
(scheiß Prozentrechnung....)
 
aylano schrieb:
Guter Gedanke.
Aber ob das wirklich so kommt, muss sich eigentlich noch zeigen, da ARM zukünftige Kerne präsentierte, die wesentlich effizienter als auch performanter werden sollen.

Es ist nunmal die Realität. Während Qualcomm und Apple auf Basis ihrer ISA Lizenzen CPUs entwickelt haben welche praktisch perfekt in das Format von Smartphones passen ist man bei ARM andere Wege gegangen.

Auf der einen Seite steht mit A7 eine absolute Low-Cost, Low-Power Variante mit einer Performance welche sich geringfügig über A8 einordnet und auf der anderen Seite A15 welcher für Produkte oberhalb von Smartphones notwendig ist. Allerdings sind solche IPC Steigerungen (A15) eben nur mit massiven Investitionen an allen Ecken zu erreichen (gegenüber den bisherigen ARM Low-Power Architekturen muss praktisch alles mit skaliert und auf deutlich mehr Durchsatz optimiert werden). Dementsprechend ist eine lineare Skalierung (im Vergleich zu A7) utopisch. Doppelte Leistung (IPC) für den ~dreifachen Energiebedarf.

Big.Little ist deshalb auch keine bahnbrechende Innovation sondern ein bewusst eingegangener Kompromiss um mit zwei ISA kompatiblen Designs welche sich an sehr unterschiedliche Märkte richten das gewünschte Ziel zu erreichen. Im Entry Bereich wird man in Zukunft primär SoCs finden welche nur A7 einsetzen.


ARM-Coregrößen sind mit 1-3 mm² schon irrelevant klein geworden. Wesentlich mehr verbraucht da die iGPUs, wo MP2 oder MP4 gleich +10 bis30mm² bedeuten.

Bei A7. Von den Größenordnungen darf man sich bei A15 etc. verabschieden.
 
Zuletzt bearbeitet:
aylano schrieb:
Wenn die Hardware-Lösung sinnvoll ist, dann wird sich die Software IMO recht schnell drauf einstellen. Vorallem, wenn Samsung als absoluter Handy und Smartphone (und vielleicht bald Tablet) - Marktführer auf so eine Lösung setzt.
Nachdem Nvidia-Tegra schon in diese Richtung geht und AMD-Kaveri mit dem ARM-Core auch schon unterschiedliche Cores haben wird, könnte so ein Multi-Kulti-Core-Die eine zukünftige Entwicklung sein.

Nur dass das so nicht funktioniert. Das ist keine Softwarefrage sondern eine technische.
Software muss ganz egal was du machst irgendwann auf die Maschinensprache eines Prozessors übersetzt aka kompiliert werden.

Du musst also zur Auslieferung der Software schon wissen welche Befehlssätze der Prozessor unterstützen wird. Software nach dem Motto: Wenn ARM Core-A, dann diese Befehle, wenn ARM Core-B, dann die anderen, gibt es und kann es auch nicht geben.

Genau aus dem Grund würden selbst wenn MS es erlaubt hätte, die ganzen Windows Desktop Programme nicht auf WinRT laufen, ohne dass sie vorher zu ARM kompiliert werden.

Daran ändert auch die Tatsache nichts, dass in Android die Apps in einer VM laufen und sich deshalb nicht um die Prozessorarchitektur kümmern müssen. (was in Android auch nur bedingt stimmt, da man auch ARM-spezifische Befehle für bestimmte Funktionen nutzen kann, um die grottige Performance der Dalvik-VM zu umgehen. Bei Winphone ist es aber z.B. eine echte VM. Die Apps haben absolut keinen Peil auf welcher Hardware sie laufen)

Denn das verschiebt das Problem nur zu Google und der Dalvik-VM, bzw dem Linux-Kernel der das alles zum Laufen bringt. Die müssten zur Laufzeit entscheiden,welche Befehlssätze sie ansprechen, was nicht gehen kann, weil das ein Henne-Ei Problem ist.
Denn:
Mit welchem Befehlssatz soll die Software denn nun entscheiden unter welchem Befehlssatz sie laufen muss :D .
 
Zuletzt bearbeitet:
Zurück
Oben