Mevcut yazılım endüstrisinde çoklu okuma ne kadar önemlidir? [kapalı]

MVC çerçevelerini (struts gibi) kullanarak Java'da web uygulamaları yazma konusunda 3 yıla yakın bir deneyime sahibim. Başlıca perakende zincirleri için kod yazmış olmama rağmen, şimdiye kadar çok iş parçacıklı kod yazmadım.

Mülakatlar sırasında çoklu okuma konusunda birkaç soru alıyorum ve genellikle onlara cevap veriyorum (çoğunlukla basit sorular). Bu beni şu anki endüstri senaryosunda okuyucunun ne kadar önemli olduğunu merak etmeme neden oldu.

Bu son derece önemlidir.

Yine de daha önemli olan, çok okuyucunun asenkronizasyon problemini çözmenin sadece bir yolu olduğunu anlamaktır. Birçok kişinin şu anda yazılım yazdığı teknik ortam, tarihsel yazılım geliştirme ortamından (toplu hesaplamalar yapan monolitik uygulamalardan) iki ana yoldan farklıdır:

• Çok çekirdekli makineler şimdi yaygındır. Artık saat hızlarının veya transistör yoğunluğunun büyüklük derecelerine göre artmasını bekleyemeyiz. Hesaplamanın fiyatı düşmeye devam edecek, ancak çok fazla paralellik nedeniyle düşecek. Bu güçten yararlanmanın bir yolunu bulmalıyız.

• Bilgisayarlar artık yoğun bir şekilde ağa bağlanmış ve modern uygulamalar, çeşitli kaynaklardan zengin bilgiler alabilmeye dayanmaktadır.

Hesaplamalı bir bakış açısına göre, bu iki faktör esas olarak aynı temel fikre doğru kaynamaktadır: bilgi giderek eşzamansız bir şekilde sağlanacaktır . İhtiyacınız olan bilginin makinenizdeki başka bir çipte mi yoksa dünyanın dört bir yanındaki bir çipte mi hesaplandığı önemli değildir. Her iki durumda da, işlemciniz orada oturup, yararlı işler yapabileceği zaman bilgi bekleyen ikinci bir milyar devir yakıyor .

Öyleyse, şimdi önemli olan ve gelecekte daha da önemli olan şey, başlı başına bir okuyuculuk değil, asenkronize ile uğraşmaktır . Multithreading bunu yapmanın sadece bir yoludur - zayıf bellek modeli yongaları daha yaygın bir şekilde kullanıldıkça daha karmaşık ve hataya daha açık hale gelebilecek karmaşık, hataya açık bir yol.

Araçlar satıcıları için zorluk, müşterilerimiz için gelecekte kullanacakları asenkron altyapı ile başa çıkmak için çoklu kullanımdan daha iyi bir yol bulmaktır.

Modern işlemcilerin gittikçe daha fazla çekirdeğe sahip olması giderek önem kazanıyor. On yıl önce, mevcut bilgisayarların çoğunda yalnızca tek bir işlemci vardı, bu yüzden çoklu okuma yalnızca üst seviye sunucu uygulamalarında önemliydi. Günümüzde temel dizüstü bilgisayarlarda bile çok çekirdekli işlemciler var. Birkaç yıl içinde mobil cihazlar bile ... Bu yüzden eşzamanlılığın potansiyel performans avantajlarını kullanmak ve çok iş parçacıklı bir ortamda doğru çalışmak için gittikçe daha fazla kod gerekiyor.

Genel olarak, çoklu iş parçacığı zaten çok önemli ve önümüzdeki birkaç yıl içinde (Péter Török'ün) belirttiği gibi daha da önem kazanacak - işlemcilerin yakın gelecekte (daha yüksek MHz yerine daha fazla çekirdek) nasıl ölçekleneceği .

Ancak sizin durumunuzda, çoğunlukla web uygulamaları ile çalışıyor gibi görünüyorsunuz. Web uygulamaları, web sunucunuzun her kullanıcı için istekleri işleme biçimi nedeniyle (yani paralel olarak), çok iş parçacıklıdır. Eşzamanlılık ve iş güvenliği (özellikle önbellek ve diğer paylaşılan verilerle ilgilenirken) anlamanız sizin için önemli olsa da, web uygulama kodunu dahili olarak çok iş parçacıklı hale getirmenin çok yararlı olacağı konusunda şüpheliyim (örneğin, birden çok çalışan) istek başına iş parçacığı). Bu anlamda, çok iş parçacığında uzman olmak bir web geliştiricisi için gerçekten gerekli olmadığını düşünüyorum. Görüşmelerde sıkça sorulur, çünkü oldukça zor bir konudur ve aynı zamanda birçok görüşmeci oraya gitmeden 10 dakika önce birkaç soru sorar.

