Mehrkern-Skalierung und Browser-Performance (ausgelagert aus Tegra-Spekulationen) [Archiv]

Undertaker

2014-02-25, 16:08:28

Ausgelagert von hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10124518#post10124518

Der sollte schon eine höhere IPC als A9r4 haben.

Der Punkt ist recht schwierig zu beurteilen, meines Wissens gibt es bislang noch keinen(?) anderen A9r4-SoC auf dem Markt. Im Geekbench 3 ist Krait 200/300 zumindest nur wenige Prozent schneller als diverse A9-SoCs. Z.B.

S600 1,7 GHz Krait 300: ~600 Punkte (Single)
Exynos 4412 1,6 GHz A9r3: ~500 Punkte (Single)
Exynos 5250 1,7 GHz A15r2: ~870 Punkte (Single) <--- zum Vergleich

Ich würde gerne auch andere Benchmarks heranziehen, nur mit der Vergleichbarkeit ist das immer so eine Sache... Ich denke aber nicht, dass sich A9r4 und Krait pro Takt wirklich viel nehmen.

robbitop

2014-02-25, 16:10:22

Ich kann mich nur dunkel daran erinnern, als Anand den ersten Kraits gegen die Cortex A9 SoCs durchbenchte. Das war Anfang 2012. IIRC wurde A9 dort in vielen (nicht allen) Benchmarks klar geschlagen. Gute 30-40 % waren es fast überall.

Undertaker

2014-02-25, 16:16:10

Es gibt bei den A9-SoCs auch Ausreißer nach unten, z.B. Tegra 3 ist teils messbar langsamer (Speicherinterface?). Und wenn bei Anand auch Browsertests dabei waren ist die Frage, ob er den gleichen Browser oder einen u.U. unterschiedlich schnellen Stock-Browser benutzt hat.

Edit: Identischer Browser:

http://www.notebookcheck.com/SoC-Shootout-x86-vs-ARM.97573.0.html

Allerdings als A9-Vertreter nur der zuvor erwähnte Tegra 3 (der pro Takt an anderer Stelle oftmals langsamer als der Exynos 4412 erscheint).

fondness

2014-02-25, 16:23:07

Krait ist schon erheblich schneller als ein A9:
http://www.anandtech.com/show/5559/qualcomm-snapdragon-s4-krait-performance-preview-msm8960-adreno-225-benchmarks/2

AFAIK liegt ein Krait-Kern nur minimal unter einem A15 pro Takt.

Undertaker

2014-02-25, 16:33:12

Linpack ist absolut synthetisch und beim Browser zählt wie erwähnt die Software (Sunspider ahoi) – und da hat Anand scheinbar Stock genutzt, also keine Vergleichbarkeit.

Meine IPC-Einschätzung:

A9r3 (mit schnellem Unterbau, Exynos 4412 o.ä.) ~ +10-20% über A7
Krait300 ~ 10% über A9r3
A15r2 ~ 30% über Krait300

Krait300/400 nehmen sich afair in der Praxis wenig.

fondness

2014-02-25, 16:35:18

Und die Einschätzung kommt jetzt aus dem Himmel oder gibt es auch eine Quelle? :)
Und AnandTech liefert auch eine Vergleich mit dem selben Browser wo Krait ebenfalls deutlich gewinnt.

Undertaker

2014-02-25, 16:36:46

http://www.notebookcheck.com/SoC-Shootout-x86-vs-ARM.97573.0.html
http://browser.primatelabs.com/android-benchmarks

Spiegelt meine Angaben ziemlich genau wieder. Wie gesagt, ich würde gerne auch noch mehr Benchmarks auswerten, aber bitte auf die Vergleichbarkeit achten.

Und AnandTech liefert auch eine Vergleich mit dem selben Browser wo Krait ebenfalls deutlich gewinnt.

Wo?

Edit: Das hier?

Browser Cache Cleare Cache In Use
Qualcomm MDP MSM8960 (Krait) 5.5 seconds 3.0 seconds
Samsung Galaxy Nexus (ARM Cortex A9) 5.8 seconds 4.4 seconds

Der Cache-Wert könnte von der Speichergeschwindigkeit beeinflusst sein. Ohne Cache haben wir nur wenige Prozent Differenz, wenn das natürlich "Network Bound" ist lässt sich wieder nichts herauslesen (die Anandtech-Startseite hat übrigens ~1,5 MB – da müsste er schon mit <3 Mbit/s verbunden sein, damit hier ein Limit entsteht).

fondness

2014-02-25, 17:14:59

Ich traue AnandTech schon zu das richtig zu benchen. :)

Undertaker

