Artık kullanmamam gereken çok okuyuculu ve çok işlemcili programlama için kullanımdan kaldırılmış uygulamalar var mı?


36

FORTRAN ve BASIC'in ilk günlerinde, esasen tüm programlar GOTO ifadeleriyle yazılmıştır. Sonuç spagetti koduydu ve çözüm yapılandırılmış programlama idi.

Benzer şekilde, işaretçiler programlarımızdaki özellikleri kontrol etmek zor olabilir. C ++ bol miktarda işaretçi ile başladı, ancak referansların kullanılması önerilir. STL gibi kütüphaneler bazı bağımlılıklarımızı azaltabilir. Daha iyi özelliklere sahip akıllı işaretçiler oluşturmak için deyimler ve bazı C ++ sürümleri referanslara ve yönetilen kodlara izin veriyor.

Kalıtım ve polimorfizm gibi programlama pratikleri sahnelerin ardında çok fazla işaretçi kullanır (tıpkı yapılı programlama gibi dal talimatlarıyla doldurulmuş kodlar üretir). Java gibi diller, işaretçileri ortadan kaldırır ve programcıların tüm yeni eşleşmeleri ve ifadelerini silmek üzere dinamik olarak ayrılmış verileri yönetmek için çöp toplama özelliğini kullanır.

Okumamda semafor kullanmayan çoklu işlem ve çoklu iş parçacıklı programlama örnekleri gördüm. Aynı şeyi farklı isimlerle mi kullanıyorlar veya kaynakları eşzamanlı kullanımdan korumanın yapılandırılmasında yeni yöntemler var mı?

Örneğin, çok çekirdekli işlemcilerle çok okuyuculu programlama için belirli bir sistem örneği OpenMP'dir. Çevreye dahil olmadığı anlaşılan semafor kullanılmadan aşağıdaki gibi kritik bir bölgeyi temsil eder.

th_id = omp_get_thread_num();
#pragma omp critical
{
  cout << "Hello World from thread " << th_id << '\n';
}

Bu örnek aşağıdakilerden bir alıntıdır: http://en.wikipedia.org/wiki/OpenMP

Alternatif olarak, wait () ve signal () işlevlerine sahip semaforlar kullanılarak birbirlerinden benzer iplik korunması şöyle görünebilir:

wait(sem);
th_id = get_thread_num();
cout << "Hello World from thread " << th_id << '\n';
signal(sem);

Bu örnekte, işler oldukça basittir ve sadece basit bir inceleme wait () ve signal () çağrılarının eşleştiğini göstermek için yeterlidir ve çok sayıda eşzamanlılıkla bile iş parçacığı güvenliği sağlanır. Ancak, diğer algoritmalar daha karmaşıktır ve birçok iş parçacığı tarafından çağrılabilecek karmaşık koşullarla birden çok fonksiyona yayılmış çoklu semaforlar (hem ikili hem de sayma) kullanır. Kilitlenme oluşturmanın veya iş parçacığını güvenli hale getirememenin sonuçlarının yönetilmesi zor olabilir.

OpenMP gibi bu sistemler semaforlarla ilgili sorunları ortadan kaldırıyor mu?
Sorunu başka bir yere mi taşıdılar?
En sevdiğim semaforumu artık semafor kullanmamak için algoritma kullanarak nasıl değiştirebilirim?


Tam olarak neden bahsediyorsun? Ne gördün?
svick

4
Kaba olmanın anlamı yok, ama ilk üç paragrafı eleyebilirdin. Sorunuzla gerçekten ilgilenmiyorlar ve sonuçlarına fazlaca yaklaşıyorlar ve çok fazla argüman üretecekler.
dbracey

1
Whoa, büyük düzenleme. Bir cevabı bıçakladım. Bu soru hala GOTO, işaretçiler, kalıtım ve polimorfizm ile dolaşıyor, ancak cevabımda bu sorunları bir kenara koydum ve "kullanımdan kaldırılmış uygulamalar" sorusuna odaklandım.
Stuart Marks,