Çok iş parçacıklı kırmızı bir ringa balığı. Çok iş parçacığı eşzamanlılık olan asıl soruna bir uygulama detay . Tüm iş parçacıklı programlar kilitler nedeniyle değil ve aynı anda değil.

Konular, concurrentprogramları uygulamak için yalnızca bir model ve uygulama şeklidir .

Örneğin, Erlang gibi dillerde çok iş parçacığı yapmadan yüksek oranda ölçeklenebilir ve hataya dayanıklı yazılımlar yazabilirsiniz.

Mülakatlar sırasında okuyuculuk üzerine birkaç soru alıyorum ...

Röportajları geçmek için çok okuyuculuk oldukça önemli olabilir. Kendi kendinden alıntı yapıyorum, "ekibimiz için adaylarla mülakat yaparken, bu beceriler projemizde önemli olduğu için (bunlar değil ) fakat bunlar bir şekilde kullandığımız genel dil bilgisini değerlendirmemi kolaylaştırdığı için eşzamanlılık soruları soruyorum ."

Performansı arttırmak için iş parçacılığından nasıl yararlanılacağını anlamak, çoğu endüstri ve uygulama için günümüzün yazılım ortamında kritik bir beceridir.

En azından eşzamanlılıkla ilgili meselelerin anlaşılması verilmelidir.

Tüm uygulamaların veya ortamların, örneğin birçok gömülü sistemde, bundan yararlanamayacağının açık olduğuna dikkat edin. Ancak Atom işlemcisi (ve diğerleri) bunu değiştirmeye çalışıyor gibi gözüküyor (hafif çok çekirdekli daha yaygın olmaya başlıyor).

Zaten çok iş parçacıklı kod yazıyor gibisiniz.

Java web uygulamalarının çoğu, aynı anda birden fazla isteği işleyebilir ve bunu birden fazla iş parçacığı kullanarak yaparlar.

Bu nedenle, en azından temelleri bilmenin önemli olduğunu söyleyebilirim.

İhtiyacınız olan durumlarda hala önemlidir, ancak gelişimdeki birçok şey gibi doğru iş için doğru araçtır. Diş açmadan üç yıl boyunca gittim, şimdi pratik olarak her şeyin bir temeli var. Çok çekirdekli işlemcilerde, diş açmaya hala büyük bir ihtiyaç var, ancak tüm geleneksel nedenler hala geçerli, hala duyarlı arayüzler istiyor ve yine de eşitleme ile başa çıkabilmek ve diğer şeylerle aynı anda başa çıkabilmek isteyeceksiniz.

Kısa cevap: Çok.

Daha uzun cevap: Elektronik (transistör tabanlı) bilgisayarlar teknolojinin fiziksel sınırlarına hızla yaklaşıyor. Isı oluşumunu ve mikroskobik devrelerin kuantum etkilerini yönetirken, her çekirdekten daha fazla saat sıkmak zorlaşıyor ve zorlaşıyor (devre yolları zaten "kuantum tünelleme" olarak adlandırılan bir etkinin bir elektron yapabileceği modern çipler üzerine o kadar yakın yerleştiriliyor? geleneksel bir elektrik yayı için uygun koşullara ihtiyaç duymadan "devreleri" bir devreden diğerine atlamak); bu nedenle, neredeyse tüm çip üreticileri, her bir CPU'ya daha fazla "yürütme birimi" koyarak her saati daha fazlasını yapabilmeye odaklıyorlar. Ardından, bilgisayar saat başına yalnızca bir şey yapmak yerine, 2 veya 4 hatta 8 yapabilir. Intel'de "HyperThreading", temelde bir CPU çekirdeğini iki mantıksal işlemciye böler (bazı sınırlamalarla). Neredeyse tüm üreticiler bir CPU yongasına en az iki ayrı CPU çekirdeği koyuyor ve masaüstü işlemciler için şu anki altın standart çip başına dört çekirdek. İki CPU yongası kullanıldığında, sekiz adet dört çekirdekli işlemci (16 AB ve isteğe bağlı HT) işlemci için tasarlanan sunucu anakartları var ve yeni nesil CPU'ların yonga başına altı veya sekiz olması muhtemel.