2014-02-25, 17:22:21

Es hat ja nicht unbedingt etwas mit "falsch" benchen zu tun, die Frage ist nur was genau gemessen wurde. Bei der Masse seiner Browser-Tests hat er den Stock-Browser genutzt, was das Ganze eher zu einem Geräte-/Software- denn SoC-Benchmark macht. Und bei dem einen Test, der nur aus dem Laden einer Webseite in drei Durchgängen besteht, sind die Limitierungen ebenso unklar – bzw. hier soll man dann plötzlich darauf vertrauen, dass der SoC die Leistung bestimmt (Cache-Werte ohne Speichereinfluss? Internetanbindung <3 Mbit?), was bei der gesamten Benchmarkreihe davor nicht der Fall war? Da sind mir die Notebookcheck-Werte mit einheitlichem Browser und einer viel breiteren Auswahl doch sehr viel vertrauenserweckender, zudem decken sie sich im Mittel doch ganz gut mit dem Geekbench. Ja, der ist auch nicht der Weisheit letzter Schluss, aber die Datendecke ist nuneinmal recht dünn. Den 3DMark Physik Score könnte man noch heranziehen, der tendiert übrigens auch eher zu meiner Schätzung.

Ailuros

2014-02-25, 17:37:17

Ich traue AnandTech schon zu das richtig zu benchen. :)

Browser benchmarks sind schon in ihrer Mehrzahl zwielichtig; ueberhaupt vieles von dem Java Zeug. Das daemliche ist dass wenn Du heute ein smartphone mit einem quad A7 gegen ein smartphone mit quad A9 bei gleicher CPU Frequenz, gleicher Aufloesung und gleicher Speichermenge nebeneinander in einem blinden Test setzt in Echtzeit nicht sooo leicht den "Gewinner" finden wirst. Aendert sich auch nicht besonders viel bei Krait vs. A9 so lange die Frequenzen vergleichbar sind.

Was mal jemand machen koennte ist eine Applikation fuer Android im Hintergrund laufen zu lassen die den Einsatz der jeweiligen cores und dessen Frequenz angiebt; man browsed ganz einfach mit dem Ding mit lehrer browser cache durch die gleichen Seiten und vergleicht dann.

robbitops Behauptung dass mehr als zwei cores selten benutzt werden ist auch im relativen Bloedsinn Bereich. Da ich nur einen quad A7 auf dem smartphone habe und keinen A15, laden bei page changes oder beim hochladen des browsers oefters 3 bzw. alle 4 cores hoch; haette ich ein big.LITTLE CPU config wuerde nur sehr kurz ein einziger A15 oder im schlimmsten Fall 2 hochladen und es waer gut.

Da Batterien nicht unendlich wachsen und dessen Unterschiede in Groessen pro smartphone Generation nicht wirklich um Welten groesser sind passen die Hersteller sich mehr oder weniger in dem Bereich an. Man muss halt eben mit einem smartphone 8-10 Stunden uebers wifi surfen koennen.

-/\-CruNcher-/\-

2014-02-25, 17:42:08

Kein Hersteller ist so blöd und taktet so stark mit Absicht runter. Es mindert den eigentlichen Vorteil vom T4i.
Der octacore A7 im MTK6592 der sich schon wie warme Semmeln in China verkauft Takte auch auf 1.7GHz und über die Preise reden wir lieber nicht. 1.2GHz ist news von vorgestern.

Da geb ich Ailuros recht die Chinesen z.b takten meistens gefährlich weit hoch um dann später das mit Updates wieder zu revidieren, ist ein witziges spielchen (gefährlich ist es nichtmal wirklich weil die maximum taktraten verspricht ja der Soc manufacture aber dieses versprechen ist nicht Device bezogen tschasching) ;)

Im Prinzip kannst du dir nie sicher sein ob die Daten die mal für so ein vor allem 7 zoll versprochen wurden auch gehalten werden, das wird so in der Masse eher getestet von vielen China OEMs funktioniert es auf dauer nicht und leute beschweren sich gibts Patch und stat 1.6 Ghz hast dann nur noch ein 1.5 Ghz gerät, aber stabil ;)

In den China Review Benchmarks wird natürlich immer mit den 1.6 Ghz maximum dann getestet ist ja klar

Undertaker

2014-02-25, 17:43:24

Da ich nur einen quad A7 auf dem smartphone habe und keinen A15, laden bei page changes oder beim hochladen des browsers oefters 3 bzw. alle 4 cores hoch;

