Perché il tuo codice non dovrebbe utilizzare il 100% della CPU? [chiuso]

Se il raffreddamento è insufficiente, la CPU potrebbe surriscaldarsi. Ma tutti (beh, almeno tutte le moderne CPU per PC) dispongono di vari meccanismi di protezione termica che riducono la velocità del clock o, in ultima analisi, si spengono.

Quindi sì, su un laptop polveroso, il 100% del carico della CPU potrebbe causare problemi temporanei, ma nulla si romperà o si "degraderà" (qualunque cosa ciò significhi).

Per problemi legati alla CPU, il 100% di carico della CPU è la strada giusta da percorrere.

Per quanto riguarda la reattività dell'applicazione (UI), questo è un concetto separato dall'utilizzo della CPU. È completamente possibile avere un'applicazione non responsiva che utilizza l'1% di CPU o un'applicazione reattiva che utilizza il 100% di CPU. La reattività dell'interfaccia utente si riduce alla quantità di lavoro svolto nel thread dell'interfaccia utente e alla priorità del thread dell'interfaccia utente rispetto agli altri thread.

I programmi Windows (winforms / WPF) dovrebbero sempre essere reattivi. Con un'implementazione ingenua di un processo che utilizza il 100% delle risorse della cpu è fin troppo facile rendere il tuo programma o persino il tuo sistema sembrare lento e sospeso.

Con una buona implementazione (ad esempio: usa un thread separato con priorità più bassa) non dovrebbe essere un problema.

Non dovresti preoccuparti che la tua CPU si rompa prima.

Generalmente non c'è niente di sbagliato in un programma che usa il 100% di CPU mentre in realtà sta facendo un lavoro utile e non sta prendendo tempo lontano da qualcosa di più importante . Se una particolare piattaforma hardware è ad es. solo in grado di utilizzare il 100% della CPU in modo continuo per un secondo prima che debba ridursi al 50% per evitare il surriscaldamento, generalmente è meglio per un'applicazione che ha un lavoro utile da eseguire per essere veloce quanto può, e lasciare che la CPU o il sistema operativo gestiscano la limitazione necessaria, piuttosto che un'applicazione per indovinare quanto velocemente dovrebbe "funzionare". Se un'applicazione o un thread ha un lavoro a priorità bassa che sarebbe utile ma non critico in ogni momento, potrebbe essere utile per il sistema operativo limitare l'utilizzo della CPU con task con priorità bassa al 50%, in modo che se la CPU debba fare qualcosa in fretta sarà pronto per "sprint" per un secondo, ma l'applicazione non dovrebbe preoccuparsi di cose che vanno oltre la richiesta di una priorità bassa del thread.

Le più grandi situazioni in cui è brutto usare CPU al 100% sono quando:

• L'applicazione è in attesa di qualche evento che non verrà accelerato dal polling persistente [e potrebbe essere effettivamente ritardato se lo sforzo perso controllando se l'attività è stata eseguita occupa risorse della CPU che altrimenti potrebbero essere spese facendo l'attività].

• L'applicazione sta ridisegnando il display troppo spesso. La definizione di "eccessivamente spesso" dipenderà in qualche misura dalla natura del dispositivo di visualizzazione e dal contenuto mostrato. Se l'hardware del display può visualizzare 120 fps, potrebbero verificarsi casi in cui l'animazione potrebbe essere mostrata a 120 fps senza aggiungere sfocatura di movimento, ma non potrebbe essere visualizzata in modo pulito a frequenze di fotogrammi inferiori senza aggiungerla. Se il rendering di un fotogramma con motion blur richiederebbe molto più tempo rispetto al rendering senza, il rendering a 120 fps sull'hardware che lo supporta potrebbe non essere più costoso del rendering a una frequenza di fotogrammi più lenta con effetto movimento. [Situazione semplice: una ruota con 29 raggi, che ruota ad un giro al secondo. A 120 fps, la ruota sembrerebbe ruotare con la giusta velocità e direzione; a 60 fps, una ruota tremolante sembrerebbe ruotare lentamente nella direzione opposta].