Tüm bunların bir sonucu olarak, bilgisayarların bilgisayar gücü kazanma şeklinden tam olarak yararlanabilmek için, bilgisayarınızın programınızı "bölmesine ve fethetmesine" izin vermeniz gerekir. Yönetilen diller en az bellek yönetimini programınızdan ayrı olarak ele alan bir GC iş parçacığına sahiptir. Bazılarında COM / OLE birlikte çalışmayı işleyen "geçiş" dişleri de vardır (performans için olduğu gibi yönetilen "sanal alanı" korumak için de). Bunun ötesinde, programınızın aynı anda birden fazla şeyi nasıl yapabildiğini düşünmeye başlamalısınız ve programınızın, programın parçalarının eşzamanlı olarak kullanılmasına izin verecek özelliklerle tasarlanması gerekiyor. Windows ve Windows kullanıcıları, programınızın arka plan konu başlıkları altında uzun ve karmaşık görevleri gerçekleştirmesini beklerler. programınızın kullanıcı arabirimini (programın ana iş parçacığında çalışır) Windows ileti döngüsüne "yanıt veren" tutar. Açıkçası, paralelleştirilebilir çözümleri olan (sıralama gibi) problemler doğal adaylardır, ancak paralelleşmeden faydalanan sınırlı sayıda problem türü vardır.

Çoklu okuma hakkında sadece bir uyarı: Daha fazla iş parçacığı daha iyi verimlilik anlamına gelmez. Doğru şekilde yönetilmezlerse, sistemi yavaşlatabilirler. Scala'nın aktörü, Java'nın iş parçacığını geliştirir ve sistem kullanımını en üst düzeye çıkarır (bir Java geliştiricisi olduğunuzdan bahseder).

EDIT: İşte multithreading olumsuz yönleri hakkında akılda tutulması gereken bazı şeyler:

• donanım kaynaklarını paylaşırken iş parçacığının birbirine karışması
• Tek bir dişlinin yürütme süreleri iyileşmedi, ancak sadece bir diş yürütülürken bile bozulabilir. Bu, daha yavaş frekanslardan ve / veya iplik değiştirme donanımını barındırmak için gerekli olan ilave boru hattı aşamalarından kaynaklanmaktadır.
• Çoklu okuma için donanım desteği yazılıma göre daha fazla görünür, bu nedenle hem uygulama programlarında hem de işletim sistemlerinde Çok İşlemciliğe göre daha fazla değişiklik yapılması gerekir.
• Eşzamanlılığı yönetme zorluğu.
• Test zorluğu.

Ayrıca, bu bağlantı aynı konuda bazı yardımcı olabilir.

Bu beni şu anki endüstri senaryosunda okuyucunun ne kadar önemli olduğunu merak etmeme neden oldu.

Performansın üçüncü parti kodundan gelmediği performans kritik alanlarda ağır kaldırma yapıyoruz, ama kendi başımıza, o zaman bu önem sırasındaki şeyleri CPU perspektifinden ele almaya meyilliyim (GPU kazandığım bir joker karakter. içine girmeyin):

1. Hafıza Verimliliği (örneğin: referansın yeri).
2. algoritmik
3. Çok iş parçacığı
4. SIMD
5. Diğer Optimizasyonlar (statik dal tahmini ipuçları, örneğin)

Bu listenin yalnızca önemine değil, bakım üzerindeki etkisi, ne kadar kolay oldukları (eğer önceden düşünülmeye değer değilse), listedeki diğer kişilerle etkileşimleri vb.

Hafıza Verimliliği