Wie ist denn die summierte Auslastung aller 4 Kerne? Bei mir sehe ich auch Last auf allen 4 Kernen, was aber einzig daher resultieren dürfte, dass der entsprechende Thread ständig von einem Kern zum nächsten geschoben wird und die Anzeige damit etwas gemittelt wird. Meines Wissens gibt es derzeit überhaupt keinen Browser, der das Laden eines Tabs auf mehrere Kerne parallelisieren kann. Wenn ich alle 4 Balken addiere, komme ich weder bei Chrome, Opera oder Android Stock auf mehr als ~1,5 vollausgelastete Kerne. Insofern würde ich robbitop da schon Recht geben wollen.

Ailuros

2014-02-25, 18:10:47

Wie ist denn die summierte Auslastung aller 4 Kerne? Bei mir sehe ich auch Last auf allen 4 Kernen, was aber einzig daher resultieren dürfte, dass der entsprechende Thread ständig von einem Kern zum nächsten geschoben wird und die Anzeige damit etwas gemittelt wird. Meines Wissens gibt es derzeit überhaupt keinen Browser, der das Laden eines Tabs auf mehrere Kerne parallelisieren kann. Wenn ich alle 4 Balken addiere, komme ich weder bei Chrome, Opera oder Android Stock auf mehr als ~1,5 vollausgelastete Kerne. Insofern würde ich robbitop da schon Recht geben wollen.

Man kann bei PVRmonitor und den ein- und ausschaltenden Balken fuer die CPUs nur einschaetzen.

Browser-start (Durchschnittsfall mit Chrome):

[**************............]
[***********.................]
[********......................]

Einfache page changes sind ungefaehr 2/3 vom obrigen ergo in etwa meistens:

[***********.................]
[*******........................]

Die "1.5 core Vereinfachung" wuerde dann schon passen theoretisch, aber bei welcher Frequenz jeweils dann, und steckt wirklich eine so einfache Formel dahinter dass man auch bei exakt gleichen Frequenzen den gleichen Stromverbrauch erreicht? Ergo 1 core 400MHz + 1 core 300MHz = gleicher Stromverbrauch als 1 core = 700MHz?

Undertaker

2014-02-25, 18:17:47

Mir ging es jetzt nur um die Parallelisierung bzw. die Frage, ob mehr als zwei Kerne beim Browsing wirklich Vorteile bringen – und wie robbitop schon sagte, denke auch ich: Eher nein.

Ailuros

2014-02-25, 18:46:03

Mir ging es jetzt nur um die Parallelisierung bzw. die Frage, ob mehr als zwei Kerne beim Browsing wirklich Vorteile bringen – und wie robbitop schon sagte, denke auch ich: Eher nein.

Kern != Kern. Wie gesagt hab ich zwei Kerne mit sehr hoher IPC und/oder mehr als einem parallelen thread in Echtzeit ist es ein total anderes Kapitel. Ohne Frequenzen und den dadurch resultierenden Stromverbrauch ist mir eine jegliche solche Vereinfachung nutzlos.

http://www.anandtech.com/show/7804/the-anandtech-mobile-show-mwc-2014-edition

Wer Zeit zu verschwenden hat, es kommt nach den ersten 10 Minuten auf multi-core und ich haette die little.LITTLE Idee patentieren sollen :P (j/k)

Undertaker

2014-02-25, 19:03:57

Kern != Kern. Wie gesagt hab ich zwei Kerne mit sehr hoher IPC und/oder mehr als einem parallelen thread in Echtzeit ist es ein total anderes Kapitel.

Es ist vollkommen irrelevant was für Kerne mit welcher IPC ich habe, wenn die zu bewältigende Software nur einen Thread mit nennenswerter Auslastung besitzt – und genau das scheint beim Laden eines Tabs browserunabhängig der Fall zu sein.

Ailuros

2014-02-25, 19:15:49

Es ist vollkommen irrelevant was für Kerne mit welcher IPC ich habe, wenn die zu bewältigende Software nur einen Thread mit nennenswerter Auslastung besitzt – und genau das scheint beim Laden eines Tabs browserunabhängig der Fall zu sein.

Da es sich hier um Lastverteilung handelt, ist es unter der Logik dann auch scheissegal wieviel Kerne man hat oder einschaltet so lange man Aufgabe X in Y Millisekunden mit N mW Stromverbrauch bewaeltigt.

Undertaker

2014-02-25, 19:25:46

Mir ist nicht klar worauf du hinauswillst. Wir reden hier von einer Aufgabe (= Browsing), die sich nach aktuellem Softwarestand praktisch nicht parallelisieren lässt. Egal ob du also 2 A15-Kerne, 8 A7-Kerne oder sonst etwas hast, mehr als einem ausgelasteten Kern und ein bisschen Overhead/Hintergrundtasks auf einem zweiten wirst du nicht gleichzeitig haben. Ergo wird auch die Energiebilanz bei stupider Steigerung der Kernzahl nicht besser.