Yanıtlar:


15

Artık kullanmaması gereken eşzamanlı programlama teknikleri ve uygulamaları var mı? Evet derdim .

Bugünlerde nadir görünen erken eşzamanlı programlama tekniği, kesintiye dayalı programlamadır. UNIX 1970'lerde bu şekilde çalıştı. UNIX'teki Aslanlar Yorumuna veya Bach'ın UNIX İşletim Sisteminin Tasarımına bakınız . Kısaca, teknik bir veri yapısını değiştirirken geçici olarak kesintileri askıya almak ve daha sonra kesintileri geri yüklemektir. BSD spl (9) kılavuz sayfasınabu kodlama stiline bir örnek vardır. Kesmelerin donanım yönelimli olduğunu ve kodun, donanım kesilmesinin türü ile bu donanıma ilişkin veri yapıları arasında örtük bir ilişki olduğunu unutmayın. Örneğin, disk G / Ç arabelleklerini işleyen kodun, bu arabelleklerle çalışırken disk denetleyici donanımındaki kesintileri askıya alması gerekir.

Bu programlama stili, tek işlemcili olmayan donanımdaki işletim sistemleri tarafından kullanılmıştır. Uygulamaların kesintilerle uğraşması çok daha nadirdi. Bazı işletim sistemlerinde yazılım kesintileri oldu ve bence insanlar üzerlerine diş açma veya koroine sistemleri kurmaya çalıştılar, ancak bu çok yaygın değildi. (Kesinlikle UNIX dünyasında değil.) Kesinti tarzı programlamanın bugün küçük gömülü sistemler veya gerçek zamanlı sistemler ile sınırlı olduğundan şüpheleniyorum.

Semaforlar , kesintiler karşısında bir ilerlemedir, çünkü bunlar yazılım yapılarıdır (donanımla ilgili değil), donanım olanakları üzerinde soyutlamalar sağlarlar ve çoklu kullanım ve çoklu işlemeyi sağlarlar. Asıl sorun, yapılandırılmamış olmalarıdır. Programcı, her semafor ve koruduğu veri yapıları arasındaki ilişkiyi global olarak tüm program boyunca sürdürmekten sorumludur. Bu nedenle, bugün çıplak semaforların nadiren kullanıldığını düşünüyorum.

İleriye doğru atılan diğer bir küçük adım , eşzamanlılık kontrol mekanizmalarını (kilitler ve koşullar), korunan verilerle kaplayan bir monitördür . Bu, Mesa (alternatif bağlantı) sistemine ve oradan da Java'ya taşındı . (Bu Mesa belgesini okursanız, Java'nın monitör kilitlerinin ve koşullarının neredeyse Mesa'dan yazılı olarak kopyalandığını görebilirsiniz.) Monitörler, yeterince dikkatli ve çalışkan bir programcının eşzamanlı programları yalnızca kod ve veriler hakkındaki yerel gerekçeleri kullanarak güvenle yazabilmelerinde yardımcı olur. monitörün içinde.

Java'nın java.util.concurrentpaketinde olduğu gibi, çok sayıda eşzamanlı veri yapıları ve iş parçacığı havuzu oluşturma yapıları içeren ek kütüphane yapıları vardır . Bunlar, iplik hapsi ve etkili değişmezlik gibi ek tekniklerle birleştirilebilir. Bkz Java eşzamanlılık In Uygulama Goetz ve diğerleri tarafından. ark. daha fazla tartışma için. Ne yazık ki, pek çok programcı , ağır kaldırma işleminin zaten kütüphane yazarları tarafından yapıldığı ConcurrentHashMap gibi bir şey kullanmaları gerektiğinde, kendi veri yapılarını kilitlerle ve koşullarla hala yuvarlamaktadır .