Çoğu, algoritmik yerine bellek verimliliği seçimime şaşırmış olabilir. Bunun nedeni, hafıza verimliliğinin bu listedeki diğer 4 öğeyle etkileşime girmesi ve bunun dikkate alınması genellikle "uygulama" kategorisinden ziyade "tasarım" kategorisinde olması. Kuşkusuz, burada bir miktar tavuk ya da yumurta problemi vardır çünkü hafıza verimliliğini anlamak için listedeki 4 öğenin hepsinin göz önünde bulundurulması gerekirken, diğer 4 öğenin tümü de hafıza verimliliğini dikkate almayı gerektirir. Yine de her şeyin merkezinde.

Örneğin, doğrusal zaman ardışık erişim ve geriye sabit zaman eklemeleri sunan ve küçük elemanlar için başka hiçbir şey sunan bir veri yapısına ihtiyacımız varsa, burada ulaşmak için saf seçim, bağlantılı bir liste olacaktır. Bu hafıza verimliliğini göz ardı ediyor. Karışımdaki bellek verimliliğini göz önüne aldığımızda, bu senaryoda daha bitişik yapılar seçiyoruz, örneğin birbirine bağlanmış yetiştirilebilir dizi temelli yapılar veya daha fazla bitişik düğüm (örneğin: bir düğüme 128 eleman yerleştiren) bir havuz ayırıcısı tarafından desteklenen bağlantılı bir liste. Bunlar aynı algoritmik karmaşıklığa sahip olmasına rağmen çarpıcı bir kenara sahiptir. Aynı şekilde, bir bellek algoritmasından ötürü bir algoritmanın karmaşıklığına rağmen, bir dizilimin genellikle hızlı sıralamalarını seçiyoruz.

Aynı şekilde, eğer hafıza erişim kalıplarımız doğada o kadar ayrıntılı ve dağınıksa, kodun en tanecikli seviyelerinde kilitlenirken yanlış paylaşım miktarını en üst düzeye çıkardığımız için verimli çoklu okumaya sahip olamayız. Bu nedenle, bellek verimliliği verimlilik çok iş parçacığını çoğaltır. Bu konudan en iyi şekilde yararlanmak için bir önkoşuldur.

Listedeki her bir öğe, verilerle karmaşık bir etkileşime sahiptir ve verinin nasıl temsil edildiğine odaklanmak, en sonunda, bellek verimliliği alanındadır. Yukarıdakilerin her biri, verileri temsil etmek veya erişmek için uygun olmayan bir yöntemle tıkanabilir.

Bellek verimliliğinin bu kadar önemli olmasının bir başka nedeni de bütün kod tabanında uygulayabilmesi . Genel olarak, insanlar verimsizliklerin buradaki ve buradaki çalışmaların küçük önemsiz bölümlerinden biriktiğini düşündüklerinde, bir profilleyiciyi yakalamaları gerektiğinin bir işaretidir. Yine de düşük gecikmeli alanlar veya çok sınırlı donanıma sahip olanlar, profil çıkardıktan sonra bile, tahsis etme, kopyalama ve hafızaya erişme. Tipik olarak bu, tüm kod tabanının, kod tabanı boyunca uygulanan yepyeni bir standartlar dizisine yol açabilecek bir performans sorununa duyarlı olabileceği tek zamandır ve bellek verimliliği genellikle bunun merkezindedir.

algoritmik

Bu, hemen hemen verilen bir şeydir, çünkü bir sıralama algoritmasındaki seçim, sıralama yapmak için aylar aylar süren toplu girişler arasındaki farkı yaratabilir. Seçim, eğer gerçekten de alt-parite veya kübik algoritmalar ile bir lineermik sistem arasında veya en azından 1.000.000 çekirdek makineye sahip olana kadar (lineer ve logaritmik veya sabit) arasındaysa, en büyük etkiyi yaratır (bu durumda hafıza) verimlilik daha da önemli hale gelirdi).