Ailuros

2014-02-25, 19:33:30

Dann schalten all die Applikationen (wie auch "all cpu meter" als sehr einfaches desktop gadget) einfach nur bunte Balken ein damit es "interessanter" fuer den Beobachter aussieht. Ich hab's schnell auf einem core-i3 ausprobiert und um Mozilla 27.0.1 hochzuladen sind es 3 threads: 32%, 21%, 17%.

Undertaker

2014-02-25, 19:40:05

Ich hab es doch schonmal erklärt: Der Thread wird schlicht viel zu schnell von Kern zu Kern geschoben, als dass du das per Software erkennen (bzw. selbige das in Echtzeit darstellen) könntest. Wirklich parallelisiert ist pro Tab (fast) nix.

Ailuros

2014-02-25, 19:45:05

Wieso sollte man einen thread von Kern zu Kern verschieben? Ich hab einen einzigen angeblichen thread und ein einziger core ist gut genug diesen auszufuehren; wieso sollte der thread durch alle cores durchfegen um zu sehen auf welchem er sich besser fuehlt oder was?

Undertaker

2014-02-25, 20:04:06

Gleichmäßige Temperaturverteilung auf dem Chip z.B. Ich meine, bei Windows kam das ab Vista(?) auf, da kann mich aber auch irren. Nimm einfach hin, dass es so ist, bzw. teste es selbst nach.

Ailuros

2014-02-25, 20:08:41

Gleichmäßige Temperaturverteilung auf dem Chip z.B. Ich meine, bei Windows kam das ab Vista(?) auf, da kann mich aber auch irren. Nimm einfach hin, dass es so ist, bzw. teste es selbst nach.

Was es auch ist, es sieht auf solchen einfachen Applikationen so aus als ob es fast gleich verhaelt auf windows7 (ultimate) vs. Android 4.2.1 im gegebenen Fall. Selbst wenn es sich um so etwas handelt: es erscheint auf jeden Fall nicht gleichmaessig ueber alle threads bzw. cores und wenn es sich ueberhaupt ueber Temperaturverteilung handelt dann heisst es dass der thread ueber mehrere threads/cores verstreut wird oder nicht?

Undertaker

2014-02-25, 20:19:18

Was noch die Gründe sind (wenn es denn noch andere gibt) weiß ich nicht, dazu müsste sich jemand anderes äußern. Und nein, der Thread wird nicht auf mehrere Kerne verteilt, zumindest nicht zu einem diskreten Zeitpunkt, sondern nur seriell von mehreren Kernen bearbeitet. Das kannst du mit üblichen Tools nicht sinnvoll in Echtzeit visualisieren.

Um den Bogen zum Ausgangspunkt zu bekommen: Ab >2 Threads hast du beim Seitenaufbau keine Leistungsgewinne (immer auf Basis aktueller Software). Und sicher nicht ohne Grund geht nach Apple auch Nvidia künftig auf wenige, stärkere Kerne.

robbitop

2014-02-26, 10:00:24

robbitops Behauptung dass mehr als zwei cores selten benutzt werden ist auch im relativen Bloedsinn Bereich. Da ich nur einen quad A7 auf dem smartphone habe und keinen A15, laden bei page changes oder beim hochladen des browsers oefters 3 bzw. alle 4 cores hoch; haette ich ein big.LITTLE CPU config wuerde nur sehr kurz ein einziger A15 oder im schlimmsten Fall 2 hochladen und es waer gut.

Sind alle 3 oder 4 Cores bei der Aktualisierung der Webseite auf 100 % Last (oder verteilt der Scheduler wie bei Windows einfach nur auf die Kerne um (damit keine Hotspots entstehen)).
Ich meine, dass HTML Browser nicht sonderlich parallelisierbar sind. (es sei denn die GUI wird nicht 3D beschleunigt - das lässt sich natürlich gut auf mehreren Cores verteilen).

Ein Indiz dazu ist, dass Quadcore SoCs bei keinem Test den ich gelesen habe, Webseiten schneller laden als Dual Core SoCs. (gleicher Takt und gleicher Kern)

Wenn 4 Kerne bei den Core-Applikationen viel bringen würde, hätte Apple längst einen Quadcore in seine SoCs verbaut IMO.

Ailuros

2014-02-26, 10:52:14

Sind alle 3 oder 4 Cores bei der Aktualisierung der Webseite auf 100 % Last (oder verteilt der Scheduler wie bei Windows einfach nur auf die Kerne um (damit keine Hotspots entstehen)).