Yukarıdaki her şey bazı önemli özellikleri paylaşır: genel olarak paylaşılabilir, değişken durum üzerinde etkileşime giren birden fazla denetim dizisine sahiptirler . Sorun, bu tarzdaki programlamanın hala yüksek oranda hata eğilimli olmasıdır. Küçük bir hatanın farkedilmemesi oldukça kolaydır, bu da yeniden üretilmesi ve teşhis edilmesi zor olan yanlış davranışlarla sonuçlanır. Bu şekilde büyük sistemler geliştirmek için hiçbir programcının "yeterince dikkatli ve çalışkan" olmaması olabilir. En azından, çok az. Bu nedenle, paylaşılabilir, değişken durumlu çoklu iş parçacıklı programlamanın, eğer mümkünse kaçınılması gerektiğini söyleyebilirim .

Ne yazık ki, her durumda önlenebilecek olup olmadığı tamamen açık değildir. Bu şekilde hala birçok programlama yapılmaktadır. Bunun başka bir şeyle desteklendiğini görmek güzel olurdu. Jarrod Roberson ve davidk01'den gelen cevaplar değişmez veriler, işlevsel programlama, STM ve mesaj iletme gibi tekniklere işaret eder. Onları önerecek çok şey var ve hepsi aktif olarak geliştiriliyor. Ama henüz eski moda olan iyi paylaşılan değişken durumun yerini tamamen aldıklarını sanmıyorum.

EDIT: işte sonunda belirli sorulara cevabım.

OpenMP hakkında fazla bir şey bilmiyorum. Benim izlenimim, sayısal simülasyonlar gibi son derece paralel problemler için çok etkili olabileceği yönünde. Ancak genel amaçlı görünmüyor. Semafor yapıları oldukça düşük seviyelidir ve programcının yukarıda açıklanan tüm sorunlarla semaforlar ve paylaşılan veri yapıları arasındaki ilişkiyi sürdürmesini gerektirir.

Semafor kullanan bir paralel algoritma varsa, dönüştürmek için herhangi bir genel teknik bilmiyorum. Nesnelere yeniden yerleştirmek ve çevresinde bazı soyutlamalar oluşturmak mümkün olabilir. Ancak, mesaj iletme gibi bir şey kullanmak istiyorsanız, tüm sorunu yeniden kavramlaştırmanız gerektiğini düşünüyorum.


Teşekkürler, bu harika bir bilgi. Referansları inceleyeceğim ve bahsettiğiniz kavramlarda benim için yeni olan şeyleri daha derine dalacağım.
GeliştiriciDon

Java.util.concurrent için +1 ve yorumda anlaştılar - 1.5'ten beri JDK'daydı ve nadiren kullanıldığını görürsem.
MebAone

1
Varsa, kendi yapılarınızı yuvarlamamanın ne kadar önemli olduğunu vurgulamanızı isterim. Çok fazla, çok fazla böcek ...
corsiKa

"Semaforlar kesintilere karşı bir ilerlemedir, çünkü bunlar yazılım yapılarıdır (donanımla ilgili değil) " demenin doğru olduğunu sanmıyorum . Semaforlar, Karşılaştır ve Değiştir komutunu uygulamak için CPU'ya veya çok çekirdekli varyantlarına bağlıdır .
Josh Pearce,

Tabii semaforların @JoshPearce edilir uygulanan donanım yapılar kullanılarak, ancak bir olan soyutlama vb CAS, test ve seti, cmpxchng gibi herhangi bir donanım yapısı, bağımsız
Stuart Marks

28

Sorunun Cevabı

Genel mutabakat paylaşılabilir değişken durum Bad ™ 'dir ve değişmez durum Good ™' dir, ki bu da fonksiyonel diller ve zorunlu diller tarafından tekrar tekrar doğru ve doğru olduğu kanıtlanmıştır.