Ancak, kişisel listemin en üstünde değil, çünkü kendi alanında yetkin olan herhangi biri sıkıntı giderme için bir hızlandırma yapısı kullanmayı bilecektir, örneğin algoritmik bilgiye göre doygun olduğumuzu ve bunun gibi bir türevi kullanmak gibi şeyleri bildiğimizi biliyoruz. önek tabanlı aramalar için sayı tabanı ağacı bebek eşyalarıdır. Çalıştığımız alanla ilgili bu tür temel bilgilerden yoksun olmak, algoritmik verimlilik kesinlikle en üst seviyeye çıkacaktır, ancak çoğu zaman algoritmik verimlilik önemsizdir.

Ayrıca, yeni algoritmalar icat etmek bazı alanlarda bir zorunluluk olabilir (örneğin: mesh işlemede daha önce bulunmadığı için yüzlerce tane icat etmem gerekti ya da diğer ürünlerdeki benzer özelliklerin uygulanması bir makalede yayınlanmayan özel sırlardı). ). Bununla birlikte, sorun çözme bölümünü geçtikten ve doğru sonuçları almanın bir yolunu bulduğumuzda ve verimlilik hedef haline geldiğinde, gerçekten kazanmanın tek yolu, verilerle nasıl etkileşime girdiğimizi düşünmektir (bellek). Bellek verimliliğini anlamadan, yeni algoritma, daha hızlı ve daha basit bir algoritma sağlamak için ihtiyaç duyulan tek şey bellek verimliliğini biraz daha düşünmek olduğunda, daha hızlı hale getirmek için boşuna çabalarla gereksiz yere karmaşık hale gelebilir.

Son olarak, algoritmalar "uygulama" kategorisinde bellek verimliliğinden daha fazla olma eğilimindedir. Başlangıçta kullanılan en uygun bir alt algoritma bile olsa, daha önceden iyileştirilmesi daha kolaydır. Örneğin, düşük kaliteli bir görüntü işleme algoritması genellikle kod tabanında yalnızca bir yerel yerde uygulanır. Daha sonra daha iyi bir tane ile değiştirilebilir. Bununla birlikte, tüm görüntü işleme algoritmaları, Pixelen uygun alt bellek temsiline sahip bir arayüze bağlıysa , ancak bunu düzeltmenin tek yolu, çoklu piksellerin temsil edilme şeklini değiştirmektir (tek bir tane değil) SOL ve kod tabanını tamamen yeniden yazmak zorunda kalacaksınız.Imagearayüz. Aynı tür bir sıralama algoritmasını değiştirmek için de geçerlidir - bu genellikle bir uygulama detayıdır; sıralanan verilerin temelini temsil etmesinde veya mesajlardan geçirilme biçiminde yapılan tam bir değişiklik, arayüzlerin yeniden tasarlanmasını gerektirebilir.

Çok iş parçacığı

