fdsonne schrieb:
Ne, das funktioniert nicht, weil sich der Bedarf je nach Szenario teils x-fach die Sekunde ändert. (...)
Was soll da eine Prio noch groß was bringen?
Der typische Computernutzer hat nicht viele Programme gleichzeitig am Laufen. Der hat sein Vordergrundprogramm (Spiel, Word, Browser, etc.), ein paar Programme im Hintergrund (Discord, Spotify, etc.) und der Rest ist Betriebssystem und Dienste. Da ist gar nicht so viel Varianz drin.
Ein Tag-System, wie ich es angesprochen habe, kann dem Scheduler genau sagen, worauf es Priorität legen soll. Das Vordergrundprogramm bekommt die P-Cores, die Hintergrundprogramme die P- und E-Cores und das OS und die Dienste die E- und SMT-Cores. Oder so in der Art.
fdsonne schrieb:
Das ist reinste Theorie. In der Praxis ist es eher so, dass man anstatt mit einer fixen Anzahl an Threads mit einer Art Pool arbeitet. Das heißt, es gibt nicht "weniger anspruchsvolle Threads". Sondern es gibt einfach nur Aufgaben, die in einen Pool gekippt werden und wo am Ende dann die Gesamtlaufzeit entscheidet.
Und genau das ist die mangelhafte Umsetzung, von der ich spreche. Wenn an den Aufgaben keine Information dran hängt, welche Art Leistung unter welchen Umständen benötigt wird, dann kann der Scheduler auch nicht effektiv arbeiten.
Sound z. B. verlangt wenig Leistung und wenig I/O, aber erfordert Real Time-Verarbeitung. Grafik verlangt teils viel CPU-Leistung, viel I/O und Real Time Verarbeitung (für konsistente Frame-Zeiten). Der Windows-Wechseldatenträgerdienst hingegen braucht das alles nicht. Der wird nur geweckt, wenn es Änderungen bei der angeschlossenen USB-Hardware gibt.
fdsonne schrieb:
Der Programmierer könnte es, wenn er es denn wöllte und wenn die Aufgabe entsprechend so gestaltet ist, dass es überwachbar ist.
Beim Gaming ist das bspw. ein Ding der Unmöglichkeit, denn neben Dingen die das Game macht (Programmierer A) kommen noch Dinge dazu, die bspw. der Treiber fabriziert (Programmierer B) - die wissen nix voneinander. A kippt Aufgaben in eine Schnittstelle, die B bereit gestellt hat und am Ende muss der Threadscheduler vom OS wissen, ob jetzt der/die Threads von A oder von B die laufzeitkritisicheren sind. Denn wenn es eng wird, entscheidet sich hier stark wie viel Performance man liegen lässt.
Wenn die Aufgabe dem Scheduler mitteilt, wie kritisch sie ist, weiß er was er wie zu sortieren hat. Einfach nur nach dem Prinzip "Sieh zu, wie du damit klar kommst!" zu arbeiten, ist ineffizient.
Und der Programmierer weiß, wo die meiste Rechenzeit in seinem Code benötigt wird. Dafür gibt es Profiler-Software.
fdsonne schrieb:
Das ist nicht vergleichbar, da dir der 1:1 Vergleich wie auf dem PC fehlt. Was man auf den PC macht ist wahlweise SMT an oder aus zu knipsen, Wahlweise E-Cores an oder aus zu knipsen oder sogar mit großen CPUs die Core-Skalierung zu ermitteln.
Das gibts auf dem Smartphone in aller Regel nicht. Ein Gerät, eine Konfig. Du wirst nicht rausbekommen, ob der Ansatz keine Ahnung 1+2+4 besser ist als der Ansatz 2+0+4 oder 2+2+8 oder sonstwas. Weil gibt es nicht zu kaufen...
Intel hat CPUs mit P- und E-Core und
SMT HT auf
beiden Core-Arten auf dem P-Core. Im Prinzip hat man damit
vier drei verschiedene Core-Arten. Was ich damit sagen will: Android schafft es, mit zwei, drei Core-Arten mit unterschiedlicher Leistungsfähigkeit gleichzeitig umzugehen. Und wenn das OS das schafft, dann kann man etwas ähnliches auch auf x86-Betriebssystemen umsetzen.
HT hat man damals damit beworben, dass man bis zu 80% Mehrleistung erreichen kann. Dieses Potential einfach wegzuwerfen, weil der Scheduler kann das nicht effizient verwalten kann, heißt für mich, dass der Scheduler das Problem ist.
