Warum führt die Priorisierung von Prozessen nicht zu einer Verbesserung der Geschwindigkeit?

Priorität hilft nicht, wenn der Engpass die CPU selbst ist. Die Priorität hat tatsächlich Auswirkungen auf den Zeitplanungsalgorithmus, den das Betriebssystem verwendet, um zu bestimmen, welcher Prozess als nächstes ausgeführt wird, da in den meisten Systemen nicht genügend Prozessoren vorhanden sind, um jeden Prozess kontinuierlich auszuführen.

Eine Task mit höherer Priorität wird schneller an die Spitze der Warteschlange gelangen. Dies hilft bei der allgemeinen Latenzzeit. Wenn Ihr Prozess jedoch die gesamte Zeitspanne erschöpft, die er der tatsächlichen Berechnung zugewiesen hat, ändert die Zeitplanung nichts. Das Ändern der Priorität ist sinnvoller, wenn Sie einen Prozess haben, der auf E / A wartet und Sie möchten, dass er schneller reagiert.

Priorität hat die CPU-Zeit. Werden alle Kerne ständig zu 100% ausgelastet? Wenn nicht, hätte die Priorität keine Wirkung. Häufig ist die CPU nicht der Engpass und ihre Speicher-, Festplatten- oder GPU-Ressourcen.

Priorität ist nur wichtig, wenn mehr ausführbare Threads vorhanden sind als verfügbare CPU-Kerne. Wenn dies geschieht, steuert Priorität, welche Threads ausgeführt werden. In den meisten Systemen gibt es nicht genug Berechnungen für Konflikte auf der CPU: Die Threads sind alle blockiert und warten darauf, dass etwas passiert. Dies kann darauf warten, dass Sie etwas eingeben, die Maus bewegen, den Bildschirm berühren oder Daten von der Festplatte, dem Netzwerk oder einem anderen Gerät, das Sie angeschlossen haben, erhalten oder dass ein anderer Thread die Arbeit an wichtigen Daten beendet Struktur. Es könnte darauf warten, dass ein Teil des Programms von der Festplatte oder einem ausgelagerten Speicher ausgelesen wird, um zurück gelesen zu werden, anstatt explizit eine Datei zu lesen.

In Windows führt der Scheduler auf jeder Prioritätsstufe eine Warteschlange mit ausführbaren Threads. Wenn er eine Planungsentscheidung trifft - entweder, dass ein Thread sein Quantum aufgebraucht hat (zulässige Zeit, bevor etwas anderes ausgeführt werden muss), was bedeutet, dass ein anderer Thread eine Umdrehung erhalten sollte, oder dass der Thread blockiert ist und nicht mehr lauffähig ist oder eine höhere Priorität hat Thread wurde nicht mehr blockiert - der nächste Thread in der Warteschlange auf der obersten Prioritätsebene mit beliebigen ausführbaren Threads wird geplant. Wenn der ausgeführte Thread sein Quantum aufgebraucht hat, wird er an das Ende der Warteschlange gesetzt. Wenn es der einzige Thread ist, der auf seiner Prioritätsstufe lauffähig ist, und es keine anderen ausführbaren Threads mit höherer Priorität gibt, die jedoch nicht ausgeführt werden, erhält der Thread einen weiteren Zug.

In Multicore- / Multiprozessorsystemen kann es Einschränkungen geben, auf welchen Cores ein Thread ausgeführt werden kann. Das System versucht außerdem, Threads auf ihrem idealen Kern und innerhalb ihres NUMA-Knotens zu belassen, so dass die Daten des Threads wahrscheinlich immer noch im Cache dieses Kerns liegen und dass er schnell auf die von ihm erstellten Daten zugreifen kann. Threads werden immer noch auf nicht idealen Kernen ausgeführt, wenn Sie nicht entscheiden können, was als nächstes ausgeführt werden soll.

