Kodunuz neden% 100 CPU kullanmıyor? [kapalı]

Özellikle Windows XP veya daha yüksek sürümlerde çalışan bir C # .NET 4 programı hakkında konuşuyorum, ancak genel cevaplar da kabul edilebilir.

Zaten optimize edilmiş ve verimli bir program varsayalım. Buradaki problem tamamen CPU kullanımının donanım üzerindeki etkilerine ve uygulamamın verimli olup olmadığına değil, aşınmayı azaltmak için yüksek kullanımlı bir programın uygulanıp azaltılmayacağına bağlı.

Bugün bir meslektaşım, veri yükleme süreçlerimde% 100 CPU kullanımını hedeflememem gerektiğini önerdi çünkü “modern CPU'lar ucuz ve% 100 CPU'da hızlı bir şekilde düşecek”.

Bu doğru mu? Ve eğer öyleyse, neden? Daha önce yoğun veya uzun bir işlem için% 100 CPU kullanımının tercih edildiği izlenimi altındaydım ve bu konuda hiçbir şekilde saygın kaynak bulamadım.

Soğutma yetersizse, CPU aşırı ısınabilir. Ancak hepsi (en azından tüm modern PC işlemcileri), saat hızını düşürecek veya son çare olarak kapatılacak olan çeşitli termal koruma mekanizmalarına sahiptir.

Bu yüzden evet, tozlu bir dizüstü bilgisayarda,% 100 CPU yükü geçici sorunlara neden olabilir, ancak hiçbir şey kırılmayacak veya "bozulmayacak" (bu ne demekse).

CPU'ya bağlı problemler için% 100 CPU yükü doğru yoldur.

Uygulama (UI) duyarlılığına gelince, bu CPU kullanımından ayrı bir kavramdır. % 1 CPU kullanan yanıt vermeyen bir uygulamaya veya% 100 CPU kullanan duyarlı bir uygulamaya sahip olmak tamamen mümkündür. UI yanıt verebilirliği, UI iş parçacığında yapılan iş miktarına ve diğer iş parçacıklarına karşı UI iş parçacığının önceliğine indirgenir.

Windows programları (winforms / WPF) her zaman duyarlı kalmalıdır. % 100 CPU kaynaklarını kullanan bir işlemin saf bir şekilde uygulanmasıyla, programınızın ve hatta sisteminizin durgun ve asılı görünmesini sağlamak çok kolaydır.

İyi bir uygulama ile (örneğin: daha düşük önceliğe sahip ayrı bir iplik kullanın) sorun olmamalıdır.

İşlemcinin daha çabuk kırılması konusunda endişelenmemelisin.

Aslında % 100 CPU kullanan bir programda , aslında işe yarar bir iş yaparken ve daha önemli bir şeyden zaman ayırmayacağınız için genellikle yanlış bir şey yoktur . Belirli bir donanım platformu, örneğin aşırı ısınmayı önlemek için% 50'ye geri dönmek zorunda kalmadan önce sadece bir saniye boyunca% 100 CPU kullanabiliyorsa, genellikle çalışması için yararlı bir işi olan bir uygulama için daha iyidir.Olabildiğince hızlı çalıştırmak ve CPU veya işletim sisteminin "ne kadar hızlı" çalışması gerektiğini tahmin etmek için bir uygulamadan ziyade gerekli kısıtlamaları işlemesine izin verin. Eğer bir uygulama veya iş parçacığı düşük öncelikli bir işe sahipse, faydalı olacak ancak her zaman kritik öneme sahip değilse, işletim sisteminin düşük öncelikli görev CPU kullanımını% 50 ile sınırlandırması yararlı olabilir; hızlı bir şey bir saniye "sprint" hazır olacak, ancak uygulama düşük iplik önceliği istemenin ötesinde böyle şeyler için endişelenmemelidir.

% 100 CPU kullanmanın kötü olduğu en büyük durumlar:

• Uygulama, sürekli oylama ile hızlanmayacak olan bazı olayları beklemektedir [ve görevin yapılıp yapılmadığını kontrol etmek için harcanan çaba, aksi halde görevi yapmak için harcanabilecek CPU kaynaklarını kapsıyorsa gerçekte ertelenebilir ].