Multithreading, donanım bağlamında oynayan mikro düzeyde bir optimizasyon olduğundan performans bağlamında zor bir durumdur, ancak donanımımız gerçekten bu yönde ölçeklenir. Zaten 32 çekirdeği olan akranlarım var (sadece 4'üm var).

Yine de mulithreading, amacı yazılımı hızlandırmak için kullanılıyorsa, muhtemelen bir profesyonel tarafından bilinen en tehlikeli mikro optimizasyonlardan biridir. Yarış durumu mümkün olan en ölümcül hatadır, çünkü doğası gereği belirsizdir (belki de birkaç ayda bir geliştiricinin makinesinde hata ayıklama bağlamı dışında en elverişsiz bir zamanda ortaya çıkabilir). Bu yüzden tartışmasızlık ve tüm bunların arasında potansiyel kod doğruluğu konusundaki en olumsuz bozulmaya sahiptir, çünkü özellikle çoklu kullanım ile ilgili hatalar, en dikkatli testlerin bile radarı altında kolayca uçabilmektedir.

Bununla birlikte, bu çok önemli hale geliyor. Halihazırda sahip olduğumuz çekirdek sayısı göz önüne alındığında, bellek verimi (bazen yüzlerce kez daha hızlı hale getirebilen) gibi bir şey hala her zaman trump olmasa da, daha fazla çekirdek görüyoruz. Tabii ki, 100 çekirdekli makinelerde bile, listenin en üstünde bellek verimliliğini koyardım, çünkü iplik verimliliği genellikle onsuz mümkün değildir. Bir program böyle bir makinede yüz iplikler kullanabilir ve yine de verimli bellek gösterimi ve erişim düzenleri (kilitleme düzenlerine bağlı olacak şekilde) bulunmadığında yavaş olabilir.

SIMD

SIMD ayrıca biraz garip çünkü kayıtlar daha da genişliyor, daha da genişleme planları var. Başlangıçta 64-bit MMX kayıtlarını ve ardından paralel olarak 4 SPFP işlemi yapabilen 128-bit XMM kayıtlarını gördük. Şimdi paralel olarak 8 yetenekli 256-bit YMM kayıt görüyoruz. Ve zaten 16'ya paralel olarak izin verecek olan 512 bitlik kayıtlar için zaten planlar var.

Bunlar multithreading'in verimliliği ile etkileşime girecek ve çoğalacaktır. Ancak SIMD, çok iş parçacığı kadar sürdürülebilirliği de azaltabilir. Onlarla ilgili hataların bir kilitlenme veya yarış durumu olarak çoğaltılması ve düzeltilmesi zor olmasa da, taşınabilirlik zordur ve kodun herkesin makinesinde çalışmasını sağlamak (ve donanım özelliklerine göre uygun talimatları kullanmak); garip.

Başka bir şey ise, bugün derleyiciler genellikle ustalıkla yazılmış SIMD kodunu geçmemelerine rağmen, kolayca naif denemeleri yenerler. Artık manuel olarak yapmak zorunda olmadığımız veya en azından kendinden veya doğrudan montaj kodu (belki de sadece küçük bir insan rehberliği) yazmak için el ile kullanmak zorunda kalmayacağımız bir noktaya gelebilirler.

Yine de, vectorized işlem için verimli bir bellek düzeni olmadan, SIMD işe yaramaz. Sadece bir işlem yapmak için sadece bir skaler alanı geniş bir sicile yükleyerek bitireceğiz. Tüm bu öğelerin temelinde, bellek düzenlerine gerçekten verimli olmak için bir bağımlılık var.

Diğer Optimizasyonlar

Bunlar genellikle, eğer kelime sadece algoritmik odağın ötesine geçmeyi değil, aynı zamanda performans üzerinde küçük bir etkiye sahip olan değişikliklere doğru ilerlemeyi önerirse, bugünlerde “mikro” olarak adlandırmaya başlayacağımı önereceğim şeyler.

Genellikle dal tahmini için optimizasyon yapmaya çalışmak, algoritma veya hafıza verimliliğinde bir değişiklik gerektirir. Örneğin, bu yalnızca statik tahmin için ipuçları ve yeniden düzenleme kodu ile deneniyorsa, bu tür kodların yalnızca ilk kez uygulanmasını geliştirmeye meyilliyse, etkilerini sorgulanabilir hale getirir. Genellikle düpedüz ihmal edilemez.

Performans İçin Çok Okunmaya Geri Dön

Her neyse, performans bağlamında çok okuyuculuk ne kadar önemli? 4 çekirdekli makinemde ideal olarak 5 kat daha hızlı işler yapabilir (hiper-okudum ile ne alabilirim). 32 çekirdeği olan meslektaşım için çok daha önemli olurdu. Ve önümüzdeki yıllarda giderek daha önemli hale gelecektir.

Bu yüzden oldukça önemli. Fakat eğer hafıza verimliliği kilitlerin korunmasına izin vermek, yanlış paylaşımları azaltmak, vb.

Performans Dışında Çok Okumak

Çok iş parçacığı her zaman basit bir verim türü anlamda saf performansla ilgili değildir. Bazen, kullanıcının yanıt verebilirliğini artırmak için olası bir işlem maliyetinde bile bir yükü dengelemek veya kullanıcının işleri bitirmesini beklemeden daha fazla çoklu görev yapmasına izin vermek için kullanılır (ör: dosya indirirken göz atmaya devam et).

Bu gibi durumlarda, okuyucunun en üst seviyeye (belki de bellek verimliliğinin üstünde bile) yükseldiğini, çünkü donanımdan en iyi şekilde yararlanmaktan ziyade kullanıcı-uç tasarımla ilgili olduğunu düşünüyorum. Arayüz tasarımlarına ve tüm kod tabanımızı bu tür senaryolarda yapılandırma şeklimize sık sık hakim olacak.

Çok büyük bir veri yapısına erişen sıkı bir döngüyü basit bir şekilde paralel hale getirmediğimizde, çoklu okuma gerçekten zorlu "tasarım" kategorisine gider ve tasarım her zaman uygulamanın önüne geçer.

Bu yüzden, bu gibi durumlarda, açık okuyucuyu baştan sona okumayı düşünmek kesinlikle kritik, hatta bellek gösterimi ve erişimden daha önemli.

Eşzamanlı ve paralel programlama önemli hale gelir. Konular aynı anda birden fazla şey yapmanın sadece bir programlama modelidir (çok çekirdekli işlemcilerin yükselişinden önceki haliyle sözde paralel değil). Çoklu iş parçacığı (IMHO adil) karmaşık ve tehlikeli olduğu için eleştirilir, çünkü iş parçacıkları birçok kaynağı paylaşır ve programcı onları işbirliği yapmaktan sorumludur. Aksi halde, hata ayıklaması zor olan kilitlenme ile sonuçlanırsınız.

Birçok harici uygulamaya başvurmamız gerekebileceği için, harici sistem etkileşiminin daha fazla zaman aldığı ve son kullanıcının işlem tamamlanana kadar bekleyemeyeceği bazı arka plan işlemleri olabilir. çok okuyuculuk önemlidir ..

Bizim uygulamada kullanıyoruz, önce kapalıysa harici sistemle bağlantı kurmaya çalışırız, sonra isteği Veritabanına kaydederiz ve işlemi artalanda bitirmek için bir iş parçacığını kullanırız. Toplu işlemlerde de gerekli olabilir.

Tarihsel olarak insanlar elle okuyuculu programlama yaparak mücadele etmek zorunda kaldılar. Doğrudan tüm ana bileşenlerle (dişler, semaforlar, muteksler, kilitler vb.) Çalışmak zorunda kaldılar.

Tüm bu çabalar, tek bir sisteme ek cpus ekleyerek ölçeklenebilen uygulamalarla sonuçlandı. Bu dikey ölçeklenebilirlik, "satın alabileceğim en büyük sunucu nedir?" İle sınırlıdır.

Günümüzde yazılım tasarımı için daha fazla çerçeve ve farklı tasarım modelleri kullanmaya doğru bir kayma görüyorum. MapReduce, toplu işlemeye odaklanan böyle bir modeldir.

Hedef yatay olarak ölçekleniyor. Daha büyük sunucular satın almak yerine daha fazla standart sunucu ekleme.

Bununla birlikte, çok iş parçacıklı programlamanın gerçekten anlaşılmasının çok önemli olduğu söyleniyor. Birinin bir yarış durumu yarattığı ve test sırasında garip hatalar fark edinceye kadar bir yarış şartının ne olduğunu bile bilmiyordum.

Makinemin 8 çekirdeği var. Görev Yöneticisi'nde çalışan 60 işlem var. Bazıları VS gibi, 98 dişe kadar kullanırlar. Outlook 26 kullanır. Hafıza kullanımımın çoğunun bu boş iş parçacıklarının her birine ayrılan yığınlar olmasını bekliyorum.

Kişisel olarak 300 çekirdekli bilgisayarın çıkmasını bekliyorum, böylece Outlook'un yanıt vermesini beklememe gerek kalmadı. Elbette o zamana kadar Outlook 301 konu kullanacak.

Çoklu iş parçacığı yalnızca, belirli bir zamanda bilgisayardaki tek önemli işlem olacak sistemler oluşturuyorsanız önemlidir (örneğin hesaplama motorları). Masaüstü uygulamaları muhtemelen tarafından kullanıcıya iyilik yapacağını değil mevcut her çekirdeğini kullanarak. İstek / yanıt modelini kullanan web uygulamaları doğal olarak çok iş parçacıklıdır.

Çerçeve ve dil tasarımcıları ve arka uç sistemler programcıları için önemlidir - uygulama geliştiriciler için çok fazla değildir. Asenkron kodun kilitlenmesi ve yazılması gibi bazı temel kavramların anlaşılması yine de faydalı olabilir.