Das System verwendet verschiedene dynamische Prioritätsschübe und dynamische Quantengrößen, so dass die Vordergrundanwendung (falls erforderlich) mehr Zeit als Hintergrundprozesse erhält und Prozesse nach Abschluss der E / A-Vorgänge (einschließlich Maus, Tastatur und Tastatur) schnell reagieren können Touchscreen-Eingabe). Darüber hinaus wird Prioritätserhöhung verwendet, um Prioritätsinversionen zu umgehen, bei denen ein Thread mit hoher Priorität auf eine Ressource wartet, die ein Thread mit niedriger Priorität derzeit hält. Wenn ein Thread mit mittlerer Priorität ausgeführt wird, verhungert er den Thread mit niedriger Priorität nach Prozessorzeit und hält den Thread mit hoher Priorität hoch. Der Thread mit niedriger Priorität wird also vorübergehend auf die höhere Priorität erhöht, sodass er Zeit erhält und hoffentlich die Ressource freigibt, die der Thread mit hoher Priorität benötigt.

Vor Windows Vista hatte die Thread-Priorität keinen Einfluss darauf, wie schnell E / A-Vorgänge abgeschlossen wurden. Seit Windows Vista können I / Os auch eine Priorität haben, die standardmäßig von der Thread-Priorität stammt.

Zusammenfassung: Wenn Sie die CPU-Last stark belasten, sehen Sie weitgehend keine Änderung der Thread-Prioritäten, und selbst dann ist der Effekt in der Regel minimal. Wenn der Prozess auf E / A warten muss oder nicht mit anderen Prozessen um CPU-Zeit konkurriert, wird er bereits so schnell wie möglich ausgeführt, und eine Änderung der Priorität wird ihn nicht schneller machen.

Im Allgemeinen ist ein zusätzlicher Aufwand erforderlich, wenn ein Programm mehr als eine CPU verwendet (durch Hinzufügen von Multithreading). Selbst wenn das Programm die höchste verfügbare Priorität hat, verwendet es möglicherweise nur einen Kern.

Andere mögliche Probleme:

• Das Programm könnte ineffizient / schlecht geschrieben sein
• Es könnte aufgrund eines "langsamen" Festplattenzugriffs oder eines langsamen Netzwerks verlangsamt werden

Selbst wenn die E / A-Priorität eines E / A-gebundenen Prozesses erhöht wird, wird er nicht unbedingt schneller ausgeführt. Wenn es sich beispielsweise um einen Verbraucher von Daten handelt, die von einem separaten, möglicherweise entfernten Prozess erzeugt werden, und mit der Geschwindigkeit Schritt hält, mit der diese Datenquelle die Daten erzeugt, können sie nicht schneller arbeiten oder einen höheren Durchsatz erzielen.

Anders als im ersten Satz der aktuell akzeptierten Antwort ( https://superuser.com/a/752587/322588 ) kategorisch angegeben, sind Prioritätsänderungen am effektivsten, wenn die CPU den Engpass darstellt, wie in der Antwort von Mike Dimmick erläutert ( https://superuser.com/a/752864/322588 ). Darüber hinaus ist die Aussage im zweiten Absatz der akzeptierten Antwort: "Wenn Ihr Prozess die gesamte Zeitscheibe erschöpft, die er bei der tatsächlichen Berechnung zugewiesen hat, dann wird die Planung dort nichts ändern", ist völlig falsch, es sei denn, der Prozess hat im Allgemeinen bereits die höchste Priorität lauffähige Threads, wenn es auf die Ausführung wartet. Dies liegt daran, dass in allen anderen Fällen die Erhöhung der Priorität wahrscheinlich mehr Zeitscheiben pro Zeitintervall der Wanduhr ergibt.

Mike Dimmick wies vor einigen Tagen auf die Probleme mit dieser Antwort hin und gab eine viel bessere Antwort, obwohl der erste unerklärlicherweise weiterhin Stimmen erhält. Die Behauptung des Autors, dass er seine Antwort für uns Attrappen bloß stumm macht, ist nicht plausibel, da sie nicht einfach oder gar simpel ist, sondern zumindest in Bezug auf CPU-gebundene Prozesse falsch ist.

Haftungsausschluss: Ich kenne Herrn Dimmick nicht, obwohl ich weiß, dass er weiß, worüber er schreibt.