Llano - Desktop und Mobil, technische Aspekte

[Pirx]

in second half

 

[Markus Everson]

Und seit wann ist Zacate == Llano?

 

[deadohiosky]

Seitdem ich beschlossen habe im falschen Thread zu posten, also genau um 2:12 westeuropäischer Zeit am 06.10.2011.

 

[Opteron]

am 06.12.2011.

Ja ist denn heut schon Nikolaus

Gönn Dir mal ne Mütze Schlaf

 

[deadohiosky]

Ey, du ... bist voll... fies... und so.... und gemein... .



Aber weißte was, ich erzähl dir mal was: Der Nikolaus... der ist schon seit ca. 700 Jahren tot.

 

[Markus Everson]

Beweis durch Behauptung?


<scnr>

 

[deadohiosky]

Natürlich nicht, wo kommen wir denn da hin:

http://www-weihnachten.de/weihnachtsgeschichten/nikolausgeschichte.htm

Bischof Nikolaus starb am 6. Dezember 352.

Er könnte aber auch 326, 345, 351 gestorben sein. (http://de.wikipedia.org/wiki/Nikolaus_von_Myra)

 

[Pirx]

... oder irrlichtert seit der Zeit in der Weltgeschichte rum (wie es auch ein gewisser BD seit geraumer Zeit zu tun pflegt(e?))

 

[nazgul99]

Für mein Board, das Asus F1A75-M PRO, ist ein neues BIOS herausgekommen und dazu eine CPU-Support-Liste:

AMD A4-3300 (AD3300OJZ22GX, rev.B0, 2.5GHz, DC, L2:1M, HD6410D, 65W)
AMD A4-3400 (AD3400OJZ22GX, rev.B0, 2.7GHz, DC, L2:1M, HD6410D, 65W)
AMD A6-3500 (AD3500OJZ33GX, rev.B0, 2.1GHz, TC, L2:3M, HD6530D, 65W)
AMD A6-3600 (AD3600OJZ43GX, rev.B0, 2.1GHz, QC, L2:4M, HD6530D, 65W)
AMD A6-3650 (AD3650WNZ43GX, rev.B0, 2.6GHz, QC, L2:4M, HD6530D, 100W)
AMD A8-3800 (AD3800OJZ43GX, rev.B0, 2.4GHz, QC, L2:4M, HD6550D, 65W)
AMD A8-3850 (AD3850WNZ43GX, rev.B0, 2.9GHz, QC, L2:4M, HD6550D, 100W)
AMD A8-3870 (AD3870WNZ43GX, rev.B0, 3.0GHz, QC, L2:4M, HD6550D, 100W)
AMD Athlon IIX2 221 (AD221XOJZ22GX, rev.B0, 2.8GHz, DC, L2:1M, 65W)
AMD Athlon IIX4 631 (AD631XWNZ43GX, rev.B0, 2.6GHz, QC, L2:4M, 100W)
AMD Athlon IIX4 641 (AD641XWNZ43GX, rev.B0, 2.8GHz, QC, L2:4M, 100W)
AMD E2-3200 (ED3200OJZ22GX, rev.B0, 2.4GHz, DC, L2:1M, HD6370D, 65W)
AMD Sempron X2 198 (SD198XOJZ22GX, rev.B0, 2.5GHz, DC, L2:1M, 65W)

Hier tauchen wieder die GPU-losen Modell incl. Dualcore-Sempron auf, ebenso auch der A8-3870. Er ist mit 3,0 GHz angegeben, das Stepping bleibt demnach B0.

Ich bin mir nicht sicher, ob all diese Details woanders schon (halb-offiziell) aufgetaucht sind, drum hab ich sie sicherheitshalber hier mal gepostet.

Ach ja, die Grafik des E2-3200 heißt hier 6370D, nicht 6379D wie hier bei AMD angegeben, damit steigt die Wahrscheinlichkeit, dass die unpassende "9" ein Tippfehler ist.

 

[Inferno]

Im neusten BIOS 1.20 vom A75M von Asrock wird der A8-3870 auch als neue CPU gelistet, dürfte also nicht mehr so lange dauern

 

[Onkel_Dithmeyer]

Wenn ich ihn in die Finger bekomme, mach ich einen Test für euch. Einen Llano mit Turbo haben wir in der Redaktion bis dato leider nicht zu sehen bekommen.

 

[Ge0rgy]

Naja, der "Turbo" ist aber auch keine magische Wudnertüte...
ich finds teilweise faszinierend wie das im Fusion-Tweaker aussieht wenn mein Llanochen die Turbomodi abfeuert...
Windoof reicht anscheinend die Prozess munter von einer CPU zur anderen durch, was dann dazu führt dass ein Kern nach dem anderen mal eben für eine viertelsekunde auf 2300 geht und dann wieder auf 1600 zurück und der nächste ist an der Reihe...
Würde man das farblich kennzeichnen hätte es vermutlich hypnotische Wirkung

 

[Onkel_Dithmeyer]

Der Umstand ist aber nicht neu und wird seit Einführung von C&Q/Speedstep diskutiert. Da hilft es aktuell nur manuell einen Thread einem einzelnen Kern zuzuweisen.

Wenn ich das alles richtig verstanden hab bisher sieht das wie folgt aus:
Singlethread-Anwendung startet und wird auf Kern 1 gelegt. Kern 1 wird voll ausgelastet, die anderen dröppeln bei 5-10% rum mit irgendwelchen Hintergrunddiensten. Jetzt denkt das OS, mensch, die anderen Kerne sind nicht so ausgelastet, jetzt lager ich den Monster-thread auf einen der weniger ausgelasteten Kerne. Jetz ist der aber so stark ausgelastet, ist nicht ein anderer frei?.... Ja, ich denke da schon seit Jahren, das muss doch besser gehen ^^

 

[Lynxeye]

Der Umstand ist aber nicht neu und wird seit Einführung von C&Q/Speedstep diskutiert. Da hilft es aktuell nur manuell einen Thread einem einzelnen Kern zuzuweisen.

Wenn ich das alles richtig verstanden hab bisher sieht das wie folgt aus:
Singlethread-Anwendung startet und wird auf Kern 1 gelegt. Kern 1 wird voll ausgelastet, die anderen dröppeln bei 5-10% rum mit irgendwelchen Hintergrunddiensten. Jetzt denkt das OS, mensch, die anderen Kerne sind nicht so ausgelastet, jetzt lager ich den Monster-thread auf einen der weniger ausgelasteten Kerne. Jetz ist der aber so stark ausgelastet, ist nicht ein anderer frei?.... Ja, ich denke da schon seit Jahren, das muss doch besser gehen ^^

Den Fehler es so zu betrachten machen wir Menschen immer wieder, da unsere Wahrnehmung immer auf Zeitabschnitte ausgelegt ist. Ein Scheduler hat aber keinen Überblick über den Zeitabschnitt, sondern muss aufgrund der Faktenlage zu einem Zeitpunkt entscheiden.

Der Scheduler zieht die Tasks nicht freiwillig um, sondern ist dazu gezwungen. Das Problem entsteht folgendermaßen: nimm an, der Scheduler muss monoton nach 10ms die Tasks schedulen, heißt er bekommt nach 10ms einen Timer-Interupt und muss entscheiden welche Tasks laufen dürfen. Nun hast du 4 Kerne aber angenommen 5 Threads, welche laufen wollen, dein 100% Load Thread läuft und 3 andere Hintergrundthreads auch.
Zum Zeitpunkt der Entscheidung wollen alle noch laufen, also nimmt der Scheduler einen laufenden Thread raus und gibt einem anderen das Recht auf einem Kern zu laufen. Da alle Threads die gleiche Prio haben erwischt es halt per Zufall gerade deinen 100% Thread. Zum nächsten Entscheidungszeitpunkt meldet einer der laufenden Hintergrundtasks, dass er nicht mehr laufen will, es wird also ein Kern frei. Da alle anderen Threads weiter laufen wollen, migriert der Scheduler natürlich nicht alle laufenden Threads auf einen anderen Kern, sondern lässt sie weiterlaufen. Dein 100% Thread bekommt einfach den freien Kern, wenn es der Kern ist, auf dem er vorher war hast du Glück, ansonsten hat mal wieder die Statistik zugeschlagen.

Was lernen wir daraus: wenn du wirklich einen Thread bzw. Prozess hast, der möglichst viel Rechenzeit bekommen und wenig Migriert werden soll, musst du die Prio hochsetzten, um die Chancen zu verringern, dass dein Prozess überhaupt beim Scheduling als Kandidat für das unterbrechen in Frage kommt. Keine Unterbrechung -> kein Kernwechsel.

 

[Ge0rgy]

man könnte auch einfach alle Programm-Threads höher Priorisieren als die Hintergrundprozesse...
Oder dem Scheduler sagen er soll die Systemdienste "von oben nach unten" auf die Kerne verteilen, also zuerst kern 4, dann 3, dann 2 und mit userprogrammen umgekehrt...

 

[nazgul99]

Der Linux-Sheduler bekommt das auch besser hin, also bitte. Nach meiner Beobachtung bleiben absolute Vollast-Threads wie CPUBurn auf einem Kern kleben, auch wenn nicht alle Kerne ausgelastet sind. Spiele-Threads mit relativ hoher Last (100% Dauerlast können die kaum erreichen, da sie regelmäßig auf andere Prozesse, I/O etc warten müssen) springen zwar auch von Kern zu Kern, das dauert aber viele Sekunden. Im Sinne von eher in Richtung einer Minute als einer Sekunde. Genau nachgemessen hab ich das nicht. Beobachtet hab ich dieses Verhalten, als ich meine Llano-Benches mit der PhoronixTestSuite ausgeführt habe.

 

[Ge0rgy]

Zu Kernel 2.4 Zeiten war es in desktop-Distris Mode den X-Server mit Nice-Level -10 laufen zu lassen,
also wesentlich höherer Prio als den Rest...
Dass das mit 2.6 nicht mehr nötig ist sagt einiges über die Fortschritte in dem Bereich...

 

[Lynxeye]

Der Linux-Sheduler bekommt das auch besser hin, also bitte.

Der Linux-Scheduler bekommt es auch nur bei Load <= Kernanzahl sinnvoll hin, danach läuft man einfach in eine technische Grenze.

 

[Onkel_Dithmeyer]

Der Scheduler kann also nicht erkennen, wie viel Resourcen ein Prozess benötigt? Sonst könnte er ja schätzen, wieviele er in einen Kern packt, so dass 1-2 Kerne schlafen können. Oder am Beispiel des Monsterthreads, dass in dem Kern kein weiterer Thread ausgeführt wird.

 

[nazgul99]

Der Linux-Scheduler bekommt es auch nur bei Load <= Kernanzahl sinnvoll hin, danach läuft man einfach in eine technische Grenze.

Dann greift ja auch nur noch der All-Core-Turbo, nicht mehr die höchste Stufe bei Load-Threads <= Kerne/2. Zudem möchte ich ein Spiel mit mehr als 8 Last-Threads sehen. Bei HPC- und Render- oder Transcoding-Software kann man ja meist die Thread-Zahl einstellen oder sie wird automatisch auf (maximal) die Zahl der Kerne/Hardware-Threads gesetzt.

Edit: gut, wir sind hier bei Llano, da sind's natürlich "nur" 4 Threads.
.
EDIT :
.
Onkel_Dithmeyer: Load=1 bedeutet, dass ein Kern (so er als Einziger die Arbeit tut) voll ausgelastet ist. Bei z.B. 4 Kernen und Load=5 gibt's halt Probleme.

 

[Lynxeye]

Du machst wieder den Fehler deine Beobachtung der Vergangenheit, auf die Logik des Schedulers zu übertragen. Der muss allerdings die zukünftige Belegung der Kerne zuteilen. Und woher soll der Scheduler wissen, ob der Thread, über den er gerade entscheiden muss, nun noch 20ms zum Abschluss seiner Berechnungen braucht, oder ob er noch 5 Std auf Volllast laufen wird.

Der Scheduler bekommt nur die Information vom Thread: "hey ich habe Arbeit, bitte gib mir die CPU". Der Scheduler weiß nicht, ob das ein Hintergrundthread ist. Er kann also nur entscheiden: habe ich Ressourcen um den Thread laufen zu lassen, oder muss ich ihn nach hinten stellen. Der Scheduler kann es sich nicht leisten einen Thread zu verzögern, nur weil dieser in der Vergangenheit keine großen CPU Anforderungen hatte, das kann sich in der Zukunft ändern. Oder würde es dir gefallen, wenn dein Virenscannerprozess die Datei, welche du gerade brauchst, extrem langsam bearbeitet, weil er vorher im Hintergrund auf Arbeit gewartet hat und deshalb vom Scheduler nur wenig Zeit zugeteilt bekommt?

Die einzige sinnvolle Möglichkeit hier ist die Prioritäten der Prozesse im System richtig zu setzen. Leider tun die meisten hier das intuitiv richtige und pinnen den Prozess auf einen Kern, statt das objektiv sinnvolle Anpassen der Prioritäten vorzunehmen.
.
EDIT :
.

Dann greift ja auch nur noch der All-Core-Turbo, nicht mehr die höchste Stufe bei Load-Threads <= Kerne/2. Zudem möchte ich ein Spiel mit mehr als 8 Last-Threads sehen. Bei HPC- und Render- oder Transcoding-Software kann man ja meist die Thread-Zahl einstellen oder sie wird automatisch auf (maximal) die Zahl der Kerne/Hardware-Threads gesetzt.

Edit: gut, wir sind hier bei Llano, da sind's natürlich "nur" 4 Threads.
.
EDIT :
.
Onkel_Dithmeyer: Load=1 bedeutet, dass ein Kern (so er als Einziger die Arbeit tut) voll ausgelastet ist. Bei z.B. 4 Kernen und Load=5 gibt's halt Probleme.

Bitte nicht wieder mit geglätteten Durchschnittswerten arbeiten. Der Scheduler muss zu einem Zeitpunkt entscheiden, weshalb er nur einen Datensatz hat, keinen Durchschnitt.

So kann es sehr wohl vorkommen, dass auf einem System mit Durchschnittsload < 1 zu einem Zeitpunkt mehr Threads laufen wollen, als Kerne vorhanden sind. Und in diesem Fall kann es zum Kernhopping kommen. Das habe ich ja vorhin versucht zu erklären, auch bei nur einem Lastthread und 4 Kernen kann der Scheduler gezwungen sein den Prozess zu migrieren. Der Linux CFQ Scheduler hat sehr viel Logik um ungünstige Migrationen zu verhindern (schätzungsweise 80% des Schedulercodes), trotzdem lässt es sich nicht ganz umgehen.

 

[Ge0rgy]

Und was spräche dagegen die Prozesse zu "klassifizieren" ? - dass der Scheduler eben weiß wer hintergrundprozess/systemdienst ist und wer nicht...?

 

[Lynxeye]

Und was spräche dagegen die Prozesse zu "klassifizieren" ? - dass der Scheduler eben weiß wer hintergrundprozess/systemdienst ist und wer nicht...?

Und was machst du indem du eine Priorität zuweist? Genau, eine Klassifikation vornehmen. Nutze die Macht, die dir gegeben ist.

 

[Dr@]

Und was machst du indem du eine Priorität zuweist? Genau, eine Klassifikation vornehmen. Nutze die Macht, die dir gegeben ist.

Die Frage ist doch aber, warum das BS dies nicht selber hin bekommt.

Warum kann der Scheduler nicht abschätzen, dass ein Prozess, der die letzten 10 Sekunden schon einen Kern voll ausgelastet hat, dies höchst wahrscheinlich auch die nächsten 10 Sekunden tun wird. Warum teilt er unwichtige kleine Prozesse nicht ausschließlich den gering ausgelasteten Kernen zu. Für mich arbeitet der Windows Scheduler noch mit der Logik aus der Single-Core-Zeit. Wenn ich beim Bulldozer künftig 8 "Integer-Kerne" im Angebot habe, macht die alte Logik für mich keinen Sinn. Ich habe immer viele Prozesse, die gleichzeitig laufen. Warum muss das aber dazu führen, das der fordernste und zeitkritischste ständig einem anderen Kern zugewiesen wird? Das sollte doch eigentlich ein lösbares Problem sein.

 

[Lynxeye]

Weil der Scheduler keine Information über die Vergangenheit hat. Weder kann er im Kernel die benötigten Durchschnittswerte errechnen (kein Float Code im Kernel), noch kann soviel Speicher für einen Kernelteil verbraten werden (alleine dadurch würde der Scheduler, der alle 10ms läuft den Applikationen die Daten aus dem Cache kegeln). Außerdem muss der Scheduler innerhalb weniger µs eine Entscheidung treffen, der kann nicht erst 1ms rumrechnen bis er weiß welcher Thread auf welchem Kern laufen darf, damit wären 10% der verfügbaren Rechenzeit schon totgelegt.

Deshalb muss man dem Scheduler halt Tipps geben. Wie gut (Linux) oder schlecht (Windows) der Scheduler mit diesen Tipps umgeht, darüber kann man sich streiten, aber nicht über die Grundlagen der Schedulerlogik.