Supponiamo di avere una carta "vai in testa alla fila" per il negozio di alimentari. Vai al negozio, riempi il carrello, vai ai banchi cassa e scopri che non c'è nessuno in fila. La tua carta ti aiuta a fare il check-out più velocemente? No.
Le priorità non influiscono sulla velocità di elaborazione, in quanto un processo con priorità più elevata non può essere eseguito più velocemente o anche per utilizzare più tempo della CPU ... non se è l'unica cosa che desidera utilizzare la CPU.
Per parlarne davvero dobbiamo menzionare i thread. I processi non "eseguono" in Windows. I thread, che fanno parte dei processi, sono quelli che funzionano. (Sebbene se un processo ha un solo thread, la distinzione è piuttosto sfocata dall'esterno.)
(A proposito: la terminologia di marketing secondo cui una CPU ha, ad esempio, "quattro core e otto thread", è fuorviante. Le CPU hanno core, ma le CPU non "hanno" thread. I thread sono parti di processi. Un core CPU senza hyperthreading abilitato può eseguire un thread; con hyperthreading abilitato, un core può eseguire due thread. Ma le CPU non "hanno" thread.)
Ogni thread è sempre in uno dei diversi stati di pianificazione. Gli stati più comunemente visti sono: In attesa (* nix lo chiama "bloccato"; in entrambi i sistemi operativi ciò significa attendere I / O o simili, non utilizza tempo della CPU e non ne vuole); Pronto (vuole usare il tempo della CPU ma al momento non ci sono CPU disponibili); e in esecuzione . Solo i thread in esecuzione richiedono tempo CPU; cioè se un processo non ha thread in esecuzione, si vedrà che usa lo zero% del tempo CPU in strumenti come Task Manager.
Un thread può essere eseguito solo su un core (o, se l'hyperthreading è abilitato, "processore logico") alla volta, quindi un processo può usare solo quanti core CPU (o LP) quanti sono i thread che vogliono eseguire al momento . (La stessa affermazione può essere fatta per l'intero sistema.)
La maggior parte dei thread sulla maggior parte dei sistemi trascorre la maggior parte del tempo nello stato di attesa. (Questo è il motivo per cui il tuo processo inattivo dovrebbe superare il 95% del tempo della CPU quando il tuo sistema non sta facendo nulla.) Le eccezioni sarebbero i thread "funzionanti" di cose come video o rendering 3d, giochi, ecc. Pochissimi thread potrebbero davvero utilizzare il 100% della CPU, perché generalmente devono lavorare su alcuni dati di input che devono leggere da qualche parte e generalmente creano dati di output che devono essere scritti da qualche parte. E potrebbero riferirsi a molti dati diversi nella memoria nel tempo, il che potrebbe significare che devono attendere che i guasti di una pagina siano risolti.
Ma i thread che fanno qualcosa come il rendering video o il rendering di immagini 3D potrebbero passare quasi tutto il loro tempo a "calcolare" nella CPU e ad aspettare molto poco l'I / O. Tali thread sono spesso chiamati "con limite di calcolo", il che significa che le loro prestazioni generali sono principalmente limitate dalla velocità della CPU.
L'impostazione effettuata in Task Manager stabilisce effettivamente la "priorità di base" per tutti i thread nel processo. La priorità effettiva, o "corrente", del thread può essere maggiore (ma mai inferiore alla base). Più su quello tra un momento. Le decisioni di pianificazione ("chi deve eseguire e su quale CPU") vengono sempre prese usando l'attuale priorità del thread. La priorità è significativa solo per i thread Pronto ed In esecuzione (o per dirla in altro modo, la priorità non è significativa per i thread in attesa).
Windows utilizza un algoritmo di pianificazione preventiva . Se un solo thread nel sistema desidera utilizzare il tempo della CPU, non importa minimamente quale sia la sua priorità; ottiene il 100% della CPU. Non è come se lo scheduler "trattenesse" una parte delle capacità della CPU quando è in esecuzione un thread a bassa priorità, nel caso in cui accada qualcosa di più alta priorità.
Se due thread vogliono utilizzare una CPU e hanno la stessa priorità, vengono programmati tramite ciò che viene chiamato "time-slicing" e nel tempo, ciascuno ottiene circa il 50% del tempo della CPU. Considerando che se hanno priorità diverse, il thread con priorità più alta ottiene il 100% e quello inferiore non ottiene nulla .
(In pratica non otterrà nulla, perché sperimenterà un periodico "boost di priorità per evitare la fame" che potrebbe dargli qualche decina di msec ogni 4 o 5 secondi circa. Ma questa non è in realtà un'eccezione a "priorità più alta ", perché viene fatto regolando la priorità del thread affamato.)
Se hai più di un core CPU, le cose diventano più interessanti e le priorità in generale hanno meno effetti. Supponiamo di avere due thread che vogliono essere eseguiti. E supponiamo di avere due o più core della CPU che non stanno facendo altro con priorità uguale o superiore a quei thread. Quindi i tuoi due thread otterranno ciascuno il 100% di un core, indipendentemente dalle rispettive priorità .
(Due persone si presentano al supermercato e ci sono due pedine gratis. Uno dei clienti ha una carta "vai in testa alla fila". Non importa.)
tl; versione dr (finora): le priorità non riguardano "chi ottiene quale percentuale del tempo della CPU", ma piuttosto "chi inizia per primo".
Non mi occuperò molto dell'hyperthreading qui, se non per dire che Windows tratta ciascuno dei due "processori logici" in un core più o meno allo stesso modo in cui tratterebbe un core se HT fosse spento. cioè sono trattati come CPU "reali", con questa eccezione: Windows farà di tutto per non usare più di un LP alla volta. vale a dire che normalmente non inizi a vedere entrambi gli LP in un core in uso fino a quando non hai più di un numero di thread che cercano di eseguire tutti contemporaneamente. Questo perché i due "processori logici" non offrono prestazioni simili al doppio di un singolo core non hyperthreaded.
Informazioni sulla "priorità di base": Windows regolerà ("boost" e "decadimento") l'attuale priorità dei thread in base a ciò che hanno fatto di recente. I thread che hanno completato di recente le operazioni di I / O saranno normalmente una tacca o due sopra la base; I thread dell'interfaccia utente (thread che eseguono una finestra) saranno spesso notevolmente più alti; I thread associati alla CPU saranno generalmente alla base. Lo scopo è mantenere la reattività nell'interfaccia utente del programma e anche mantenere le richieste di I / O che fluiscono verso cose come i dischi.
Un programma (processo) può anche cambiare la priorità di base di ciascuno dei suoi thread, all'interno di un intervallo determinato dalla priorità del processo (la cosa impostata in Task Manager). Ma la stragrande maggioranza dei programmi non dà fastidio. (Altri dovrebbero.)
Ci sono altre cose che stanno succedendo. A causa del boost / decadimento prioritario e poiché i sistemi multiprocessing (sia multicore, hyperthreaded, o entrambi) sono così comuni in questi giorni e perché ci sono sempre cose in esecuzione in background in Windows (ma, speriamo, non usando molto tempo della CPU), e a causa degli effetti di "affinità" sia dura che debole, è difficile eseguire casi di test e ottenere i risultati esatti che sarebbero previsti qui. Ma questo dovrebbe darti vicino a un'immagine corretta.
In conclusione...
È ragionevole lasciare la maggior parte delle cose su "Normale". In caso contrario, puoi facilmente finire per morire di fame qualcosa che ti piacerebbe davvero lavorare (anche se potresti non sapere che esiste), come le funzioni di svuotamento della cache del disco del sistema operativo. In effetti, molti dei processi del sistema operativo saranno diversi da quelli normali e dovrebbero essere lasciati ovunque Windows li metta.
Un caso ragionevole per l'utilizzo di Task Manager per armeggiare con le priorità è se si dispone di un'attività di hogging della CPU (come video o rendering 3D) e rallenta l'utilizzo del sistema mentre è in esecuzione. La cosa giusta è, che ci crediate o no, di abbassarne la priorità di una o due tacche. Utilizzerà felicemente tutti i cicli della CPU che nient'altro vuole, ma resterà fuori dal tuo uso interattivo del sistema. Potrebbe essere necessario un po 'più di tempo per completare il suo lavoro, ma lo farà con una minima interferenza per l'uso interattivo di altri programmi. Se non ti piace quel compromesso, non farlo! Ma impostalo su una priorità elevata nel tentativo di "farlo andare più veloce" e potrebbe bloccare l'intera UI fino al termine.
Non impostare mai nulla sulla cosiddetta classe di priorità in tempo reale.
(Modifica - questo paragrafo aggiunto) Ok, questa è un'affermazione estrema. ("Nessuna affermazione universale è vera - non escluso questo.") Almeno, non senza un'attenta considerazione. Se il tuo obiettivo è far funzionare qualcosa più velocemente, probabilmente non sarà di aiuto. Ma potrebbe "bloccare" il sistema (che richiede un ripristino, o sulla maggior parte delle macchine moderne, richiede un ciclo di accensione). O renderlo così non rispondente che potrebbe anche essere bloccato.
nb: qualsiasi app per la riproduzione di video dovrebbe attivare la funzione "Pianificazione della classe multimediale" in Vista e versioni successive. Ciò fornirà automaticamente fino all'80% di una CPU, calcolata su intervalli relativamente brevi. Se non riesci a ottenere una riproduzione priva di problemi con questo qualcosa è molto sbagliato.
Per ulteriori dettagli, consultare i capitoli sui thread e la pianificazione nella sesta edizione di Windows Internals di Solomon, Russinovich e Ionescu.
Vedi anche la mia risposta qui per informazioni su come impostare le priorità di processo e thread e sul significato della colonna "Priorità" in Task Manager.
When should I set [priorities in Task Manager]?quasi mai.