Il primo è chiaramente riconoscibile come cattivo. Il secondo è un po 'più sottile. Se uno si rivolge a una piattaforma mobile, in alcuni casi potrebbe essere opportuno consentire agli utenti di selezionare la frequenza fotogrammi dell'animazione desiderata, poiché alcuni utenti potrebbero non essere preoccupati per la durata della batteria ma vorrebbero l'animazione di migliore qualità, mentre altri accetterebbero una qualità inferiore animazione in cambio di una migliore durata della batteria. Piuttosto che cercare di indovinare l'applicazione dove dovrebbe essere il trade-off, potrebbe essere utile lasciare che l'utente lo personalizzi.

"Le moderne CPU sono economiche e si degraderanno rapidamente al 100% della CPU".

Non penso che nessuno abbia effettivamente affrontato la parte "degradare" di questa domanda. Gli IC si degradano quando la temperatura die supera i limiti del produttore. Gli IC di solito sono progettati per funzionare fino a 125C, sebbene ogni 10C aumenti la vita del 50%

I processori non hanno sempre avuto una regolazione termica. Poi alcuni AMD Durons hanno avuto dei problemi (presumibilmente era possibile distruggerne uno se funzionassero senza dissipatore di calore). Ora tutti i processori per PC hanno sensori di temperatura incorporati che si inseriscono nell'orologio della CPU e rallentano il tempo per evitare danni. Quindi potresti scoprire che il tuo programma utilizza il 100% della CPU disponibile, ma la CPU funziona solo al 75% della sua velocità nominale perché il suo raffreddamento è inadeguato.

All'interno di un programma utente non è il posto giusto per provare a gestire il consumo della CPU. Generalmente il tuo programma dovrebbe alternare il fare le cose il più velocemente possibile e in attesa, sospeso, per l'input o l'accesso al disco. Dovresti evitare l'attesa e lo spinlock se possibile, ma come cortesia per il resto del sistema.

Sia Windows che Linux hanno sistemi "govenor" della CPU che eseguono prestazioni e gestione termica. Poiché questo viene fatto a livello di sistema operativo, può tenere conto del consumo totale della CPU del sistema. È responsabilità del sistema operativo gestire l'hardware e impedire ai programmi utente di utilizzarlo in modo improprio. È responsabilità dell'hardware proprietario mantenere i fan puliti e funzionanti e il produttore di adattarsi adeguatamente a dissipatori e ventole in primo luogo.

Ci sono alcuni casi in cui i dispositivi hanno un raffreddamento inadeguato, ma un'ondata di ritorni insegna ai produttori a non farlo.

Per giocare l'avvocato del diavolo: in un certo senso, un programma che non può raggiungere il 100% di utilizzo potrebbe causare un peggioramento dell'usura: a meno che non sia sospeso in attesa di un tasto, è probabile che sia sospeso in attesa di I / O del disco tempo. E i dischi sono (ancora solitamente) grandi dispositivi meccanici soggetti a usura meccanica o al rischio di shock / effetti giroscopici quando si spostano, per non parlare del consumo di energia.

"..modern CPUs are cheap and will degrade quickly at 100% CPU".

Non devi preoccuparti del "degrado della CPU". Le CPU moderne non sono di qualità inferiore rispetto ai precedenti.

È molto costoso (e sta diventando sempre più costoso ogni due anni) per fare CPU, alcuni miliardi per costruire un nuovo fab non sono infrequenti (vedi link).

link

I costi di produzione di una CPU dipendono al massimo dal n. di unità prodotte. Questo è un fatto ben noto nell'economia. Questo è il motivo per cui possono essere venduti (relativamente) "a buon mercato", dopotutto. (Penso, nessun collegamento necessario qui)

