İşlemciler bugünlerde gittikçe daha fazla çekirdek alıyor, bu da beni meraklandırıyor ...
Programcılar olarak, bu davranışa uyum sağlamalı ve birden fazla çekirdek için programlama konusunda daha fazla çaba harcamalıyız?
Bunu ne ölçüde yapmalı ve optimize etmeliyiz? Konu? Affinity? Donanım optimizasyonları? Başka bir şey?
Yanıtlar:
Ne kadar iyi olursanız olun, kodunuzu yazdığınız dili ve derleyiciyi geliştiren ekiplerden daha iyi bir konu yönetimi vb .
Uygulamanızın çok iş parçacıklı olması gerekiyorsa, ihtiyacınız olan konuları oluşturun ve derleyici ve işletim sisteminin işlerine devam etmesine izin verin.
Kaynakları en iyi şekilde kullanabilmeniz için bu konuların nasıl yönetildiğinin farkında olmanız gerekir. Çok fazla iş parçacığı oluşturmamak, örnek olarak akla gelen bir şeydir.
Ayrıca neler olduğunu bilmeniz gerekir (Lorenzo'nun yorumuna bakın), böylece iplik yönetimine ipuçları verebilir (veya özel durumlarda geçersiz kılabilirsiniz), ancak bunların az ve çok arasında olacağını düşünürdüm.
Ben bir .NET programcısıyım ve .NET'in Görevler olarak adlandırılan çoklu kullanım için yüksek düzeyde bir soyutlamaya sahip olduğunu biliyorum. Sizi metale karşı doğru çok iş parçacığının nasıl yapılacağı hakkında çok fazla bilgi sahibi olmaktan korur. Diğer mevcut geliştirme platformlarının benzer soyutlamalara sahip olduğunu varsayıyorum. Bu yüzden, çoklu iş parçacığı ile bir şey yapacaksanız, mümkünse bu seviyede çalışmaya çalışacağım.
Şimdi, kendi uygulamanızda çok iş parçacığına dikkat etmeli misiniz? Bu sorunun cevabı, yazdığınız uygulamaya çok bağlıdır. Binlerce (veya daha fazla) bağımsız şey üzerinde işlem yapan bir uygulama yazıyorsanız ve bu işlem paralel olarak yapılabilirse, o zaman kesinlikle çok iş parçacıklığından bir avantaj elde edersiniz. Ancak, basit bir veri giriş ekranı yazıyorsanız, çoklu iş parçacığı size çok fazla satın almayabilir.
En azından, bir kullanıcı arayüzü üzerinde çalışırken çoklu kullanım ile ilgilenmeniz gerekir. Kullanıcı arayüzünden uzun süredir devam eden bir işlemi başlatmak istemiyorsunuz ve bu işlemi yapmak için UI iş parçacığını ele geçirdiğiniz için yanıt vermemesini sağlıyorsunuz. Bir arka plan iş parçacığını kapatın ve en azından kullanıcıya bir İptal düğmesi verin, böylece bir hata yaparlarsa tamamlanmasını beklemek zorunda kalmazlar.
Objective-C ve Mac OS X ve iOS ülkelerinde, çerçeveler (diğerleri gibi) işlemci çekirdeklerindeki bu artışlardan yararlanmak ve geliştiriciden faydalanmak için güzel bir arayüz sunmak için yazılmıştır.
Mac OS X ve iOS'ta örnek Grand Central dağıtımdır. libcKuyruk tabanlı çoklu iş parçacığını kolaylaştırmak için (sanırım) ilaveler var . Daha sonra Kakao ve Temel çerçeveleri (diğerleri arasında) GCD'nin üzerine yazılır ve geliştiriciye dağıtım kuyruklarına ve çok az kazan plakası koduyla diş açmaya kolay erişim sağlar.
Birçok dil ve çerçeve benzer kavramlara sahiptir.
Zor kısım, CPU yoğun algoritmanızı, işlenebilecek yürütme yığınlarına bölmektir.
Daha sonra, sürekli olarak bir çekirdekten diğerine atlayan bir iş parçacığının, özellikle iki farklı fiziksel ölünün kullanıldığı mimarilerde performans cezaları (kaçırılan birinci ve ikinci seviye CPU önbelleği nedeniyle) olacaktır. Bu durumda iplik çekirdeği afinitesi iyi bir şeydir.
Şimdi (Ekim 2010) büyük bir geçiş dönemindeyiz.
Bugün 12 çekirdekli bir masaüstü bilgisayar satın alabiliriz.
Bugün 448 çekirdekli bir işlem kartı satın alabiliriz (NVidia Tesla'yı arayın).
Programlarımızın yakın gelecekte çalışacağı muazzam derecede paralel ortamları bilmeyerek geliştiricilerin ne kadar çalışabileceğine dair sınırlamalar var.
İşletim sistemleri, çalışma zamanı ortamları ve programlama kütüphaneleri sadece bu kadarını yapabilir.
Gelecekte, yeni .NET "Görev Çerçevesi" gibi soyutlamaları kullanarak, işlemimizi bağımsız işlemler için ayrık parçalara ayırmamız gerekecek.
Önbellek yönetimi ve yakınlık gibi ayrıntılar hala mevcut olacak - ancak bunlar yalnızca ultra performanslı uygulamanın provence'ı olacak. Aynı geliştirici, bu ayrıntıları 10k çekirdekli bir makinede manuel olarak yönetmek istemeyecektir.
aslında ne geliştirdiğinize bağlı. cevap, ne geliştirdiğinize bağlı olarak, "önemsiz" den "kesinlikle kritiktir" ve takımdaki herkesin paralel uygulamaları iyi anlamasını ve kullanmasını bekleriz ".
çoğu durumda, kilitlenme, iş parçacığı, görev ve görev havuzlarının sağlam bir şekilde anlaşılması ve kullanılması, paralellik ihtiyacı gerektiğinde iyi bir başlangıç olacaktır. (dil / lib'e göre değişir)
Buna ek olarak, tasarımlar arasındaki farkları da yapmalısınız - önemsiz olmayan çoklu işlem için, çoğu zaman birkaç yeni programlama modeli veya paralelleştirme stratejileri öğrenilmelidir. bu durumda, öğrenme, sağlam bir anlayışa sahip olmak için yeterli zamanın başarısız olması ve mevcut programların güncellenmesi için bir yıl (veya daha fazla) bir ekip gerekebilir. o noktaya ulaştıktan sonra, (umarım!) bugün yaptığınız gibi sorunları / uygulamaları algılamayacak veya yaklaşmayacaksınız (bu geçişi henüz yapmadıysanız).
bir başka engel de, bir programı belirli bir yürütme için etkin bir şekilde optimize etmenizdir. programları optimize etmek için çok fazla zamanınız yoksa, gerçekten gerektiği kadar faydalanamazsınız. yüksek seviyeli (veya belirgin) paralelleştirme, programınızın algılanan hızını oldukça az çaba ile artırabilir ve bu, bugün birçok takımın gideceği kadarıyla: "Uygulamanın gerçekten belirgin kısımlarını paralelleştirdik" - bazı durumlarda bu iyi. asılı meyveyi almanın ve basit paralellik kullanmanın faydaları çekirdek sayısı ile orantılı olacak mı? Çoğu zaman, iki ila dört mantıksal çekirdek olduğunda, ancak bunun ötesinde çok sık değil. çoğu durumda, zaman yatırımı göz önüne alındığında, bu kabul edilebilir bir getiri. bu paralel model birçok insanın paralelliğin iyi kullanımlarını uygulamaya girişidir.
bu önemsiz paralel modelleri kullanarak öğrendikleriniz tüm karmaşık paralel senaryolarda ideal olmayacaktır; karmaşık paralel tasarımları etkin bir şekilde uygulamak çok farklı bir anlayış ve yaklaşım gerektirir. bu basit modeller genellikle ayrılır veya sistemin diğer bileşenleri ile önemsiz bir etkileşime sahiptir. Ayrıca, bu önemsiz modellerin birçok uygulaması etkili bir şekilde karmaşık paralel sistemlere iyi ölçeklenmemektedir - kötü karmaşık bir paralel tasarım basit model kadar uzun sürebilir. ill: yürütme sırasında 8 mantıksal çekirdeği kullanırken tek dişli modelin iki katı kadar hızlı çalışır. en yaygın örnekler çok fazla iş parçacığı ve yüksek düzeyde senkronizasyon paraziti kullanmak / oluşturmaktır. genel olarak buna paralel yavaşlama denir. tüm paralel problemlere basit problemler olarak yaklaşırsanız karşılaşmak oldukça kolaydır.
bu nedenle, programlarınızda gerçekten etkili çoklu kullanım yöntemini (bugünün ikliminde azınlık) kullanmanız gerektiğini varsayalım: karmaşık modeli öğrenmek ve daha sonra program akışına ve etkileşime nasıl yaklaştığınızı yeniden öğrenmek için basit modeli etkili bir şekilde kullanmanız gerekecektir. karmaşık model, donanımın bugün olduğu ve en baskın iyileştirmelerin yapılacağı yer olduğu için programınızın en sonunda olması gereken yerdir.
basit modellerin yürütülmesi çatal gibi düşünülebilir ve karmaşık modeller karmaşık, ah, ekosistem gibi çalışır. Genel kilitleme ve iş parçacığı dahil olmak üzere basit modellerin anlaşılması, etki alanı (içinde geliştirdiğiniz) kullandığında ara geliştiricilerin olması gerektiğini veya yakında bekleneceğini düşünüyorum. karmaşık modelleri anlamak bugün hala (çoğu alanda) biraz olağandışı, ancak bence talep oldukça hızlı bir şekilde artacak. geliştiriciler olarak, programlarımızın çok daha fazlası bu modelleri desteklemelidir ve kullanımının çoğu bu kavramları anlama ve uygulamada oldukça geride kalmaktadır. mantıksal işlemci sayıları donanım geliştirmenin en önemli alanlarından biri olduğundan, karmaşık sistemleri anlayan ve uygulayabilen insanlara olan talep kesinlikle artacaktır.
Son olarak, çözümün sadece "paralellik eklemek" olduğunu düşünen birçok insan var. Çoğu zaman, mevcut uygulamayı daha hızlı hale getirmek daha iyidir. birçok durumda çok daha kolay ve çok daha basittir. vahşi ortamdaki birçok program hiçbir zaman optimize edilmemiştir; bazı insanlar henüz optimize edilmemiş versiyonun bir gün donanım tarafından gölgede bırakılacağı izlenimine kapıldılar. Performans önemliyse, mevcut programların tasarımını veya algosunu geliştirmek de önemli bir beceridir - sorunlara daha fazla çekirdek atmak her zaman en iyi veya en basit çözüm değildir.
modern PC'leri hedeflerken, iyi paralel sistemler uygulamak zorunda olan çoğumuzun çoklu kullanım, kilitleme, paralel kütüphaneler, bir kitap okuma değerinin ve birçok deneyim yazma ve test programlarının ötesine geçmesi gerekmeyecektir (temel olarak, yaklaşım yazma programları).
Biz yapıyoruz, ancak hesaplama ağır yazılımları yazıyoruz, böylece doğrudan birden fazla çekirdekten faydalanıyoruz.
Bazen zamanlayıcı konuları çekirdekler arasında çok hareket ettirir. Bu kabul edilebilir değilse, çekirdek yakınlıkla oynayabilirsiniz.
Olduğu gibi, işlemci frekansı yakın gelecekte artmayacak. 3 GHz işaretinin etrafında takılıp kaldık (hız aşırtma olmadan). Elbette, birçok uygulama için çok temel çok iş parçacığının ötesine geçmek gerekli olmayabilir. Bir kullanıcı arayüzü uygulaması oluşturuyorsanız, herhangi bir yoğun işlem bir arka plan iş parçacığında yapılmalıdır.
Gerçek zamanlı olması gereken büyük miktarda veri işleyen bir uygulama oluşturuyorsanız, evet, muhtemelen çok iş parçacıklı programlamaya bakmalısınız.
Çok iş parçacıklı programlama için performansınızda azalan getiriler elde edeceğinizi göreceksiniz; saat harcayabilir ve programı% 15 iyileştirebilir ve daha sonra bir hafta daha geçirebilir ve yalnızca% 5 daha geliştirebilirsiniz.