A
Antdoit
Neues Mitglied
- 1
Da es jetzt schon die ersten Smartphones mit 8 Kernen gibt, frag ich mich:
Was macht ihr als Software Developer damit?
Was macht ihr als Software Developer damit?
Was macht man mit 8 Kernen?
- 5 Antworten
- Letztes Antwortdatum
markus.tullius
Dauer-User
- 342
Das gleiche, wie mit vier Kernen. 
https://developer.android.com/training/multiple-threads/index.html
Noch eine Erklärung dazu aus der Wiki:
http://de.wikipedia.org/wiki/Multithreading
https://developer.android.com/training/multiple-threads/index.html
Noch eine Erklärung dazu aus der Wiki:
http://de.wikipedia.org/wiki/Multithreading
Zuletzt bearbeitet:
M
monsti
Gast
Marketing 
Wie bei allen "mit vielen CPUs" ausgestatteten Systemen ist iwan der RAM Zugriff das Problem. Die x Kerne teilen sich alle ein und den selben Adress-/Datenbus. Die Kerne könnten "rechnen", jedoch teilen sie sich die Geschwindigkeit zum RAM Speicher.
Im Studium hab ich mal gelernt (die Zahlen passen bestimmt nicht mehr) das ist ca:
1 (CPU) : 20000 (RAM) : 1.000.000 (Hintergrundspeicher).
-> Bis also ein Kern "rechnen" kann, vergeht extrem viel Zeit bis Eingabe + Ergebnis geladen sind. Damit sind die Kerne fast alle abgeschaltet. Egal ob ein Kern oder 8 Kerne....
Von der Grundarchitektur sind 99% meiner Anwendungen immer gleich:
- "Zeichne" eine Maske
- Warte auf eine Eingabe (hier "schläft" die CPU im Idealfall oder ist untertaktet).
Davon kannst ab und zu etwas mit einem AsyncTask starten, z. B. wenn man etwas sucht oder etwas aus dem Netz läd. Dummerweise bringt das für den User i.A. auch
keinen Geschwindigkeitsvorteil. Nur die Sanduhr dreht sich hübsch und zappelt nicht.
Bei einem Programm hab ich die Synchronisation über Netzwerk komplett über einen SyncProvider geschrieben. Da bringt der AsyncTask (und damit quasi die extra CPU) bei Lichte betrachtet auch nicht viel. Wenn tatsächlich Daten angekommen sind, muss iwan hier auch mit locks() gearbeitet werden. Da kann man drüber streiten ob ob man sich hier ein paar 100 ms spart.
Bei Spielen oder bei gut programmierten WebBrowser (z.B. paralleles Laden + Entpacken von Bildern) kann das schon viel bringen!
Dummerweise hat man aber eher so den Maske zeichnen + auf Eingabe warten Teil in den Apps.
Wie bei allen "mit vielen CPUs" ausgestatteten Systemen ist iwan der RAM Zugriff das Problem. Die x Kerne teilen sich alle ein und den selben Adress-/Datenbus. Die Kerne könnten "rechnen", jedoch teilen sie sich die Geschwindigkeit zum RAM Speicher.
Im Studium hab ich mal gelernt (die Zahlen passen bestimmt nicht mehr) das ist ca:
1 (CPU) : 20000 (RAM) : 1.000.000 (Hintergrundspeicher).
-> Bis also ein Kern "rechnen" kann, vergeht extrem viel Zeit bis Eingabe + Ergebnis geladen sind. Damit sind die Kerne fast alle abgeschaltet. Egal ob ein Kern oder 8 Kerne....
Von der Grundarchitektur sind 99% meiner Anwendungen immer gleich:
- "Zeichne" eine Maske
- Warte auf eine Eingabe (hier "schläft" die CPU im Idealfall oder ist untertaktet).
Davon kannst ab und zu etwas mit einem AsyncTask starten, z. B. wenn man etwas sucht oder etwas aus dem Netz läd. Dummerweise bringt das für den User i.A. auch
keinen Geschwindigkeitsvorteil. Nur die Sanduhr dreht sich hübsch und zappelt nicht.
Bei einem Programm hab ich die Synchronisation über Netzwerk komplett über einen SyncProvider geschrieben. Da bringt der AsyncTask (und damit quasi die extra CPU) bei Lichte betrachtet auch nicht viel. Wenn tatsächlich Daten angekommen sind, muss iwan hier auch mit locks() gearbeitet werden. Da kann man drüber streiten ob ob man sich hier ein paar 100 ms spart.
Bei Spielen oder bei gut programmierten WebBrowser (z.B. paralleles Laden + Entpacken von Bildern) kann das schon viel bringen!
Dummerweise hat man aber eher so den Maske zeichnen + auf Eingabe warten Teil in den Apps.
kosmus
Erfahrenes Mitglied
- 62
Ja innerhalb einer app sind die threads oft überschaubar. Aber neben dem multithreading gibt es noch das Multitasking und da hilft es natürlich auch wenn die Prozesse auf mehrere kerne, verteilt werden.
M
monsti
Gast
Ja selbst da machts nicht so mächtig Sinn.
80% der Apps die man installiert hat, machen eh "nix". Sie existieren nur im RAM.
Das kann man gut mit den Systemtools beobachten.
Die vielen Kerne der ARM CPUs sehe ich fast so "überflüssig" wie Hyperthreading
beim x86/x64. Es ist geil für's Marketing und in einigen Fällen bringts etwas.
Für mich als Coder ist mehr die Optimierung vom Akkuverbrauch wichtig und
natürlich die "richtig" Verwendung der Internetverbindung (die ist ggf. langsam,
die ist ggf. instabil). Das sind die Dinge die den User wahnsinnig machen, wenn
das zickt.
Bei Spielen (oder eine sehr überschaubare Kategorie Apps) bringen Threads sehr viel.
In der theoretischen Informatik lernt man das ja:
z.B. bei
(I.): O(n) = n^2
(II.): 4 x O (n/4) =(n/4) ^2 // z. B. also Partitionieren und das 4x gleichzeitig machen
=> II. (zzgl. einer Mergeoperation) kann - für große n - viel kleiner sein wie I.
Wer aber auf so ein Problem läuft, der hat es eh nicht verstanden ... oder hat eine Spezialanwendung (z. B. Bildverarbeitung)
80% der Apps die man installiert hat, machen eh "nix". Sie existieren nur im RAM.
Das kann man gut mit den Systemtools beobachten.
Die vielen Kerne der ARM CPUs sehe ich fast so "überflüssig" wie Hyperthreading
beim x86/x64. Es ist geil für's Marketing und in einigen Fällen bringts etwas.
Für mich als Coder ist mehr die Optimierung vom Akkuverbrauch wichtig und
natürlich die "richtig" Verwendung der Internetverbindung (die ist ggf. langsam,
die ist ggf. instabil). Das sind die Dinge die den User wahnsinnig machen, wenn
das zickt.
Bei Spielen (oder eine sehr überschaubare Kategorie Apps) bringen Threads sehr viel.
In der theoretischen Informatik lernt man das ja:
z.B. bei
(I.): O(n) = n^2
(II.): 4 x O (n/4) =(n/4) ^2 // z. B. also Partitionieren und das 4x gleichzeitig machen
=> II. (zzgl. einer Mergeoperation) kann - für große n - viel kleiner sein wie I.
Wer aber auf so ein Problem läuft, der hat es eh nicht verstanden ... oder hat eine Spezialanwendung (z. B. Bildverarbeitung)
markus.tullius
Dauer-User
- 342
Man kann schon etwas an Geschwindigkeit raus holen. Aber das ist meist mit einen größeren Programmieraufwand verwunden, und nicht ganz trivial (wobei man dann wie @monsti schön viele Landau-Symbole benutzten kann, um das asymptotische Verhalten von Folgen zu betrachten (Komplextheorie)).
In Endeffekt ist es für die meisten Entwickler egal, wie viel Kerne ein Device hat. Denn meistens muss die App auch auf ein Gerät laufen, dass nur ein Kern hat, und 4 Jahre alt ist.
Das Zusammenspiel der einzelnen Kerne in einem Smartphone ist ein Thema für sich. In den aktuellen Topdevices sind meist nicht 8 gleiche Kerne sondern verschiedene Kerne mit unterschiedlichen Stromverbrauch und verschiedenen Geschwindigkeiten verbaut. Die Geschwindigkeit, wie schnell eine Arm-CPU arbeitet, hängt nicht nur von den Anzahl der Kerne ab, sondern auch wie die Maschinenbefehle von der CPU abgearbeitet wird.
So gelten die CPU von Apple für das iPhone als sehr schnell, obwohl die CPUs max. 4 Kerne haben und nur mit mit max 1.4 GHz getaktet sind.
In Endeffekt ist es für die meisten Entwickler egal, wie viel Kerne ein Device hat. Denn meistens muss die App auch auf ein Gerät laufen, dass nur ein Kern hat, und 4 Jahre alt ist.
Das Zusammenspiel der einzelnen Kerne in einem Smartphone ist ein Thema für sich. In den aktuellen Topdevices sind meist nicht 8 gleiche Kerne sondern verschiedene Kerne mit unterschiedlichen Stromverbrauch und verschiedenen Geschwindigkeiten verbaut. Die Geschwindigkeit, wie schnell eine Arm-CPU arbeitet, hängt nicht nur von den Anzahl der Kerne ab, sondern auch wie die Maschinenbefehle von der CPU abgearbeitet wird.
So gelten die CPU von Apple für das iPhone als sehr schnell, obwohl die CPUs max. 4 Kerne haben und nur mit mit max 1.4 GHz getaktet sind.