Posso elencare una serie di motivi per cui considererei le CPU moderne tendenzialmente di qualità superiore rispetto a "tempi passati".

Ma solo il più importante: i vantaggi del test. L'elettronica moderna è "progettata per il test". Se il software o l'hardware, l'intuizione generale di valutare i test su quasi tutto il resto, non è così vecchio. Per le CPU, i test vengono anche presi per formare i diversi tipi di prezzo e frequenza, ad es. le migliori CPU sono vendute con le frequenze più alte. Nonostante ciò, i processori meno costosi sono molto spesso in grado di operare con frequenze più elevate rispetto a quelli venduti - sono danneggiati solo per il motivo che il produttore vuole vendere alcuni processori "di alto livello" con prezzi più alti.

(D'altra parte, naturalmente ci sono più errori possibili per un processore con oltre 1,5 miliardi di transistor come al giorno d'oggi che con qualche migliaio di transistor di un processore degli anni settanta, ma questo non contraddice la mia risposta IMO. I processori in generale tendono ad avere molti errori noti, almeno nel microcodice, ma questo non è soggetto qui.)

Esistono anche più motivi per non preoccuparti della degredazione della CPU per il tuo programma:

• La prima ragione è che le moderne CPU riducono la frequenza o l'accelerazione, se diventano troppo calde.

  Dovrebbe essere chiaro che se si utilizza la CPU al 100% 24/7 per l'intero anno normalmente morirà prima di una CPU utilizzata solo ogni seconda settimana un'ora. Ma questo vale anche per le automobili, a proposito. Solo in questi casi penserei all'utilizzo della CPU e al potenziale sonno da solo.

• Il secondo motivo è che è davvero molto difficile scrivere un programma che utilizza il 100% della CPU dal sistema operativo (ad esempio, in Windows). Inoltre, le CPU moderne (normalmente) hanno almeno 2-4 core. Quindi un algoritmo tradizionale che tende a utilizzare il 100% di una CPU single core, ora ha solo il 50% in una CPU dual core (semplificato ma visto in scenari reali).