Womoeglich das zweite aber man kann sich auch nicht sicher sein.

Ich meine, dass HTML Browser nicht sonderlich parallelisierbar sind. (es sei denn die GUI wird nicht 3D beschleunigt - das lässt sich natürlich gut auf mehreren Cores verteilen).

Ja aber wenn der scheduler auf diverse threads/cores verteilt dann hat es wohl auch einen Stromverbrauch-relativen Zweck sonst waere der Aufwand dafuer erstmal idiotisch.

Ein Indiz dazu ist, dass Quadcore SoCs bei keinem Test den ich gelesen habe, Webseiten schneller laden als Dual Core SoCs. (gleicher Takt und gleicher Kern).

Gegen gleicher Takt und Kern nichts einzuwenden, da wir aber eine Unmenge von diversen configs haben muss man sich schon differenzieren. Wie ich schon sagte ein quad A7 ladete ein klein bisschen schneller eine schwere Seite als das originale iPad mini trotz 1080p vs. 1024*768 und trotz zich noch anderen Faktoren.

Wenn 4 Kerne bei den Core-Applikationen viel bringen würde, hätte Apple längst einen Quadcore in seine SoCs verbaut IMO.

Siehe oben; da sie aber im iPad mini retina einen dual core Cyclone eingebaut haben ist ein quad core im =/>A7 Bereich total ueberfluessig.

Undertaker

2014-02-26, 11:29:51

Gegen gleicher Takt und Kern nichts einzuwenden, da wir aber eine Unmenge von diversen configs haben muss man sich schon differenzieren. Wie ich schon sagte ein quad A7 ladete ein klein bisschen schneller eine schwere Seite als das originale iPad mini trotz 1080p vs. 1024*768 und trotz zich noch anderen Faktoren.

Solche Quervergleiche zwischen verschiedenen OS' und Browsern sagen nicht wirklich viel aus, zumal wir hier komplett unterschiedliche SoCs (Speicheranbindung, Architektur) haben. Ja, Gerät A ist schneller als Gerät B – das hat aber deswegen noch lange nix mit der Kernzahl zu tun.

Worauf die Konfig aber keinerlei Einfluss hat ist die Frage, ob der jeweilige Browser das Laden einer Seite auf mehrere Kerne parallelisieren kann oder nicht. Chrome, Opera, Firefox etc. können das schon einmal nicht. Am PC z.B. reicht ein Kern + SMT, darüber gibt es keine Leistungssteigerungen beim Seitenaufbau mehr (wohingegen Takt auch bei >3 GHz noch sauber skaliert, es ist also schlicht fehlende Parallelisierung).

Ja aber wenn der scheduler auf diverse threads/cores verteilt dann hat es wohl auch einen Stromverbrauch-relativen Zweck sonst waere der Aufwand dafuer erstmal idiotisch.

Wie gesagt: Temperaturverteilung. Der Verbrauch wird durch das Umverteilen sicher nicht sinken.

Ailuros

2014-02-26, 12:30:59

Solche Quervergleiche zwischen verschiedenen OS' und Browsern sagen nicht wirklich viel aus, zumal wir hier komplett unterschiedliche SoCs (Speicheranbindung, Architektur) haben. Ja, Gerät A ist schneller als Gerät B – das hat aber deswegen noch lange nix mit der Kernzahl zu tun.

Worauf die Konfig aber keinerlei Einfluss hat ist die Frage, ob der jeweilige Browser das Laden einer Seite auf mehrere Kerne parallelisieren kann oder nicht. Chrome, Opera, Firefox etc. können das schon einmal nicht. Am PC z.B. reicht ein Kern + SMT, darüber gibt es keine Leistungssteigerungen beim Seitenaufbau mehr (wohingegen Takt auch bei >3 GHz noch sauber skaliert, es ist also schlicht fehlende Parallelisierung).

Um ehrlich zu sein hab ich das Resultat egal wie fraglich nicht erwartet weil der uebliche "hoerensagen-Stereotyp" eher fuer iOS steht und schon gar nicht fuer einen chinesischen Plastik-bomber.

Wie gesagt: Temperaturverteilung. Der Verbrauch wird durch das Umverteilen sicher nicht sinken.

...und hier ist der eigentliche Haken wo ich mit dem gleichen Fragezeichen fuer das verdammt breite OT hier *hust*: verbraucht man mehr oder weniger oder gleich viel Strom wenn man anstatt 700MHz single core auf 300 + 400MHz zwei cores verteilt (ist nur ein einfaches Beispiel). Temperatur bzw. Abwaerme ist zu guter letzt eben nicht irrelevant zum Verbrauch selbst indirekt.

