I computer stanno diventando più veloci, le applicazioni funzionano più facilmente per noi, tuttavia, quando si tratta di interagire con Windows sembra che non importi quale sia il coraggio del nostro PC, sembra sempre andare allo stesso ritmo. È qualcosa di esclusivo del sistema operativo di Redmond? È una cattiva ottimizzazione in termini di hardware o c'è una ragione tecnica dietro? Te lo spieghiamo.
La cosa normale, e per semplice logica, è pensare che poiché abbiamo più potenza di calcolo in un computer, i programmi consumano sempre meno risorse. Tuttavia, spesso scopriamo che non è così e che la mancanza di ottimizzazione prevale su altre cose. È per la pigrizia o l'insuccesso dei programmatori che ci sono una serie di decisioni a livello tecnico o circostanze inevitabili che lo portano?
Windows consuma sempre le stesse risorse di un PC
Dobbiamo partire dal fatto che negli attuali sistemi operativi è questa stessa e non le applicazioni, che si occupa di gestire i diversi processi e, quindi, non solo decidono dove vengono eseguiti e in quale ordine, ma anche in quali condizioni lo fanno ed è qui che entriamo in due diversi modi di utilizzare le risorse hardware, sia dal sistema stesso che dalle applicazioni.
Tuttavia, ce n'è uno che è un incubo in termini di prestazioni e che trasforma alcuni processi in veri e propri vampiri della potenza del nostro computer, nonostante non richiedano davvero così tanta potenza per funzionare e cioè che una percentuale fissa di la capacità è loro assegnata. in lavorazione. Indipendentemente dal fatto che abbiamo un potente computer di fascia alta o un modesto MiniPC. Ad esempio, Windows 11 viene fornito di serie con Virtualization Based Sicurezza, una funzionalità che fornisce piuttosto poco per gli utenti domestici, ma è in grado di consumare il 5% delle prestazioni, indipendentemente dal fatto che tu stia eseguendo un'applicazione su un Celeron o un Celeron. Xeon, con la differenza di potenza che questo implica.
Perché vengono prese queste misure?
In realtà, è impossibile prevedere le prestazioni che un programma richiederà, poiché dobbiamo tenere conto che dipenderà dalla latenza di ogni istruzione ed è impossibile prevederlo perché non sappiamo dove troverà i dati corrispondenti. Avrà le informazioni già nei registri o, in mancanza, in qualche livello della cache dei dati del processore? Si tenga conto che la latenza del processore, misurata nei suoi cicli di clock, varierà per ogni istruzione in funzione del periodo di ricerca delle informazioni.
Pertanto, con questa premessa, unitamente all'enorme numero di configurazioni hardware esistenti, è perfettamente compreso che per i processi di sistema, un sistema operativo, indipendentemente dal fatto che sia Windows, Linux o qualsiasi altro, richiede determinate percentuali di utilizzo fisso sulla potenza del processore. Inoltre, questo viene fatto su console e con il passare degli anni queste percentuali di utilizzo vengono ridotte per dare più potenza ai giochi. Non possiamo però dimenticare che in questo caso si parla di sistemi chiusi ed è una situazione totalmente diversa da quella dei computer.
Core aggiuntivi per il sistema operativo?
Tutto questo ci porta a una delle novità che abbiamo visto implementate nelle ultime due generazioni di Intel Processori core, anche se non in tutti i modelli. Stiamo parlando dei cosiddetti E-Core, che sulla carta sono stati pensati per compiti in background. Tuttavia, l'assegnazione a loro non è automatica. In altre parole, ciò che il sistema operativo farà è cercare, ad esempio, il 2% della potenza di un core libero di eseguire un processo chiave.
Il modo in cui il sistema operativo esegue i processi nei thread per il CPU è come trovare più spazio possibile in una scatola in cui mettere le cose. Non attiverà un altro nucleo se rimane ancora una percentuale in quelli esistenti. Le conseguenze? Bene, nonostante il fatto che gli E-Core siano una buona idea per questo tipo di attività, Windows potrebbe ignorarlo, poiché agli occhi del sistema operativo stesso, ciò che ha a disposizione è un certo numero di thread di esecuzione, non conoscere il potere che fornisce. contribuire ciascuno.
