Perché il tuo codice non dovrebbe usare una CPU al 100%? [chiuso]

Sto parlando in particolare di un programma C # .NET 4 in esecuzione su Windows XP o versioni successive, ma sono accettabili anche risposte generali.

Assumi un programma già ottimizzato ed efficiente. Il problema qui è interamente dovuto agli effetti di un elevato utilizzo della CPU sull'hardware e se un programma di utilizzo elevato dovrebbe essere limitato per ridurre l'usura, non sul fatto che la mia implementazione sia efficiente.

Un collega ha suggerito oggi che non dovrei mirare all'utilizzo della CPU al 100% sui miei processi di caricamento dei dati perché "le CPU moderne sono economiche e si degraderanno rapidamente alla CPU al 100%".

È vero? E se sì, perché? In precedenza avevo l'impressione che l'uso della CPU al 100% fosse preferibile per un'operazione intensiva o lunga e non riuscivo a trovare fonti rispettabili sull'argomento in entrambi i casi.

Se il raffreddamento non è sufficiente, la CPU potrebbe surriscaldarsi. Ma tutti (beh, almeno tutte le moderne CPU per PC) dispongono di vari meccanismi di protezione termica che rallentano la velocità di clock o, come ultima risorsa, si spengono.

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

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

Per quanto riguarda la reattività delle applicazioni (UI), questo è un concetto separato dall'utilizzo della CPU. È del tutto possibile avere un'applicazione che non risponde 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 ad altri thread.

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

Con una buona implementazione (ad esempio: utilizzare un thread separato con priorità inferiore) non dovrebbe essere un problema.

Non dovresti preoccuparti che la tua CPU si rompa prima.

In genere non c'è nulla di sbagliato in un programma che utilizza CPU al 100% mentre in realtà sta facendo un lavoro utile e non sta prendendo tempo da qualcosa di più importante . Se una particolare piattaforma hardware è in grado, ad esempio, di utilizzare la CPU al 100% ininterrottamente per un secondo prima di dover rallentare al 50% per evitare il surriscaldamento, è generalmente meglio per un'applicazione che ha un lavoro utile da eseguireeseguire il più velocemente possibile e lasciare che la CPU o il sistema operativo gestiscano la limitazione necessaria, piuttosto che un'applicazione indovini la velocità con cui "dovrebbe" funzionare. Se un'applicazione o un thread hanno un lavoro a bassa priorità che sarebbe utile ma non critico in ogni momento, potrebbe essere utile per il sistema operativo limitare l'utilizzo della CPU con attività a bassa priorità al 50%, quindi se la CPU deve fare qualcosa in fretta sarà pronto per "scattare" per un secondo, ma l'applicazione non dovrebbe preoccuparsi di cose del genere oltre a richiedere una bassa priorità di thread.

Le situazioni più gravi in ​​cui è male usare una CPU al 100% sono quando:

• L'applicazione è in attesa di un evento che non verrà accelerato dal polling persistente [e potrebbe effettivamente essere ritardato se lo sforzo sprecato per verificare se l'attività viene eseguita occupa risorse della CPU che altrimenti potrebbero essere spese per l'attività].

• L'applicazione ridisegna 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 di visualizzazione può visualizzare 120 fps, potrebbero verificarsi casi in cui l'animazione potrebbe essere visualizzata a 120 fps senza l'aggiunta di motion blur, ma non potrebbe essere visualizzata in modo pulito a frame rate inferiori senza aggiungerlo. Se il rendering di un fotogramma con motion blur richiederebbe molto più tempo rispetto al rendering senza, quindi il rendering a 120 fps su hardware che lo supporta potrebbe effettivamente non essere più costoso del rendering con un frame rate più lento con motion blur. [Situazione semplice: una ruota con 29 raggi, ruotando di un giro al secondo. A 120 fps, la ruota sembrerebbe ruotare con la giusta velocità e direzione; a 60 fps,

Il primo è chiaramente riconoscibile come cattivo. Il secondo è un po 'più sottile. Se si sta prendendo di mira una piattaforma mobile, in alcuni casi potrebbe essere opportuno consentire agli utenti di selezionare la frequenza dei fotogrammi di animazione desiderata, poiché alcuni utenti potrebbero non essere preoccupati della durata della batteria ma vorrebbero l'animazione della migliore qualità, mentre altri accetterebbero una qualità inferiore animazione in cambio di una migliore durata della batteria. Piuttosto che avere l'applicazione tenta di indovinare dove dovrebbe essere il compromesso, può essere utile consentire all'utente di personalizzarlo.

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