Sorun, ana dil zorunlu dillerin sadece bu çalışma biçimini yerine getirmek için tasarlanmamış olmalarıdır, bu diller için bir şeyler değişmeyecek. Kıyaslamanın GOTOhatalı olduğu yer burasıdır . Değiştirilemez durum ve mesaj geçme harika bir çözüm ama her derde deva değil.

Kusurlu öncül

Bu soru, kusurlu bir öncül ile karşılaştırmaya dayanmaktadır; O GOTOgerçek sorun oldu ve evrensel bazı how kullanımdan kaldırıldı Dil Tasarımcılar ve Yazılım Mühendisliği Sendikaları Intergalatic Evrensel Kurulu ©! Bir GOTOmekanizma olmadan ASM hiç işe yaramazdı. Ham işaretçilerin C veya C ++ ile sorun olduğu ve bazı akıllı işaretçilerin her derde deva olduğu varsayımıyla aynı değildir.

GOTOproblem değildi, programcılar problemdi. Aynı paylaşılabilir değişken durum için de geçerli . Sorun kendi içinde değil , sorun olan programcıları kullanıyor. Paylaşılabilir değişken durumu , hiçbir zaman yarış koşullarına veya böceklerine sahip olmayacak şekilde kullanan bir kod üretmenin bir yolu olsaydı, sorun olmazdı. Tıpkı spagetti kodunu asla GOTOyazmazsanız ya da eşdeğer yapılarla yazıyorsanız, bu da bir sorun değildir.

Eğitim her derde deva

Idiot programcıları buydu deprecated, her popüler dil hala GOTOdoğrudan veya dolaylı bir yapıya sahipti ve bu tür bir yapıya sahip her dilde doğru bir şekilde kullanıldığında bir best practicezaman .

ÖRNEK: Java'nın etiketleri vardır ve try/catch/finallyher ikisi de doğrudan GOTOifadeler olarak çalışır .

Konuştuğum çoğu Java programcısı, immutableonların dışında the String class is immutable, onların gözlerindeki ifadeye benzeyen bir zombi ile yinelenen gerçekte ne anlama geldiğini bile bilmiyor . Bir sınıf oluşturmak için finalanahtar kelimeyi nasıl doğru kullanacaklarını kesinlikle bilmiyorlar immutable. Bu nedenle , değişmez mesajları kullanarak mesajlaşmanın neden bu kadar harika ve paylaşılabilir değişken durumun neden bu kadar iyi olmadığı konusunda hiçbir fikrinin olmadığından eminim .


3
+1 Mükemmel cevap, açıkça yazılı ve değişken durumun altında yatan deseni saptayarak. IUBLDSEU bir meme haline gelmeli :)
Dibbeke

2
GOTO, 'lütfen, gerçekten hayır, lütfen bir alev savaşı başlatınız, ikiye katlanıyorum.' Bu soru alevleri yok ediyor ama gerçekten iyi bir cevap vermiyor. Fonksiyonel programlama ve değişmezliğin saygın sözleri harika ama bu ifadelere hiç et yok.
Evan Plaice

1
Bu çelişkili bir cevap gibi görünüyor. İlk önce, "A Kötüdür, B İyidir" diyorsun, sonra "Salaklar itiraz edildi" diyorsun. Aynı şey ilk paragraf için de geçerli değil mi? Cevabınızın son bölümünü alıp "Paylaşılabilir değişken durum her dilde doğru kullanıldığında en iyi uygulamadır" diyemez miyim? Ayrıca, "kanıt" çok güçlü bir kelimedir. Gerçekten güçlü kanıtların olmadığı sürece kullanmamalısın .
luiscubal

