Dlaczego twój kod nie powinien używać 100% procesora? [Zamknięte]

Mówię konkretnie o programie C # .NET 4 działającym w systemie Windows XP lub nowszym, ale ogólne odpowiedzi są również dopuszczalne.

Załóżmy już zoptymalizowany i wydajny program. Problem polega wyłącznie na skutkach dużego zużycia procesora na sprzęcie i na tym, czy program o dużym zużyciu powinien być ograniczany w celu zmniejszenia zużycia, a nie na tym, czy moja implementacja jest wydajna.

Współczesny kolega zasugerował, że nie powinienem dążyć do 100% wykorzystania procesora w moich procesach ładowania danych, ponieważ „nowoczesne procesory są tanie i szybko ulegają degradacji przy 100% procesorze”.

Czy to prawda? A jeśli tak, to dlaczego? Wcześniej miałem wrażenie, że 100% użycie procesora jest lepsze w przypadku intensywnej lub długiej operacji i nie mogłem znaleźć żadnych poważnych źródeł na ten temat.

Jeśli chłodzenie jest niewystarczające, procesor może się przegrzać. Ale wszystkie (przynajmniej wszystkie współczesne procesory komputerowe) mają różne mechanizmy ochrony termicznej, które dławią szybkość zegara lub, w ostateczności, wyłączają się.

Tak, na zakurzonym laptopie 100% obciążenia procesora może powodować przejściowe problemy, ale nic się nie zepsuje ani nie „pogorszy” (cokolwiek to oznacza).

W przypadku problemów związanych z procesorem właściwym rozwiązaniem jest 100% obciążenie procesora.

Jeśli chodzi o czas reakcji aplikacji (UI), jest to odrębna koncepcja niż wykorzystanie procesora. Całkowicie możliwe jest, że aplikacja nie odpowiada, która wykorzystuje 1% procesora lub aplikacja responsywna, która wykorzystuje 100% procesora. Reaktywność interfejsu użytkownika sprowadza się do ilości pracy wykonanej w wątku interfejsu użytkownika oraz priorytetu wątku interfejsu użytkownika w porównaniu do innych wątków.

Programy Windows (winforms / WPF) powinny przez cały czas pozostawać responsywne. Dzięki naiwnej implementacji procesu, który wykorzystuje 100% zasobów procesora, zbyt łatwo jest sprawić, że Twój program, a nawet system, wydaje się powolny i zawieszony.

Przy dobrej implementacji (na przykład: użyj osobnego wątku o niższym priorytecie) nie powinno to stanowić problemu.

Nie powinieneś martwić się wcześniejszym zerwaniem procesora.

Zasadniczo nie ma nic złego w programie wykorzystującym 100% procesora , który faktycznie wykonuje użyteczną pracę i nie traci czasu na nic ważniejszego . Jeśli dana platforma sprzętowa jest w stanie np. Stale wykorzystywać 100% procesora przez jedną sekundę, zanim będzie musiała powrócić do 50%, aby uniknąć przegrzania, generalnie lepiej jest dla aplikacji, która ma użyteczną pracę do wykonaniaaby działać tak szybko, jak to możliwe, i pozwolić procesorowi lub systemowi operacyjnemu obsłużyć wszelkie niezbędne funkcje dławienia, niż aby aplikacja zgadła, jak szybko powinna „działać”. Jeśli aplikacja lub wątek ma pracę o niskim priorytecie, która byłaby przydatna, ale nie zawsze krytyczna, może być pomocne dla systemu operacyjnego ograniczenie użycia procesora o niskim priorytecie do 50%, aby jeśli procesor musiał to zrobić coś szybko będzie gotowe do „sprintu” przez sekundę, ale aplikacja nie powinna martwić się o takie rzeczy poza żądaniem niskiego priorytetu wątku.

Największe sytuacje, w których użycie 100% procesora jest złe, gdy:

• Aplikacja jest zajęty, oczekiwanie na niektóre zdarzenia, które nie będzie przyspieszona uporczywego odpytywania [i faktycznie może być opóźniony, jeżeli wysiłek zmarnowany sprawdzeniu, czy zadanie zostało wykonane zajmuje zasobów procesora, które w przeciwnym razie mogłyby być wydatkowane robi zadanie].