Non penso che qualcuno abbia effettivamente affrontato la parte "degradata" di questa domanda. I circuiti integrati si degraderanno quando la temperatura dello stampo supera i limiti del produttore. I circuiti integrati sono generalmente progettati per funzionare fino a 125 ° C, anche se ogni aumento di 10 ° C riduce la vita del 50%

I processori non hanno sempre avuto una regolazione termica. Quindi alcuni AMD Duron hanno avuto problemi (presumibilmente era possibile distruggerne uno se eseguito senza dissipatore di calore). Ora tutti i processori per PC avranno sensori di temperatura integrati che rispondono al clock della CPU e rallentano il clock 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 di CPU. Generalmente il tuo programma dovrebbe alternarsi tra fare le cose il più velocemente possibile e aspettare, sospeso, per l'accesso o l'accesso al disco. Se possibile, dovresti evitare l'attesa e lo spinlock, ma per gentile concessione del resto del sistema.

Sia Windows che Linux hanno sistemi "govenor" di CPU che eseguiranno prestazioni e gestione termica. Poiché ciò avviene a livello di sistema operativo, può tenere conto del consumo totale di CPU del sistema. È responsabilità del sistema operativo gestire l'hardware e impedire ai programmi utente di utilizzarlo in modo improprio. È responsabilità del proprietario dell'hardware mantenere pulite e funzionanti le ventole e, in primo luogo, il produttore deve montare adeguati dissipatori e ventole.

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

Per interpretare 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 una sequenza di tasti, è probabile che sia sospeso in attesa dell'I / O del disco per la maggior parte del tempo. E i dischi sono (ancora di solito) grandi dispositivi meccanici soggetti a usura meccanica o al rischio di shock / effetti giroscopici quando si muovono, per non parlare del consumo di energia.

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

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

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

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

I costi di produzione di una CPU dipendono al massimo dal n. di unità prodotte. Questo è un fatto ben noto in economia. Questo è il motivo per cui possono essere venduti (relativamente) "economici" dopo tutto. (Penso, nessun collegamento necessario qui)

Sono in grado di elencare una serie di motivi per cui considero le CPU moderne tendenzialmente più di qualità rispetto ai "tempi passati".

Ma solo il più importante: vantaggi nei test. L'elettronica moderna è "progettata per il test". Che si tratti di software o hardware, l'ampia visione di valutare i test su quasi tutto il resto, non è così vecchia. Per le CPU, vengono anche eseguiti i test per formare i diversi tipi di prezzo e frequenza, ad esempio le migliori CPU vengono vendute con le frequenze più alte. Nonostante ciò, i processori più economici sono molto spesso in grado di funzionare con una frequenza superiore rispetto alle vendite, sono paralizzati solo per il motivo che il produttore vuole vendere alcuni processori "di alto livello" con prezzi più alti.

(D'altra parte, ovviamente ci sono più errori possibili per un processore con oltre 1,5 miliardi di transistor come al giorno d'oggi normale rispetto ad alcune migliaia di transistor di un processore degli anni Settanta. Ma questo non contraddice la mia risposta IMO. Processori in generale tendono ad avere molti errori noti, almeno nel microcodice, ma questo non è soggetto qui.)

Esistono ancora più motivi per non preoccuparti della degressione della CPU per il tuo programma:

• Il primo motivo è che le CPU moderne riducono la frequenza o l'acceleratore, se si surriscaldano.

  Dovrebbe essere chiaro che se si utilizza la CPU al 100% 24 ore su 24, 7 giorni su 7, tutto l'anno morirà normalmente prima di una CPU utilizzata solo ogni due settimane un'ora. Ma questo vale anche per le auto. Solo in questi casi penserei all'utilizzo della CPU e al potenziale sonno.