2
Bir alev savaşı başlatmak niyetim değildi. Jarrod benim yorumuma cevap verinceye kadar, GOTO'nun tartışmalı olmadığını ve bir benzetme içinde iyi çalışacağını düşünmüştü. Soruyu yazdığımda, benim başıma gelmedi, ancak Dijkstra hem GOTO hem de semaforlarda sıfır noktasındaydı. Edsger Dijkstra bana dev gibi görünüyor ve semaforların (1965) ve erken (1968) icadı ile GOTO'lar hakkında bilimsel çalışmalar yaptı. Dijkstra'nın savunuculuk yöntemi genellikle huysuz ve yüz yüze idi. Tartışma / karşılaşma onun için işe yaradı, ancak ben sadece semaforlara olası alternatifler hakkında fikir istiyorum.
GeliştiriciDon

1
Birçok programın gerçek dünyada değişebilen şeyleri modellemesi gerekiyor. Saat 05: 37'de, nesne # 451, o andaki gerçek dünyada bir şeyin durumunu tutarsa ​​(5:37) ve ardından gerçek dünyadaki şeyin durumu değişirse, temsil eden nesnenin kimliği için mümkündür. Gerçek dünyadaki şeyin değişmez olması durumu (yani, her zaman nesne # 451 ile temsil edilecektir) ya da nesne # 451'in değişmez olması, ancak her ikisi için değil. Çoğu durumda, kimliğin değişmez olması, nesne # 451'in değişmez olmaktan daha yararlı olacaktır.
supercat

27

Akademik çevrelerdeki son öfke, Yazılım İşlem Belleği (STM) gibi gözüküyor ve çok iş parçacıklı programlamanın tüm tüylü ayrıntılarını, yeterince akıllı derleyici teknolojisini kullanarak programcıların elinden çıkarmayı vaat ediyor. Perdenin ardında hala kilitlenir ve semaforlar var ama siz programcı olarak endişelenmenize gerek yok. Bu yaklaşımın faydaları hala net değil ve bariz bir rakip yok.

Erlang , eşzamanlılık için mesaj geçişi ve aracıları kullanır ve bu, STM'den daha basit bir modeldir. Mesaj geçerken endişelenecek hiçbir kilit ve semafor yok, çünkü her bir ajan kendi mini evreninde çalışıyor, bu nedenle veriyle ilgili yarış koşulları yok. Hala bazı tuhaf kenar davalarınız var ama bunlar canlılar ve kilitlenmeler kadar karmaşık değiller. JVM dilleri Akka'yı kullanabilir ve mesaj geçişi ve aktörlerin tüm avantajlarından yararlanabilir, ancak Erlang'ın aksine JVM aktörler için yerleşik bir desteğe sahip değildir, bu nedenle günün sonunda Akka hala konu ve kilitleri kullanır, ancak siz programcı bunun için endişelenmenize gerek yok.

Benim bildiğim diğer model kilitleri ve iplikleri kullanmayan , başka bir zaman uyumsuz programlama biçimi olan futures'ları kullanmak .

Bu teknolojinin ne kadarının C ++ 'ta mevcut olduğundan emin değilim ancak olasılıkla net bir şekilde konu ve kilit kullanmayan bir şey görüyorsanız, eşzamanlılık yönetimi için yukarıdaki tekniklerden biri olacaktır.


Yeni terim "kıllı detaylar" için +1. Lol adam. Sadece bu yeni dönemde gülmekten vazgeçemiyorum. Sanırım bundan sonra "kıllı kod" kullanacağım.
Saeed Neamati,

1
@Saeed: Bu ifadeyi daha önce duymuştum, nadir değil. Komik olsa da katılıyorum :-)
Cameron

1
İyi cevap. .NET CLI'nın sözde sinyalizasyon desteği de var (kilitlemenin aksine) ancak kilitlemenin tamamen yerini aldığı bir örneğe henüz rastlamadım. Async'in önemli olup olmadığından emin değilim. Javascript / NodeJ'ler gibi platformlardan bahsediyorsanız, bunlar aslında tek iş parçacıklıdır ve yalnızca yüksek IO yüklerinde daha iyidir çünkü kaynak sınırlarını maksimize etmeye daha az hassastırlar (yani bir ton atılabilir bağlamda). CPU yoğun yüklerinde, zaman uyumsuz programlama kullanmanın yararı yoktur.
Evan Plaice