• Inoltre il sistema operativo ha il controllo sulla CPU e non sul tuo programma, quindi se ci sono altre applicazioni con priorità uguale o superiore (quale è l'impostazione predefinita), il tuo programma ottiene solo più CPU possibile, ma le altre applicazioni non moriranno di fame. (Naturalmente questa è solo la teoria semplificata, e ovviamente il multitasking di Windows, Linux e altri non è perfetto, ma nel complesso lo considererei vero).

"I was previously under the impression that 100% CPU usage was preferable for an intensive or long operation.."

Sì, rimani con questo. Ad esempio, se si esegue un looping in attesa di un altro processo, in altre parole non si fa nulla, non sarebbe troppo male se Thread.Sleep () alcuni millisecondi in quel ciclo, dando ulteriore tempo agli altri. Considerando che non è necessario per un buon sistema operativo multitasking, ho risolto alcuni problemi con questo, ad es. per Windows 2000. (Questo NON significa ovviamente usare Sleep () nei calcoli, per esempio ..

Tale degrado è teoricamente possibile e si chiama " elettromigrazione ". L'elettromigrazione dipende dalla temperatura, accelerando all'aumentare della temperatura. Se sia un problema pratico per le moderne CPU è in discussione. Le moderne pratiche di progettazione VLSI compensano l'elettromigrazione e i chip hanno maggiori probabilità di fallire per altri motivi.

Detto questo, l'elettromigrazione accade anche a carichi e temperature normali , ma è abbastanza lento che un chip ben progettato diventa obsoleto molto prima di fallire, o fallisce prima con un altro meccanismo.

Il tasso di elettromigrazione dipende dalla temperatura del chip, con il raddoppio della vita per ogni (molto approssimativamente) 10 ° C. Questo è, infatti, alla base di un test chiamato "HTOL" (vita operativa ad alta temperatura), che misura quanto tempo impiega un chip a morire ad esempio a 125 ° C. Un chip che gira a 125 ° C fallirà circa 100 volte più velocemente di un chip che gira a 55 ° C, quindi se progettato per durare almeno 10 anni a 55 ° C, un chip potrebbe non funzionare entro 1 mese a 125 ° C. Se stai lavorando a qualcosa di più ragionevole come 85 ° C, un chip di questo tipo fallirebbe almeno 5-10 volte prima di quello per cui è stato progettato.

Ovviamente, le CPU sono generalmente progettate tenendo conto delle temperature più elevate, quindi possono durare per anni a 85 ° C 24 ore al giorno, al 100% di funzionamento al 100%. Quindi ti suggerisco di non preoccuparti di "consumare" la CPU, e solo preoccuparti se un carico del 100% sia appropriato dal punto di vista dell'ingegneria del software.

Se si sta eseguendo il codice sui client, l'utilizzo della CPU al 100% significa che i computer client in quel momento non possono essere utilizzati per nient'altro che attività con priorità più alta. Poiché la maggior parte delle applicazioni di solito viene eseguita con priorità predefinita, gli utenti che utilizzano quei computer noteranno il blocco del computer e non potranno eseguire altro sui loro computer. Anche se stiamo parlando di brevi raffiche, gli utenti che lavorano su qualcosa lo noteranno comunque.

Come altri hanno detto, eri abbastanza riservato riguardo l'installazione, quindi non posso dirlo con certezza. Ma se i tuoi client sono computer desktop, stai lontano dal 100% di utilizzo della CPU. Non a causa del degrado della CPU, ma perché non è una buona forma per disturbare gli utenti durante il loro lavoro.

Quindi la situazione è questa: hai un codice che viene eseguito per cinque ore usando il 100% di tutte le CPU, che è ottimizzato il più possibile, il proprietario della macchina sta bene e la macchina è inutilizzabile per cinque ore, e il tuo collega afferma che sarebbe meglio eseguire il tuo codice in 6 ore utilizzando l'83,33% di tutte le CPU, perché mette meno usura sul computer.

Dipende dal computer che stai usando. So che un produttore di computer ha rifiutato le riparazioni in garanzia entro i termini della garanzia su computer domestici a basso costo che sono stati utilizzati in un ambiente scientifico attivo 24 ore su 24, 7 giorni su 7. Volevano chiaramente che il cliente acquistasse i loro server più costosi o i computer "business". Se hanno avuto successo, non lo so.

Ogni Mac che ho posseduto ha a un certo punto del suo ciclo di vita un codice al 100% di utilizzo della CPU per giorni alla volta. In un caso ho dovuto spegnere il display, perché non avevo il caricatore originale per un laptop, e con 4 core e hyper threading usava più energia del caricabatterie in dotazione - quindi la batteria è scarica e quando è arrivata Il 5% del computer ha rallentato la velocità di clock fino a quando la batteria ha raggiunto il 10%! (Con il display spento, funzionava a piena velocità per diversi giorni). In nessun caso, nessun effetto negativo.

Quindi con un computer ben progettato, hai ragione. Con un computer mal progettato e economico, il tuo collega potrebbe avere ragione. D'altra parte, potresti considerare il costo del tuo tempo di attesa rispetto al costo di acquisto di un computer sostitutivo.

Se è possibile, rendere il codice un'attività a priorità più bassa e assicurarsi di mantenere separato il thread pesante della CPU dalla GUI. Quindi potresti avere il 100% di utilizzo, ma l'utente può sempre eseguire altre attività e rimanere reattivo. Di per sé, una CPU è progettata per rimanere attiva al 100% di utilizzo per un po ', altrimenti non verrebbe rilasciata. A meno che l'utente finale non abbia apportato modifiche gravi e pericolose al proprio hardware, non si può danneggiare nulla.