• Aplikacja zbyt często przerysowuje ekran. Definicja „zbyt często” będzie w pewnym stopniu zależeć od charakteru urządzenia wyświetlającego i wyświetlanej treści. Jeśli sprzęt wyświetlający może wyświetlać 120 klatek na sekundę, mogą wystąpić przypadki, w których animacja może być wyświetlana przy 120 klatkach na sekundę bez dodawania rozmycia ruchu, ale nie może być wyświetlana czysto przy niższej liczbie klatek na sekundę bez jej dodania. Jeśli renderowanie klatki z rozmyciem w ruchu zajęłoby znacznie więcej czasu niż renderowanie bez niej, to renderowanie przy 120 klatkach na sekundę na sprzęcie, który ją obsługuje, może w rzeczywistości nie być bardziej kosztowne niż renderowanie z mniejszą liczbą klatek na sekundę przy rozmyciu ruchu. [Prosta sytuacja: koło z 29 szprychami, obracające się z jednym obrotem na sekundę. Przy 120 fps koło wydaje się obracać z odpowiednią prędkością i kierunkiem; przy 60 fps,

Ten pierwszy jest wyraźnie rozpoznawalny jako zły. Drugi jest nieco bardziej subtelny. Jeśli kierujesz reklamy na platformę mobilną, w niektórych przypadkach pożądane może być umożliwienie użytkownikom wybrania pożądanej liczby klatek na sekundę animacji, ponieważ niektórzy użytkownicy mogą nie martwić się o czas pracy baterii, ale chcieliby animacji o najlepszej jakości, podczas gdy inni zaakceptują niższą jakość animacja w zamian za lepszą żywotność baterii. Zamiast zmuszać aplikację do odgadnięcia, gdzie powinien być kompromis, pomocne może być dostosowanie go przez użytkownika.

„nowoczesne procesory są tanie i szybko ulegają degradacji przy 100% procesorze”.

Nie sądzę, żeby ktokolwiek faktycznie zajął się „poniżającą” częścią tego pytania. Układy scalone ulegną degradacji, gdy temperatura matrycy przekroczy ograniczenia producenta. Układy scalone są zwykle zaprojektowane do pracy w temperaturze do 125 ° C, chociaż każde zwiększenie o 10 ° skraca żywotność o 50%

Procesory nie zawsze miały regulację termiczną. Następnie niektóre AMD Durons napotkały problemy (podobno można było je zniszczyć, jeśli uruchomiono je bez radiatora). Teraz wszystkie procesory komputerowe będą miały wbudowane czujniki temperatury, które zwracają sygnał do zegara procesora i spowalniają zegar, aby zapobiec uszkodzeniom. Może się więc okazać, że Twój program wykorzystuje 100% dostępnego procesora, ale procesor działa tylko z 75% jego prędkości znamionowej, ponieważ jego chłodzenie jest niewystarczające.

W programie użytkownika nie ma odpowiedniego miejsca do zarządzania zużyciem procesora. Zasadniczo twój program powinien przełączać się między robieniem rzeczy tak szybko, jak to możliwe, a oczekiwaniem, zawieszeniem, na wejście lub dostęp do dysku. Jeśli to możliwe, powinieneś unikać zajętości i blokowania, ale w ramach uprzejmości reszty systemu.

Zarówno Windows, jak i Linux mają systemy „govenor” procesora, które będą zarządzać wydajnością i temperaturą. Ponieważ odbywa się to na poziomie systemu operacyjnego, może uwzględniać całkowite zużycie procesora przez system. System operacyjny jest odpowiedzialny za zarządzanie sprzętem i zapobieganie jego niewłaściwemu użyciu przez programy użytkownika. Obowiązkiem właściciela sprzętu jest utrzymanie wentylatorów w czystości i poprawienie ich działania, a producent to przede wszystkim montaż odpowiednich radiatorów i wentylatorów.

Istnieje kilka przypadków, w których urządzenia mają niewystarczające chłodzenie, ale powódź zwrotów uczy producentów, aby tego nie robić.

Aby zagrać w adwokata diabła: W pewnym sensie program, który nie może osiągnąć 100% wykorzystania, może spowodować gorsze zużycie: O ile nie zostanie zawieszony w oczekiwaniu na naciśnięcie klawisza, istnieje prawdopodobieństwo, że przez większość czasu jest zawieszony w oczekiwaniu na We / Wy dysku. Dyski są (wciąż zwykle) dużymi urządzeniami mechanicznymi, które podlegają zużyciu mechanicznemu lub ryzyku wstrząsów / efektów żyroskopowych podczas ruchu, nie wspominając o zużyciu energii.

„Nowoczesne procesory są tanie i szybko ulegają degradacji przy 100% procesorze”.

Nie musisz się w ogóle martwić o „degradację procesora”. Nowoczesne procesory nie są gorszej jakości niż w dawnych czasach.

Wytwarzanie procesorów jest bardzo drogie (i staje się coraz droższe co kilka lat), niektóre miliardy na budowę nowej fabryki nie są rzadkością (patrz link).

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

Koszty produkcji procesora zależą co najwyżej od nie. wyprodukowanych jednostek. Jest to dobrze znany fakt w gospodarce. Właśnie dlatego mogą być sprzedawane (relatywnie) „tanie”. (Myślę, że link nie jest konieczny)

Mogę wymienić wiele powodów, dla których uważam, że współczesne procesory mają wyższą jakość niż w „dawnych czasach”.

Ale tylko najważniejsze: zalety w testowaniu. Nowoczesna elektronika jest „zaprojektowana do testów”. Niezależnie od tego, czy chodzi o oprogramowanie czy sprzęt, szeroki wachlarz wyceny testów w porównaniu do prawie wszystkiego innego nie jest tak stary. W przypadku procesorów są nawet przeprowadzane testy formowania różnych rodzajów cen i częstotliwości, np. Najlepsze procesory sprzedawane są z najwyższymi częstotliwościami. Mimo to tańsze procesory bardzo często są w stanie pracować z wyższą częstotliwością niż sprzedawane - są sparaliżowane tylko dlatego, że producent chce sprzedawać niektóre procesory „wysokiego poziomu” o wyższych cenach.

(Z drugiej strony, oczywiście jest więcej możliwych błędów dla procesora z ponad 1,5 miliardem tranzystorów jak zwykle w dzisiejszych czasach niż z tysiącem tranzystorów procesora z lat siedemdziesiątych. Ale to nie stoi w sprzeczności z moją odpowiedzią IMO. Procesory ogólnie zwykle mają wiele znanych błędów, przynajmniej w mikrokodzie, ale nie jest to tutaj przedmiotem).

Jest jeszcze więcej powodów, aby nie martwić się degradacją procesora w twoim programie:

• Pierwszym powodem jest to, że współczesne procesory zmniejszają częstotliwość lub przepustnicę, jeśli stają się zbyt gorące.

  Powinno być jasne, że jeśli wykorzystasz procesor w 100% 24/7 przez cały rok, zwykle umrze wcześniej niż procesor używany tylko co drugi tydzień przez godzinę. Nawiasem mówiąc, dotyczy to również samochodów. Tylko w takich przypadkach myślałem o wykorzystaniu procesora i potencjalnym śnie.

• Drugim powodem jest to, że naprawdę bardzo trudno jest napisać program, który wykorzystuje 100% procesora z systemu operacyjnego (np. W systemie Windows). Poza tym nowoczesne procesory (zwykle) mają co najmniej 2-4 rdzenie. Tak więc tradycyjny algorytm, który zwykle wykorzystuje 100% procesora jednordzeniowego, ma teraz tylko 50% na procesorze dwurdzeniowym (uproszczony, ale widoczny w rzeczywistych scenariuszach).

• Co więcej, system operacyjny kontroluje procesor, a nie program, więc jeśli istnieją inne aplikacje o tym samym lub wyższym priorytecie (co jest ustawieniem domyślnym), twój program otrzymuje tylko tyle procesora, ile to możliwe, ale inne aplikacje nie będą głodować. (Oczywiście jest to tylko uproszczona teoria i oczywiście wielozadaniowość systemów Windows, Linux i innych nie jest idealna, ale ogólnie uważam, że to prawda).

„Wcześniej miałem wrażenie, że 100% użycie procesora jest lepsze w przypadku intensywnej lub długiej operacji.”

Tak, zostań przy tym. Ale na przykład, jeśli czekasz i zapętlasz inny proces, innymi słowy nic nie robiąc, nie byłoby źle, gdybyś używał Thread.Sleep () przez kilka milisekund w tej pętli, dając dodatkowy czas innym. Chociaż nie jest to konieczne dla dobrego systemu wielozadaniowego, rozwiązałem niektóre problemy z tym np. Dla Windows 2000. (To NIE znaczy oczywiście, że używasz Sleep () w obliczeniach na przykład ..

Taka degradacja jest teoretycznie możliwa i nazywa się ją „ elektromigracją ”. Elektromigracja jest zależna od temperatury i przyspiesza wraz ze wzrostem temperatury. To, czy jest to praktyczny problem dla współczesnych procesorów, jest przedmiotem dyskusji. Nowoczesne praktyki projektowania VLSI kompensują elektromigrację, a chipy są bardziej podatne na awarie z innych powodów.

To powiedziawszy, elektromigracja zachodzi nawet przy normalnych obciążeniach i temperaturach , ale jest ona na tyle powolna, że ​​dobrze zaprojektowany układ albo przestaje działać znacznie wcześniej, zanim zawiedzie, albo zawodzi najpierw przez inny mechanizm.

Szybkość elektromigracji zależy od temperatury chipa, a żywotność podwaja się dla każdego (bardzo z grubsza) 10 ° C. Jest to w rzeczywistości podstawa testu o nazwie „HTOL” (żywotność w wysokiej temperaturze), który mierzy, ile czasu zajmuje chipowi umarcie w, powiedzmy, 125 ° C. Układ pracujący w temperaturze 125 ° C ulegnie awarii około 100 razy szybciej niż układ pracujący w temperaturze 55 ° C, więc jeśli zostanie zaprojektowany na co najmniej 10 lat w temperaturze 55 ° C, układ może ulec awarii w ciągu 1 miesiąca w temperaturze 125 ° C. Jeśli działałby w czymś bardziej rozsądnym, takim jak 85 ° C, taki układ nadal zawodziłby co najmniej 5-10 razy szybciej niż zostałby zaprojektowany.

Oczywiście procesory są zwykle projektowane z myślą o wyższych temperaturach, dlatego mogą zwykle pracować przez lata w 85 ° C 24/7 przy 100% obciążeniu. Sugeruję więc, abyś nie przejmował się „zużyciem” procesora, a jedynie martwił się, czy 100% obciążenia jest odpowiednie z punktu widzenia inżynierii oprogramowania.

Jeśli uruchamiasz swój kod na klientach, 100% wykorzystanie procesora oznacza, że ​​komputery klienckie w tym czasie nie mogą być używane do niczego innego niż zadania o wyższym priorytecie. Ponieważ większość aplikacji zwykle ma domyślny priorytet, użytkownicy korzystający z tych komputerów zauważą zawieszenie komputera i nie będą mogli tego zrobić na innych komputerach. Nawet jeśli mówimy o krótkich seriach, użytkownicy pracujący nad czymś nadal to zauważą.

Jak powiedzieli inni, byłeś dość skryty w kwestii konfiguracji, więc nie mogę tego powiedzieć na pewno. Ale jeśli Twoimi klientami są komputery stacjonarne, trzymaj się z dala od 100% wykorzystania procesora. Nie z powodu degradacji procesora, ale dlatego, że nie jest dobrą formą zakłócanie pracy użytkowników.

Sytuacja jest następująca: masz jakiś kod, który działa przez pięć godzin przy użyciu 100% wszystkich procesorów, który jest zoptymalizowany tak bardzo, jak to możliwe, właściciel maszyny jest w porządku, ponieważ maszyna jest bezużyteczna przez pięć godzin, a twój kolega twierdzi, że lepiej byłoby uruchomić kod w ciągu 6 godzin przy użyciu 83,33% wszystkich procesorów, ponieważ powoduje to mniejsze zużycie komputera.

To zależy od używanego komputera. Wiem, że producent komputerów odmówił naprawy gwarancyjnej w okresie gwarancyjnym na tanich komputerach domowych, które były używane w warunkach naukowych przez całą dobę. Wyraźnie chcieli, aby klient kupił droższe serwery lub komputery „biznesowe”. Czy udało im się odnieść sukces, nie wiem.

Każdy komputer Mac, którego posiadam, ma w pewnym momencie swojego kodu uruchomieniowego 100% użycie procesora przez kilka dni. W jednym przypadku musiałem wyłączyć wyświetlacz, ponieważ nie miałem oryginalnej ładowarki do laptopa, a dzięki 4 rdzeniom i hiper-wątkom zużywało ono więcej energii niż dostarczona ładowarka - więc bateria się wyczerpała, a kiedy osiągnęła 5 procent komputer spowolnił taktowanie zegara, aż bateria osiągnęła 10%! (Przy wyłączonym wyświetlaczu działał z pełną prędkością przez kilka dni). W żadnym przypadku nie występują żadne niepożądane skutki.

Dzięki dobrze zaprojektowanemu komputerowi masz rację. Przy źle zaprojektowanym, tanim komputerze twój kolega może mieć rację. Z drugiej strony możesz wziąć pod uwagę koszt czasu oczekiwania w porównaniu z kosztem zakupu komputera zastępczego.

Jeśli możesz, ustaw kod o niższym priorytecie i upewnij się, że wątek obciążający procesor jest oddzielony od GUI. Wtedy możesz mieć 100% wykorzystania, ale użytkownik zawsze może wykonywać inne zadania i pozostać responsywny. Procesor sam w sobie jest zaprojektowany tak, aby działał przez chwilę w 100%, inaczej nie zostałby zwolniony. O ile użytkownik końcowy nie dokona poważnych i niebezpiecznych modyfikacji swojego sprzętu, nie można niczego uszkodzić.