1
İlginç cevap, ben rastlamak olmasaydı gelecekleri önce. Ayrıca, Erlang gibi mesaj geçiş sistemlerinde hala kilitlenme ve livelock olabileceğinizi unutmayın . CSP resmi olarak kilitlenme ve livelock hakkında sebep oluşturmanıza izin verir, ancak bunu kendiliğinden engellemez.
Mark Booth,

1
Kilitsiz ekleyin ve bu listeye ücretsiz veri yapıları beklerdim.
stonemetal

3

Bunun çoğunlukla soyutlama seviyeleri ile ilgili olduğunu düşünüyorum. Programlamada sıklıkla, bazı ayrıntıları daha güvenli veya daha okunaklı bir şekilde soyutlamak veya bunun gibi bir şey soyutlamakta fayda vardır.

Bu kontrol yapıları için geçerlidir: ifs, fors ve hatta try- catchbloklar üzerinde sadece soyutlamalardır gotos. Bu soyutlamalar hemen hemen her zaman kullanışlıdır, çünkü kodunuzu daha okunabilir hale getirir. Ancak yine de kullanmanız gereken durumlar vardır goto(örneğin, elle montaj yapıyorsanız).

Bu aynı zamanda bellek yönetimi için de geçerlidir: C ++ akıllı işaretçiler ve GC, ham işaretçiler ve manuel bellek ayırma / tahsisat üzerine soyutlamalardır. Ve bazen, bu soyutlamalar uygun değildir, örneğin gerçekten maksimum performansa ihtiyacınız olduğunda.

Aynı şey çoklu iş parçacığı için de geçerlidir: gelecekler ve aktörler gibi şeyler sadece iplikler, semaforlar, muteksler ve CAS komutları üzerinde soyutlamalardır. Bu tür soyutlamalar, kodunuzu daha okunaklı hale getirmenize yardımcı olabilir ve ayrıca hatalardan kaçınmanıza yardımcı olur. Ama bazen, onlar sadece uygun değildir.

Hangi araçlara sahip olduğunuzu, avantaj ve dezavantajlarının neler olduğunu bilmelisiniz. Daha sonra (varsa) göreviniz için doğru soyutlamayı seçebilirsiniz. Daha yüksek soyutlama seviyeleri daha düşük seviyelere itiraz etmemektedir, soyutlamanın uygun olmadığı ve en iyi seçimin “eski yolu” kullanmak olduğu her zaman bazı durumlar olacaktır.


Teşekkürler, analojiyi yakaladınız ve WRT semaforlarının cevabının böyle olup olmadığına dair bir önyargılı fikrim ya da hatta balta öğütmek zorunda değilim. Benim için daha büyük sorular, daha iyi yollar var ve semaforların önemli bir şeyi kaçırmış gibi görünmeyen ve çok oklu algoritmaların tamamını yapamadıkları görülüyor.
GeliştiriciDon

2

Evet, ancak bazılarına rastlamanız mümkün değil.

Eski günlerde, engelleme yöntemlerinin kullanılması yaygındı (bariyer senkronizasyonu) çünkü iyi muteksler yazmak doğru değildi. Son zamanlarda bu olayların izlerini hala görebilirsiniz. Modern eşzamanlılık kitaplıklarını kullanmak, size daha zengin ve kapsamlı bir şekilde test edilmiş, paralelleştirme ve süreçler arası koordinasyon için araçlar kümesi sunar.

Aynı şekilde, eski bir uygulama da manuel olarak nasıl paralel hale getirileceğini bulmak için baş döndürücü kod yazmaktı. Bu (potansiyel olarak zararlı, yanlış yaparsanız) optimizasyon biçimi, optimizasyon da büyük ölçüde, sizin için bunu yapan derleyicilerin ortaya çıkması, gerektiğinde döngüleri gevşetmek, tahminen dalları takip etmek vb. İle ortaya çıkmıştır. , piyasada en az 15 yıl olmak. İplik havuzları gibi şeylerden yararlanmak, aynı zamanda, geçmişin bazı aldatıcı kurallarını da engelliyor.