Ich lass mich ja auch gerne eines besseren belehren aber das obrige duerfte auch mitunter der Grund sein warum eine GPU (natuerlich wo immer GPGPU auch wirklich Sinn macht) bei N hoeherem Parallelismus und um einiges niedrigeren Frequenzen nicht nur schneller ist sondern auch weniger Strom verbraucht. Und hier sollte ich anmerken dass die obrige Verteilung ueber die cores natuerlich nicht in allen Faellen vorkommt; es gibt durchaus Anwendungsfaelle wo mal ein einziger core auf schaetzungsweise 80% hochgejagt wird und es wird dann der Fall sein wo es einfach nicht anders geht.

Und da wir den thread hier zu stark vergewaltigt haben: es ist auch nicht so dass die GPUs heutzutage beim browsen dumm herumhocken. Beim laden und scrollen haut es ziemlich stark auf die Fuellrate und es wird jedesmal ein begrenzter Anteil von fragment processing eingesetzt.

Als letzte Kleinigkeit stocken heute die Mehrzahl der Geraete an zu wenig Speicher. Egal was fuer CPUs und dessen Anzahl bzw. config der groesste Flaschenhals ist 1GB Speicher wenn man wirklich auf so einem Geraet so fahrlaessig browsen will wie auf einem desktop. Begrenzt man sich auf maximal 2 tabs im schlimmsten Fall ist es auch schwer zu bemerken. IMHO brauchen heutige SoCs entweder sehr grosszuegige interne caches und/oder mehr als 1GB Speicher.

Undertaker

2014-02-26, 12:39:55

...und hier ist der eigentliche Haken wo ich mit dem gleichen Fragezeichen fuer das verdammt breite OT hier *hust*: verbraucht man mehr oder weniger oder gleich viel Strom wenn man anstatt 700MHz single core auf 300 + 400MHz zwei cores verteilt (ist nur ein einfaches Beispiel).

Ich glaube, du hast es noch nicht so ganz verstanden. ;) Um etwas auf zwei Kerne aufteilen zu können, müsste die Aufgabe erstmal parallelisierbar sein, was beim Seitenaufbau anscheinend nicht wirklich der Fall ist. Dein Beispiel ist darum falsch gewählt – es ist nicht so, dass der Dualcore dann zwei Kerne mit 300 + 400 MHz füttert, sondern abwechselnd beide Kerne die mit je 700 MHz takten. Darum auch energetisch keine Verbesserung gegenüber dem Singlecore.

Du hast aber Recht, wir sind um Meilen OT und sollten das vielleicht auslagern.

Ailuros

2014-02-26, 13:12:56

Ich muss jetzt leider schnell weg; lager es mal bitte aus entweder im Techno oder mobilen Forum wo immer es Dir am meisten Sinn macht. Danke im voraus :)

iFanatiker

2014-02-26, 14:46:29

Muss ich jetzt hier echt den Unterschied zwischen einen Prozess und einen Thread erklären? Wieso sollte ein Web Browser nicht mehrere "schwache" Kerne nicht auslasten können?

Gerade der mobile Chrome geht auf Geräten mit wenig Resourcen durchaus auf ein Singe Process -> Multi Thread Paradigma zurück und auch in dem Core API Prozess wie auch in jeden Render Prozess werden durchaus mehrere Threads angestoßen. Zum Beispiel lädt auch der Core Prozess durchaus mehrere Resoucen Anfragen Parallel runter. Dazu gibt es noch Optimierungen wie die das prädiktive Vorladen von Seiten, DNS Anfragen usw. Gerade bei Chrome in Kombi mit "schwachen" SoC läuft deutlich flüssiger mit mehreren Kernen. Dazu kommt noch die generelle Architektur von Android wie auch spezielle Anforderungen an ein mobiles System bzgl. der Verfügbarkeit diverser Dienste. Entsprechend gilt zur Zeit ein Quad Core System als "Honeyspot" für ein "schnelles" Android System.

Undertaker

2014-02-26, 14:59:02

Ailuros

2014-02-27, 06:51:42

Natürlich gibt es auch beim Webbrowser noch einen Batzen weiterer Threads, die zusammen vielleicht nochmal einen "halben" Kern extra auslasten, sodass sich insgesamt eine Auslastung von irgendwo zwischen einem und zwei Kernen beobachten lässt. Das eigentliche Problem ist aber, dass die eigentliche Hauptlast der Berechnungen nur in einem Thread stattfindet. Es gibt genügend Benchmarks z.B. zwischen Cortex-A7 Dual- und Quad-Cores, die eben keine Leistungsgewinne beim Browsing zeigen.