• Uygulama ekranı aşırı sık yeniden çiziyor. "Aşırı sık" ifadesi, bazı ölçütlerde, ekran cihazının doğasına ve gösterilen içeriğe bağlı olacaktır. Ekran donanımı 120 fps gösterebiliyorsa, hareket bulanıklığı eklemeden animasyonun 120 fps'de gösterilebildiği, ancak daha düşük kare hızlarında eklemeden net bir şekilde gösterilemediği durumlar olabilir. Hareket bulanıklığı olan bir karenin oluşturulması, gösterilmesinin yapılmamasından çok daha uzun sürerse, onu destekleyen donanımın 120 fps'de gerçekleştirilmesi, hareket bulanıklığı olan daha düşük kare hızında görüntülemekten daha maliyetli olamaz. [Basit durum: saniyede bir devirde dönen, 29 telli bir tekerlek. 120 fps'de, tekerleğin uygun hız ve yönde döndüğü görülecektir; 60 fps'de

İlki açıkça kötü olarak tanınır. İkincisi biraz daha ince. Eğer biri bir mobil platformu hedefliyorsa, bazı durumlarda kullanıcıların arzu edilen animasyon kare hızını seçmelerine izin verilmesi istenebilir, çünkü bazı kullanıcılar pil ömrü konusunda endişeli olmayabilir, ancak diğerleri daha düşük kaliteyi kabul ederken en iyi kalitede animasyon isteyebilir. daha iyi pil ömrü karşılığında animasyon. Uygulamanın takasın nerede olacağını tahmin etmeye çalışmak yerine, kullanıcının özelleştirmesine izin vermek yararlı olabilir.

"Modern CPU'lar ucuzdur ve% 100 CPU'da hızlı bir şekilde bozulur".

Kimsenin aslında bu sorunun "bozulma" kısmını ele aldığını sanmıyorum. IC sıcaklığı , kalıp sıcaklığı üreticinin sınırlarını aştığında düşecektir . IC'ler genellikle 125C'ye kadar çalışacak şekilde tasarlanmıştır, ancak her 10C'lik artış ömrü% 50 kısaltır

İşlemcilerde her zaman termal düzenleme yoktu. Sonra bazı AMD Durons problemleri yaşadı (iddiaya göre soğutucu olmadan çalıştırılırsa birini yok etmek mümkündü). Artık tüm PC işlemcilerinde CPU saatine geri beslenen yerleşik sıcaklık sensörleri olacak ve hasarı önlemek için saati yavaşlatacak. Bu nedenle, programınızın kullanılabilir CPU'nun% 100'ünü kullandığını ancak CPU'nun soğutmanın yetersiz olması nedeniyle işlemcinin anma hızının yalnızca% 75'inde çalıştığını görebilirsiniz.

Bir kullanıcı programı içerisinde CPU tüketimini yönetmeye çalışmak için doğru yer değildir. Genel olarak, programınız işleri mümkün olduğu kadar çabuk yapmak ve giriş veya disk erişimi için bekletmek, askıya almak arasında geçiş yapmalıdır. Mümkünse meşgul beklemekten ve sıkma işleminden kaçınmalısınız, ancak sistemin geri kalanı için nezaketen.

Hem Windows hem de Linux, performans ve termal yönetim yapacak CPU "govenor" sistemlerine sahiptir. Bu işletim sistemi düzeyinde yapıldığından, toplam sistem CPU tüketimini hesaba katabilir. Donanımı yönetmek ve kullanıcı programlarının yanlış kullanmasını önlemek işletim sisteminin sorumluluğundadır. Fanları temiz tutmak ve çalışır durumda tutmak donanım sahibinin sorumluluğundadır ve üretici her şeyden önce uygun soğutucu ve fanları takmak zorundadır.

Cihazların yetersiz soğutmaya maruz kaldığı birkaç durum vardır, ancak bir geri dönüş süngeri üreticilere bunu yapmamasını öğretir.

Şeytanın avukatını oynamak: Bir şekilde,% 100 kullanımına ulaşamayan bir program daha kötü aşınmaya neden olabilir: Bir tuşa basılması beklenmeden askıya alınmadığı sürece, çoğu zaman disk G / Ç için beklemenin askıya alınma olasılığı vardır. Ve diskler (hala genellikle) mekanik aşınmaya maruz kalan büyük mekanik cihazlardır veya güç tüketiminden bahsetmek yerine, hareket ettiklerinde şok / jiroskopik etki riski taşırlar.

".. modern CPU'lar ucuzdur ve% 100 CPU'da hızlı bir şekilde bozulur".

"CPU bozulması" konusunda endişelenmenize gerek yok. Modern CPU'lar önceki zamanlardan daha az kalitede değil.

Öyle çok pahalı (ve birkaç yılda bir daha pahalı oluyor) Yeni bir fab (bağlantıya bakınız) nadir değildir oluşturmak için, bazı milyarlarca işlemcileri yapmak.

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

Bir işlemcinin üretim maliyetleri en fazla no. üretildi. Bu ekonomide iyi bilinen bir gerçektir. Her şeyden önce (nispeten) “ucuz” olarak satılmalarının nedeni budur. (Bence burada bağlantı gerekli değil)

Modern CPU'ların "eski zamanlardan" daha kaliteli olma eğiliminde olduğunu düşünmemin birkaç nedenini listeleyebilirim.

Ancak sadece en önemlisi: Testteki avantajlar. Modern elektronikler "test için tasarlanmıştır". Yazılım veya donanım olsun, hemen hemen her şey üzerinde testler yapmanın geniş bir anlayışı çok eski değildir. CPU'lar için farklı fiyat ve sıklık türlerini oluşturmak için testler bile yapılır, örneğin en iyi CPU'lar en yüksek frekanslarla satılır. Buna rağmen, daha ucuz işlemciler satıldığından çok daha sık çalışabiliyorlar - yalnızca üreticinin bazı "yüksek seviye" işlemcileri daha yüksek fiyatlarla satmak istemesi nedeniyle sakat kalıyorlar.

(Diğer yandan, bugünlerde normalde 1.5 milyardan fazla transistöre sahip bir işlemcide yetmişlerin bir işlemcisinin bin transistörüne kıyasla daha fazla hata var. En azından mikro kodda bilinen birçok hataya sahip olma eğilimindedir , ancak bu konuya tabi değildir.)

Programınızın CPU bozulması konusunda endişelenmemek için daha da fazla neden var:

• Bunun ilk nedeni, modern CPU'ların çok ısınmaları durumunda frekanslarını veya kısmalarını düşürmeleridir.

  İşlemcinin% 100 / 7'sini% 100/7 kullanırsanız, normalde sadece bir saatte bir her ikinci haftada bir kullanılan CPU'dan daha erken öleceği açıktır. Ancak bu, arabalar için de geçerlidir. Sadece böyle durumlarda CPU kullanımı hakkında düşünürdüm ve potansiyel kendini uyur.

• İkinci sebep, işletim sisteminin CPU’nun% 100’ünü (örneğin Windows’ta) kullanan bir program yazmanın çok zor olmasıdır. Ayrıca, modern işlemciler (normalde) en az 2-4 çekirdeğe sahiptir. Dolayısıyla, tek çekirdekli bir işlemcinin% 100'ünü kullanma eğiliminde olan geleneksel bir algoritma, şimdi çift çekirdekli işlemcide (% 100 basitleştirilmiş ancak gerçek senaryolarda görülüyor) sadece% 50'ye sahip.

• Dahası, işletim sistemi CPU'nuzu kontrol eder ve programınız üzerinde değil, bu nedenle aynı veya daha yüksek önceliğe sahip başka uygulamalar varsa (varsayılan değer), programınız yalnızca mümkün olduğunca fazla CPU alıyor, ancak diğer uygulamalar açlıktan. (Tabii ki bu sadece basitleştirilmiş bir teoridir ve elbette Windows, Linux ve diğerlerinin çoklu görevi mükemmel değildir, ama genel olarak bunu doğru olarak düşünürdüm).

"Daha önce yoğun veya uzun bir işlem için% 100 CPU kullanımının tercih edildiği izlenimi altındaydım."

Evet, bununla kal. Ancak, örneğin, başka bir işlem için bekleyen ve döngü yaparsanız, başka bir deyişle, hiçbir şey yapmazsanız, Thread.Sleep () bu döngüdeki milisaniyelerin bir kısmını başkalarına ekstra zaman vererek verirseniz çok da kötü olmaz. Çok görevli bir işletim sistemi için gerekli olmasa da, bununla ilgili bazı sorunları çözdüm, örneğin Windows 2000 için. (Tabii ki hesaplamalarda Sleep () kullanımı elbette bu DEĞİLDİR).

Bu tür bir bozulma teorik olarak mümkündür ve " elektromigrasyon " olarak adlandırılır . Elektromigrasyon sıcaklığa bağlıdır ve sıcaklık arttıkça hızlanır. Modern işlemciler için pratik bir sorun olup olmadığı tartışma için hazır. Modern VLSI tasarım uygulamaları elektromigrasyonu telafi eder ve yongaların başka nedenlerle başarısız olma olasılığı daha yüksektir.

Elektromigrasyonun normal yüklerde ve sıcaklıklarda bile meydana geldiğini söylerken, iyi tasarlanmış bir çipin ya başarısızlıktan çok eski hale gelmesi ya da önce başka bir mekanizma ile başarısız olması yeterince yavaş.

Elektromigrasyon oranı talaş sıcaklığına bağlıdır ve ömür boyu her 10 ° C'de iki katına çıkar. Aslında bu, bir çipin 125 ° C'de ölmesinin ne kadar sürdüğünü ölçen "HTOL" (yüksek sıcaklıkta çalışma ömrü) adlı bir testin temelidir. 125 ° C'de çalışan bir çip, 55 ° C'de çalışan bir çipten kabaca 100 kat daha hızlı başarısız olur, bu nedenle 55 ° C'de en az 10 yıl sürecek şekilde tasarlanırsa, bir çip 125 ° C'de 1 ay içinde başarısız olabilir. 85 ° C gibi daha makul bir yerde çalıştırılması durumunda, böyle bir çip, tasarlandığından en az 5-10x daha erken bir sürede başarısız olur.

Elbette, CPU'lar genellikle daha yüksek sıcaklıklar düşünülerek tasarlanır, bu nedenle tipik olarak 85 ° C 24/7% 100 yük işletiminde yıllarca dayanabilirler. Bu nedenle, CPU'yu "yıpratmak" için endişelenmemenizi ve yalnızca% 100 yükün yazılım mühendisliği perspektifinden uygun olup olmadığı konusunda endişelenmenizi öneririm.

Kodunuzu istemcilerde çalıştırıyorsanız,% 100 CPU kullanımı, o sırada istemci bilgisayarların daha yüksek önceliğe sahip görevlerden başka bir şey için kullanılamadığı anlamına gelir. Çoğu uygulama varsayılan olarak öncelikli olarak çalıştığından, bu bilgisayarları kullanan kullanıcılar bilgisayarın donma olduğunu fark edecek ve bilgisayarlarında başka şeyler yapamayacaklardır. Kısa patlamalardan söz etsek bile, bir şey üzerinde çalışan kullanıcılar bunu fark edeceklerdir.

Diğerlerinin dediği gibi, kurulum konusunda oldukça gizliydiniz, bu yüzden kesin olarak söyleyemem. Ancak, müşterileriniz masaüstü bilgisayar ise,% 100 CPU kullanımından uzak durun. CPU bozulması yüzünden değil, kullanıcıları işleri sırasında rahatsız etmenin iyi bir yolu olmadığı için.

Yani durum şudur: Tüm işlemcilerin% 100'ünü kullanarak beş saat boyunca söyleyebileceğiniz bir kodunuz var, mümkün olduğunca optimize edilmiş, makinenin sahibi makinenin beş saat boyunca kullanılamaması ve iş arkadaşınızla iyi durumda Tüm CPU'ların% 83,33'ünü kullanarak kodunuzu 6 saatte çalıştırmanızın daha iyi olacağını iddia eder, çünkü bilgisayar üzerinde daha az aşınma ve yıpranma meydana gelir.

Kullandığınız bilgisayara göre değişir. Bir bilgisayar üreticisinin 24 saat süren bilimsel bir ortamda kullanılan ucuz ev bilgisayarlarında garanti süresi içinde onarımları reddettiğini biliyorum. Müşterinin daha pahalı sunucularını veya "iş" bilgisayarlarını satın almalarını açıkça istediler. Başarılı olup olmadıklarını bilmiyorum.

Sahip olduğum her Mac, hayatında bir noktada günlerce% 100 CPU kullanımında kod çalıştırıyor. Bir durumda, ekranı kapatmak zorunda kaldım, çünkü bir dizüstü bilgisayar için orijinal şarj cihazım yoktu ve 4 çekirdekli ve hiper iş parçacığıyla birlikte verilen şarj cihazından daha fazla güç harcadım; Bilgisayarın yüzde 5'i pil% 10'a kadar saat hızını yavaşlattı! (Ekran kapalıyken birkaç gün tam hızda çalıştı). Hiçbir durumda, herhangi bir kötü etki.

Yani iyi tasarlanmış bir bilgisayarla haklısın. Kötü tasarlanmış, ucuz bir bilgisayarla, iş arkadaşınız haklı olabilir. Öte yandan, bekleme sürenizin maliyetine karşılık yedek bilgisayar satın alma maliyetine bakabilirsiniz.

Yapabiliyorsanız, kodunuzu daha düşük öncelikli bir görev yapın ve CPU-ağır iş parçacığını GUI'den ayrı tuttuğunuzdan emin olun. Öyleyse% 100 kullanımınız olabilir, ancak kullanıcı her zaman başka görevleri yürütebilir ve yanıt verebilir. Kendi başına bir CPU bir süre% 100 kullanımda çalışmaya devam edecek şekilde tasarlanmıştır, aksi takdirde serbest bırakılmaz. Son kullanıcı donanımında ciddi ve tehlikeli değişiklikler yapmazsa, hiçbir şeye zarar veremezsiniz.