• 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 moderne CPU (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% su una CPU dual core (semplificata ma vista in scenari reali).

• Inoltre il sistema operativo ha il controllo sulla CPU e non sul tuo programma, quindi se ci sono altre applicazioni con la stessa o maggiore priorità (qual è l'impostazione predefinita), il tuo programma sta ottenendo solo quanta più CPU possibile, ma le altre applicazioni non lo faranno morire di fame. (Naturalmente questa è solo la teoria semplificata, e ovviamente il multitasking di Windows, Linux e altri non è perfetto, ma nel complesso lo considererei per davvero).

"In precedenza avevo l'impressione che l'utilizzo della CPU al 100% fosse preferibile per un'operazione intensiva o lunga .."

Sì, resta con questo. Ma per esempio, se stai aspettando e eseguendo il loop per un altro processo, in altre parole senza fare nulla, non sarebbe troppo male se Thread.Sleep () alcuni millisecondi in quel loop, dando tempo extra ad altri. Considerando che non è necessario per un buon sistema operativo multitasking, ho risolto alcuni problemi con questo, ad esempio per Windows 2000. (Ciò NON significa ovviamente usare Sleep () nei calcoli per esempio ..

Tale degrado è teoricamente possibile e si chiama " elettromigrazione ". L'elettromigrazione dipende dalla temperatura, accelerando quando la temperatura aumenta. Se si tratta di 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 avviene anche a carichi e temperature normali , ma è abbastanza lenta che un chip ben progettato o diventa obsoleto molto prima di fallire, oppure fallisce tramite un altro meccanismo prima.

Il tasso di elettromigrazione dipende dalla temperatura del chip, con raddoppia la durata di vita per ogni (molto approssimativamente) 10 ° C. Questa è, in effetti, la base di un test chiamato "HTOL" (vita operativa ad alta temperatura), che misura quanto tempo impiega un chip a morire, per esempio, a 125 ° C. Un chip funzionante a 125 ° C si guasterà circa 100 volte più velocemente di un chip funzionante a 55 ° C, quindi se progettato per durare almeno 10 anni a 55 ° C, un chip potrebbe guastarsi entro 1 mese a 125 ° C. Se funzionasse a qualcosa di più ragionevole come 85 ° C, un chip di questo tipo avrebbe comunque fallito almeno 5-10 volte prima del previsto.

Naturalmente, le CPU sono generalmente progettate tenendo conto delle temperature più elevate, quindi in genere possono durare per anni a 85 ° C 24/7 con un carico del 100%. Quindi suggerirei di non preoccuparti di "logorare" la CPU e di preoccuparti solo se un carico del 100% è appropriato dal punto di vista dell'ingegneria del software.

Se si esegue 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ù elevata. Poiché la maggior parte delle applicazioni di solito viene eseguita con priorità predefinita, gli utenti che utilizzano tali computer noteranno il blocco del computer e non potranno fare altro sui propri computer. Anche se stiamo parlando di brevi raffiche, gli utenti che lavorano su qualcosa lo noteranno comunque.

Come altri hanno detto, sei stato piuttosto riservato riguardo alla configurazione, quindi non posso dirlo con certezza. Ma, se i tuoi client sono computer desktop, stai lontano dall'utilizzo della CPU al 100%. Non a causa del degrado della CPU, ma perché non è una buona forma interrompere gli utenti durante il loro lavoro.

Quindi la situazione è questa: hai del 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 con la macchina che è inutilizzabile per cinque ore e il tuo collega afferma che sarebbe meglio eseguire il codice in 6 ore utilizzando l'83,33% di tutte le CPU, perché riduce l'usura del computer.

Dipende dal computer che si sta utilizzando. So che un produttore di computer ha rifiutato le riparazioni in garanzia entro il periodo di garanzia sui computer domestici a basso costo che sono stati utilizzati in un ambiente scientifico in esecuzione 24/7. Volevano chiaramente che il cliente acquistasse i loro server o computer "business" più costosi. Se hanno avuto successo, non lo so.

Ogni Mac di mia proprietà ha a un certo punto del suo ciclo di vita l'esecuzione al 100% dell'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 utilizzava più energia del caricabatterie in dotazione, quindi la batteria si è scaricata e quando ha raggiunto Il 5 percento del computer ha rallentato la velocità di clock fino a quando la batteria ha raggiunto il 10%! (Con il display spento, ha funzionato alla massima velocità per diversi giorni). In nessun caso, nessun effetto negativo.

Quindi, con un computer ben progettato, hai ragione. Con un computer mal progettato ed 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, rendi il tuo codice un'attività con priorità inferiore e assicurati di mantenere il thread pesante della CPU separato dalla GUI. Quindi potresti avere un utilizzo al 100%, ma l'utente può sempre eseguire altre attività e rimanere reattivo. Di per sé, una CPU è progettata per rimanere in esecuzione al 100% di utilizzo per un po 'o non verrebbe rilasciata. A meno che l'utente finale non abbia apportato modifiche gravi e pericolose al proprio hardware, non è possibile danneggiare nulla.