Belki de kullanımdan kaldırılmış olan uygulama, modern, iyi test edilmiş kütüphaneleri kullanmak yerine, eşzamanlılık kodunu kendiniz yazmaktır.


Teşekkürler. Eşzamanlı programlamanın kullanımı için büyük bir potansiyel var gibi görünüyor, ancak disiplinli bir şekilde kullanılmazsa bir Pandora'nın kutusu olabilir.
GeliştiriciDon

2

Apple'ın Grand Central Satış, eşzamanlılık hakkındaki düşüncelerimi değiştiren zarif bir soyutlamadır. Kuyruklara odaklanması, benim mütevazi deneyimlerime göre asenkron mantığın uygulanmasını bir büyüklük sırası daha basit hale getiriyor.

Kullanılabilir ortamlarda programladığımda, iş parçacığı, kilitler ve dişler arası iletişim kullanımlarımın çoğunu değiştirmişti.


1

Paralel programlamaya yapılan en büyük değişikliklerden biri, CPU'ların öncekinden çok daha hızlı olmaları, ancak bu performansı elde etmek için güzel bir şekilde doldurulmuş önbellek gerektirmeleridir. Sürekli olarak aralarında değiş tokuş yaparken aynı anda birkaç iş parçacığı çalıştırmayı denerseniz, neredeyse her zaman her iş parçacığı için önbelleği geçersiz kılacaksınız (yani, her iş parçacığı üzerinde çalışmak için farklı veriler gerektirir) ve performansı sizden çok daha fazla öldürürsünüz yavaş işlemciler ile kullanılır.

Bu, zaman uyumsuz veya görev temelli (örneğin, Grand Central Dispatch veya Intel'in TBB) çerçevelerinin daha popüler olmasının bir nedenidir, bir seferde kod 1 görevini çalıştırırlar, bir sonrakine geçmeden önce bitirmeleri için - her birini kodlamanız gerekir Eğer tasarımı bozmak istemediğiniz sürece her görev çok az zaman alır (örn. paralel görevleriniz gerçekten kuyruğa alınır). CPU-yoğun görevler, tüm görevleri işleyen tek iş parçacığında işlenmekten çok alternatif bir CPU çekirdeğine geçirilir. Aynı zamanda gerçekten çok iş parçacıklı işlem yapılmıyorsa yönetimi de daha kolay.


Harika, Apple ve Intel teknolojisine referanslar için teşekkürler. Cevabınız, öz yakınlığa bağlılık yönetimi zorluklarını işaret ediyor mu? Çok çekirdekli işlemciler çekirdek başına L1 önbellekleri yineleyebileceğinden bazı önbellek performansı sorunları azaldı Örneğin: software.intel.com/en-us/articles/… Daha fazla önbellek isabetine sahip dört çekirdek için yüksek hızlı önbellek, aynı verilerde daha fazla önbellek özlüsü olan bir çekirdekten 4 kat daha hızlı olabilir. Matris çarpımı yapabilir. 4 çekirdekli 32 ipliğin rastgele programlanması yapılamaz. Benzeşimi kullanalım ve 32 çekirdek alalım.
GeliştiriciDon

aslında aynı problem olmasa da - çekirdek yakınlık sadece bir görevin özden çekirdeğe sıçradığı sorunu ifade eder. Bir görev kesintiye uğrarsa, aynı mesele yenisiyle değiştirilirse, asıl görev aynı çekirdekte devam eder. Intel'in orada söylediği: önbellek isabetleri = hızlı, önbellek özlemeleri = çekirdek sayısından bağımsız olarak yavaş. Sanırım sizi
AMD'ler
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.