Wobei browser benchmarks auch nicht das absolut zuverlässigste sind, überhaupt wenn in Benchmarks links und rechts hoher getaktet wird.
Es wäre interessant mal Browser Benchmarks von einem octacore zu sehen. Ich frag mal Anand ob er zeitgleich mit QCOMs octacore Zeug ein paar octacores vergleichen wird. Ich erwarte zwar keinen sehenswerten Unterschied in Echtzeit aber mal sehen....

Avalox

2014-02-27, 08:52:19

Habe hier gerade mal auf dem kleinen Gerät nachgesehen. Chrome nutzt hier 4 Rastertthreads und auch der JS Compiler nutzt mehrere Threads. Wobei letzteres ja eher neu ist.

Undertaker

2014-02-27, 09:19:29

Avalox

2014-02-27, 09:51:49

Ailuros

2014-02-27, 10:09:54

Wie gesagt, mehrere Threads werden zweifellos genutzt. Problem ist eben, dass ein Thread davon dominiert und dadurch die Leistung limitiert. Einfach mal die summierte Auslastung aller Kerne bei einem Quad anschauen, die bestätigt was die Benchmarks schon sagen: Mehr als zwei Kerne beschleunigen den Seitenaufbau praktisch nicht mehr, egal ob A7, Krait oder sonstwas.

Dann wuerde aber wohl schwer browsing auf neueren Geraeten schneller werden. Denn eine um N% hoehere maximale CPU Frequenz auf einem relativ neueren SoC (wenn sich sonst nichts an der CPU selber aendert) bedeutet auch nicht zwingend dass in Echtzeit sich die CPU Frequenz auch um N% erhoeht. Dafuer sind die Abstaende in Batterie-groessen zwischen budget und high end smartphones zu klein.

Von der einen Seite ist es mir vollkommen klar dass CPU Leistung in Echtzeit (nicht in benchmarks) NICHT linear skaliert mit mehr cores. Das heisst aber dann wiederum nicht dass quad gegen dual cores (bei vergleichbaren IPC Grenzen zwischen den beiden) gar nichts bringt. So wie ich es sehe von den Bums-applikationen die die thread-Verteilung illustrieren wollen ist es extrem SELTEN dass ein einziger core auf >50% gejagt wird und der Normalfall ist dass wenn mehr als 1 core benutzt wird die Balken stufenartig relativ nahe zu den anderen liegen.

Avalox

2014-02-27, 10:31:42

Das sollte ja recht einfach zu testen sein, da Chrome ja das Abschalten des Multithtreading Rendern erlaubt, bzw. man sogar eine Anzahl maximaler Threads vorgeben kann.
Zum testen des neuen concurrent compilation fähigen JS Compiler bietet sich ja der neue schicke Profiler.
http://v8.googlecode.com/svn/branches/bleeding_edge/tools/profviz/profviz.html

Undertaker

2014-02-27, 11:21:19

Dann wuerde aber wohl schwer browsing auf neueren Geraeten schneller werden. Denn eine um N% hoehere maximale CPU Frequenz auf einem relativ neueren SoC (wenn sich sonst nichts an der CPU selber aendert) bedeutet auch nicht zwingend dass in Echtzeit sich die CPU Frequenz auch um N% erhoeht. Dafuer sind die Abstaende in Batterie-groessen zwischen budget und high end smartphones zu klein.

Nun, wir haben in den letzten Jahren nicht nur bei ARM-SoCs einige Takt- und IPC-Steigerungen erlebt, sondern auch gewaltige Optimierungen bei den Browsern. Das mittlerweile wohl rund 3 Jahre alte Galaxy S2(!) eines Kollegen rennt in Sunspider rund drei mal so schnell wie in den Reviews 2011 (~1200 zu 3400 ms) – der reale Vorteil beim Browsen ist ebenfalls gigantisch. Das sollte man nicht vergessen wenn man schaut, wie gut man mit einem Cortex A7 heute surfen kann.

Von der einen Seite ist es mir vollkommen klar dass CPU Leistung in Echtzeit (nicht in benchmarks) NICHT linear skaliert mit mehr cores. Das heisst aber dann wiederum nicht dass quad gegen dual cores (bei vergleichbaren IPC Grenzen zwischen den beiden) gar nichts bringt. So wie ich es sehe von den Bums-applikationen die die thread-Verteilung illustrieren wollen ist es extrem SELTEN dass ein einziger core auf >50% gejagt wird und der Normalfall ist dass wenn mehr als 1 core benutzt wird die Balken stufenartig relativ nahe zu den anderen liegen.

Genau das ist wieder das Problem der von Kern zu Kern verschobenen Threads und das Tools schlicht gemittelte Werte wiedergeben.

Ich will auch gar nicht sagen, das Dual->Quad gar keine zusätzlichen Leistungsgewinne beim Surfen bringt, aber die Zugewinne sind doch eher klein und auf wenige Situationen begrenzt. Das ist auf dem Desktop genau das gleiche Problem.

Ailuros

2014-02-27, 19:13:29

Nun, wir haben in den letzten Jahren nicht nur bei ARM-SoCs einige Takt- und IPC-Steigerungen erlebt, sondern auch gewaltige Optimierungen bei den Browsern. Das mittlerweile wohl rund 3 Jahre alte Galaxy S2(!) eines Kollegen rennt in Sunspider rund drei mal so schnell wie in den Reviews 2011 (~1200 zu 3400 ms) – der reale Vorteil beim Browsen ist ebenfalls gigantisch. Das sollte man nicht vergessen wenn man schaut, wie gut man mit einem Cortex A7 heute surfen kann.

Es sollte wohl klar sein dass der vorige Paragraph den gerade gequotet hast nicht ein smartphone vor einem Jahrzehnt mit einem heutigen vergleicht. Der Punkt in diesem war dass wenn ich Geraet A mit 4*A7@1.2GHz habe, gegen Geraet B mit 4*A7@1.7GHz und der Unterschied in Batteriegroesse ist sagen wir mal bei nur 15%, dann besteht die Wahrscheinlichkeit wenn der Hersteller vergleichbare Laufzeiten haben will dass es eben nur bei ca. 15% liegen wird. Und natuerlich ist es auch auf andere Vergleiche anwendbar aber nur innerhalb von gewissen Grenzen.

Ich will auch gar nicht sagen, das Dual->Quad gar keine zusätzlichen Leistungsgewinne beim Surfen bringt, aber die Zugewinne sind doch eher klein und auf wenige Situationen begrenzt. Das ist auf dem Desktop genau das gleiche Problem.

Wenn es hilft zusaetzlich Strom zu sparen reicht es mir persoenlich schon mal aus. Es ist ja NICHT so dass A7 Kerne spezifisch pro core irgendwelche nennenswerte die area einnehmen. A15 waeren natuerlich um einiges problematischer bisher, aber sie haetten den Trend der gerade erscheint 2*A15 mit 4*A7 in big.LITTLE anzubinden schon seit langem anwenden sollen. Bei der die area, dem Stromverbrauch und der Leistung die ein A15 liefert ist dort ein quad von diesen tatsaechlich zweiffellos Ueberfluss. Braucht man wirklich mehr Dampf schaltet man einfach bei 2+4 alle 6 cores ein und gut ist es.

Undertaker

2014-02-27, 19:22:56

Wenn es hilft zusaetzlich Strom zu sparen reicht es mir persoenlich schon mal aus. Es ist ja NICHT so dass A7 Kerne spezifisch pro core irgendwelche nennenswerte die area einnehmen. A15 waeren natuerlich um einiges problematischer bisher, aber sie haetten den Trend der gerade erscheint 2*A15 mit 4*A7 in big.LITTLE anzubinden schon seit langem anwenden sollen. Bei der die area, dem Stromverbrauch und der Leistung die ein A15 liefert ist dort ein quad von diesen tatsaechlich zweiffellos Ueberfluss. Braucht man wirklich mehr Dampf schaltet man einfach bei 2+4 alle 6 cores ein und gut ist es.

Bleiben wir mal bei einem A7-only SoC: Energieeinsparungen und Leistungssteigerungen durch zusätzliche Kerne werden immer gemeinsam einhergehen. Nur wenn sich mein Problem parallelisieren lässt, erziele ich durch weitere Kerne eine Mehrleistung; alternativ kann ich auch nur unter dieser Bedingung die Taktraten senken und damit bei gleichbleibender Performance Energie einsparen.

Ansonsten stimme ich dir zu, 2x A15 + *x A7 ist eine schicke Sache. Ob es nun zwei, vier oder sonst wie viele A7-Kerne sein sollen ist mir dagegen praktisch egal; die Dinger mögen kaum Fläche kosten, gleichzeitig auslasten kann ich sie aber auch fast nie. Auf jeden Fall eine weitaus schickere Lösung als stupide 8 A7-Kerne einzupflanzen, selbst wenn man zwei unterschiedlich optimierte Cluster nutzt. Gegen einen >1,5 GHz A15 stinkt jeder noch so schnelle A7 ab, und das merkt man nunmal auch beim Surfen.