Kodumun gelecekteki petascale makinelerinde çalışmasını istersem, hangi programlama paradigmalarına yatırım yapmalıyım?

Sektörün, çekirdeklerin işlenmesinde katlanarak artmaya yöneldiği ilk 500 anketinden açıkça anlaşılıyor . En büyük süper bilgisayarlar, düğümler arası iletişim için MPI kullanır, ancak düğümler arası paralellik için net bir eğilim olmadığı görülmekle birlikte, her bir çekirdeğe tek bir MPI işlemini eşleştirmenin en basit (ancak en verimli olanı değil) yaklaşımı ile birlikte derleyici, OpenMP, pthreads, CUDA, Cilk ve OpenCL'den paralelleştirme.

Dünyadaki en büyük süper bilgisayarların bazılarında kullanılma potansiyeli olan bir kodu koruyan ve geliştiren bir grup bilim insanından biriyim. Sınırlı geliştirici zamanı varsayarsak, dünyanın en güçlü makinesinin performansından yararlanabilmem için kendimi geleceğe nasıl koruyabilirim? Süreç bağlantı mimarisi hakkında ne gibi varsayımlar yapmalıyım? Çok sayıdaki çağa girerken hangi paradigmalar acı çekecek? Bölümlenmiş Global Adres Alanı dilleri petascale makinelerinde "üretimde" mevcut olacak mı?

Tarihi bakış açısı

Gelecekte yeni paradigmaların nasıl olacağını söylemek gerçekten imkansız, örneğin Ken Kennedy'nin HPF'in Yükselişini ve Düşüşünü okumayı önerdiğim iyi bir tarihsel bakış açısı . Kennedy, ortaya çıkan iki örüntüyü (MPI ile akıllı bir derleyiciye karşı) hesaplar ve MPI'nin ilk dönemdeki benimseyenlere nasıl doğru miktarda sahip olduğunu ve hakim olma esnekliğini gösterir. HPF sonunda sorunlarını çözdü, ancak çok geçti.

Birçok yönden, PGAS ve OpenMP gibi bazı paradigmalar aynı HPF eğilimini izliyor. İlk kodlar iyi kullanacak kadar esnek değildi ve masaya çok fazla performans bıraktılar. Ancak, paralel algoritmanın her iotasını yazmak zorunda kalmama sözü cazip bir amaçtır. Böylece yeni modellerin arayışı her zaman takip ediliyor.

Donanımdaki Eğilimleri Temizle

Şimdi, MPI’nın başarısı, sıklıkla, üzerinde çalıştığı donanımı nasıl modellediğiyle yakından ilişkili olarak gösterildi. Kabaca her düğüm birkaç işleme sahiptir ve mesajları yerel noktadan noktaya veya koordineli toplu işlemler yoluyla geçirmek küme alanında kolayca yapılır. Bu nedenle, yeni donanım trendlerini yakından takip etmeyen bir paradigma veren kimseye güvenmiyorum, aslında Vivak Sarakar'ın çalışmasıyla bu fikre ikna oldum .

Bu doğrultuda, yeni mimarilerde açıkça öne çıkan üç eğilim var. Ve açık olalım , HPC'de pazarlanan on iki farklı mimarlık var. Bu, 5 yıldan daha kısa bir süre önce yalnızca x86 özelliğine sahip olduğundan, önümüzdeki günlerde donanımı farklı ve ilginç şekillerde kullanmak için birçok fırsat göreceksiniz.

• Özel Amaçlı Çipler: Hızlandırıcılar gibi büyük vektör birimlerini düşünün (görünüm, Bill Dally of Nvidia tarafından desteklendi)
• Düşük Güç Chips: ARM tabanlı kümeler (güç bütçelerini karşılamak için)
• Cips Döşeme: farklı özelliklere sahip cips döşemeyi düşünün ( Avant Argwal çalışması )

Mevcut Modeller

Mevcut model aslında 3 seviye derinliğinde. Bu seviyelerden ikisini iyi kullanan pek çok kod varken, her üçünü de kullanan pek bir şey yok. Öncelikle exascale almak için kodun her üç seviyede de çalışıp çalışamayacağına karar vermek için yatırım yapması gerektiğine inanıyorum. Bu muhtemelen şu anki trendlerle iyi bir şekilde yinelemenin en güvenli yoludur.

Tahmin edilen yeni donanım görüşlerine dayanarak modelleri ve bunların nasıl değişmesi gerektiğini yineleyeyim.

Dağıtılmış

Dağıtılmış seviyedeki oyuncular büyük ölçüde MPI ve PGAS dillerine ayrılır. MPI şu anda açık bir kazanan, ancak UPC ve Chapel gibi PGAS dilleri uzaya doğru ilerliyor. İyi bir gösterge HPC Benchmark Challenge'dır. PGAS dilleri kıyaslamaların çok şık uygulamalarını veriyor.

Buradaki en ilginç nokta, bu modelin şu anda yalnızca düğüm düzeyinde çalışmasına karşın, Döşeme mimarileri için bir düğüm içinde önemli bir model olacağıdır. Bunun bir göstergesi, temelde dağıtılmış bir sistem gibi davranan Intel SCC yongasıdır. SCC ekibi kendi MPI uygulamasını oluşturdu ve birçok takım topluluk kütüphanelerini bu mimariye aktarmada başarılı oldu.

Ancak dürüst olmak gerekirse, PGAS'ın gerçekten bu alana adım atmak için iyi bir hikayesi var. Gerçekten MPI internode programlamak ve aynı hile intranode yapmak zorunda mısın? Bu çinili mimarilerle ilgili büyük bir sorun, çiplerde farklı saat hızlarına sahip olacakları ve hafızadaki bant genişliğindeki önemli farklılıklar olacağıdır; bu nedenle performans kodları bunu göz önünde bulundurmalıdır.

Düğümde paylaşılan hafıza

Burada MPI'nın genellikle "yeterince iyi" olduğunu görüyoruz, ancak PThreads (ve Intel Parallel Building Blocks gibi PThreads'ten türetilen kütüphaneler) ve OpenMP hala sıkça kullanılıyor. Yaygın görüş, MPI'nin soket modelinin RPC için parçalanacağı ya da çekirdekte çalışan daha hafif bir ağırlık işlemine ihtiyaç duyacağınız yeterli paylaşılan bellek parçasının olduğu bir zaman olacağı yönündedir. Zaten paylaşılan bellek MPI'si ile ilgili problemleri olan IBM Bluegene sistemlerinin göstergelerini görebilirsiniz.

Matt'in belirttiği gibi, hesaplama yoğun kodları için en büyük performans artışı, seri kodun vektörleştirilmesidir. Birçok kişi bunun hızlandırıcılarda doğru olduğunu varsaysa da, düğüm makineleri için de çok önemlidir. Westmere’in 4 geniş bir FPU’ya sahip olduğuna inanıyorum, böylece bir tanesi vektörleşmeden sadece dörtte birini alabiliyor.

Mevcut OpenMP'nin bu alana iyi adım attığını görmeme rağmen, düşük güçlü veya fayans çiplerinin daha fazla hafif iplik kullanabileceği bir yer var. OpenMP, veri akışının nasıl çalıştığını tarif etmekte zorlanıyor ve daha fazla iş parçacığı kullanıldığında, sadece bu eğilimin daha abartılı olduğunu görüyorum, sadece OpenMP ile uygun ön hazırlık yapmak için ne yapılması gerektiğinin örneklerine bakıyorum.

Hem OpenMP hem de PThreads yeterli seviyede, iyi bir zirve yüzdesi elde etmek için gerekli olan vektörleştirmeden faydalanabilir, ancak bunu yapmak için algoritmalarınızı vektörelleşmenin doğal olduğu bir şekilde yıkmak gerekir.

Co-processor

Sonunda ortak işlemcinin (GPU, MIC, Cell acclerators) ortaya çıkması bekledi. Exascale'e giden hiçbir yolun onlarsız tamamlanamayacağı açıkça ortaya çıkıyor. SC11'de, her Bell ödül yarışması, düşük petaflops'a ulaşmak için onları etkin bir şekilde kullandı. CUDA ve OpenCL mevcut pazara hükmediyor olsa da, OpenACC ve PGAS derleyicilerinin bu alana girmesini umuyorum.

Şimdi exascale'e ulaşmak için, bir öneri, düşük güçte çalışan çipleri birçok ortak işlemciye bağlamaktır. Bu, mevcut yığının orta katmanını ortadan kaldıracak ve ana çip üzerindeki karar sorunlarını yöneten kodları kullanacak ve ortak işlemcilere işten ayrılacak. Bu, kodun oldukça etkili bir şekilde çalışması için kişinin algoritmaları, dalsız komut düzeyinde paralel snippet olan çekirdekler (veya codelets) açısından yeniden düşünmesi gerektiği anlamına gelir. Bildiğim kadarıyla, bu evrim için bir çözüm oldukça açık.

Bu uygulama geliştiricisini nasıl etkiler?

Şimdi soruna ulaşmak için. Kendinizi exascale makinelerinin gelecekteki karmaşıklıklarından korumak istiyorsanız, birkaç şey yapmalısınız:

• Algoritmalarınızı en az üç paralel hiyerarşi seviyesine uyacak şekilde geliştirin.
• Algoritmalarınızı heirarşi arasında hareket ettirilebilecek çekirdekler cinsinden tasarlayın.
• Sıralı işlemlere olan ihtiyacınızı gevşetin, tüm bu efektler eşzamansız olarak gerçekleşir, çünkü eşzamanlı yürütme mümkün değildir.

Bugün performans göstermek istiyorsanız, MPI + CUDA / OpenCL yeterince iyi ancak UPC oraya gidiyor, bu yüzden birkaç gün alıp öğrenmek kötü bir fikir değil. OpenMP sizi başlatır ancak kodun yeniden yapılandırılması gerektiğinde sorunlara yol açar. PThreads kodunuzu tamamen kendi stilinize göre yeniden yazmanızı gerektirir. Bu da MPI + CUDA / OpenCL'i mevcut en iyi model yapıyor.

Burada tartışılmaz ne

Tüm bu exascale konuşması güzel olsa da, burada gerçekten tartışılmayan bir şey, makinelere veri girip çıkarıyor. Bellek sistemlerinde pek çok gelişme olmasına rağmen, onları meta kümesinde görmüyoruz (sadece çok pahalı). Artık veri yoğun hesaplama, tüm süper hesaplama konferanslarının büyük bir odağı haline geliyor, yüksek bellek bant genişliği alanına daha büyük bir hareket olması gerekiyor.

Bu da gerçekleşebilecek olan diğer eğilimi de beraberinde getirmektedir (eğer doğru finansman kuruluşları devreye girerse). Makineler, gerekli bilgi işlem türü için daha da uzmanlaşacaktır. NSF tarafından finanse edilen "veri yoğun" makinelerin zaten görüyoruz, ancak bu makineler 2019 Exascale Grand Challenge'dan farklı bir yolda.

Bu beklenenden uzun oldu, yorumlarda onlara ihtiyaç duyduğunuz referansları isteyin

Intranode kodu (ara bağlantıya değmeyen hesaplama) stratejisini tartışarak başlayalım, çünkü MPI'nin internode kodu için iyi bir seçim olduğunu düşünüyorum. 100 çekirdeğin altındaki düğümlerden bahsetmenin anlamsız olduğunu düşünüyorum, yani en azından şu anki bir GPU veya MIC.

Tek başına kalanlar, herhangi bir modern çipte maksimum performans elde edemezler çünkü vektör ünitesinden (ilk Cray'den beri geçerli) faydalanmalısınız. Intel ve AMD'de içsel kullanabilirsiniz, ancak bunlar taşınabilir değildir ve bence clunky. CUDA ve OpenCL kütüphanede yerleşik bir vektörleşmeye sahiptir ve maksimum performans elde etmeyi kolaylaştırır. Bildiğim tüm yeni donanımların bu vektör gereksinimi vardır, bu nedenle herhangi bir çözüm bunu dikkate almalıdır. Benim için, CUDA / OpenCL geçerli yoldur.

Daha sonra, tüm bu makineler programlanması daha zor olan NUMA olacaktır, ancak çekirdek stratejisinin işe yaradığını düşünüyorum. İşi ve verileri küçük birimlere böldün. Bunlar muhtemelen şu anda CUDA ve OpenCL'de olduğu gibi otomatik olarak planlanacaktır, ancak bağımlılıkları belirleyebilirsiniz. Akış paradigmasına uyan sorunlar için bu yığın otomatik olarak da yapılabilir. Intel TBB bunu yapıyor, ancak CUDA veya (yakında) TBB'yi hedef alabilen Thrust ve Cusp tarafından örneklenen üst düzey kütüphane yaklaşımını tercih ediyorum .

Bu konuda bazı değerli meslektaşlarımdan daha kısa bir cevap deneyeceğim ;-)

Tüm öğrencilerime mesajım, geliştirici zamanının CPU zamanından daha değerli olduğu yönündedir. Bu, büyük makinelerde çalıştırmak için (% 100 verimlilikle kodun% 100'ünü dönüştürmek için zamanınız varsa - yüksek seviye bir yaklaşım kullanarak), zaman harcayan bir düşük seviye kullandığınızdan daha iyi durumda olursunuz demektir. Kodunuzun% 20'sinde size% 100 verimlilik sağlayan bir yaklaşım. Sonuç olarak, üst düzey kütüphanelerin büyük bir hayranıyım. Bu alandaki en sevdiğim iş parçacığı yapı taşları (TBB) çünkü algoritmalar en dıştaki döngülerde ve yüksek seviyede bakmamı sağlıyor. Ayrıca, işletim sistemi işlevleriyle uğraşmak zorunda kalmadan pthreads ile yapmak isteyebileceğiniz her şeyi yapabilir. En içteki döngülere bakan yaklaşımların hayranı değilim çünkü bu, intranode paralel kaynakları kullanmak için yanlış bir seviyedir - - yani OpenMP yok,

OpenCL, CUDA, vs. hakkında otorite ile konuşamam.

Daha önce yayınlanan cevaplar mükemmel ama MPI genellikle boğum programlama modelleri olarak yeterli görülmektedir gerçeğini yansıtır düşünüyorum düğüm mimarisi, çoğunlukla odaklanmıştır çoğu durumda ve biz mücadele intranode paralellik olduğunu.

İşte henüz cevaplanmayan veya nispeten sınırlı bir şekilde cevaplanmayan iki soruyu cevaplama girişimlerim:

İşlemler arası bağlantı mimarisi hakkında ne gibi varsayımlar yapmalıyım?

Ağların üç özelliğini göz önünde bulunduracağım:

1. gecikme
2. bant genişliği ve
3. eşzamanlılık.

Gecikme, frekans ile ters orantılıdır. Frekans ölçeklendirmenin durduğunu biliyoruz. Bu nedenle, gecikmenin gelecekte önemli ölçüde düşme ihtimalinin olmadığı sonucuna varılabilir. Blue Gene / Q üzerindeki MPI gönderme-geri alma gecikmesi yaklaşık 2 ABD'dir, bu 3200 çevrime karşılık gelir. Bu gecikmenin yarısından fazlası yazılımdır, ancak MPI standardı için bunun iyi bir kısmı gerekir; Kapsamlı ayarlama, özellikle MPI joker karakterlerinin kullanılmayacağını öne sürdüğü takdirde gecikme süresini 1 bize yaklaştırabilir.

Her durumda, Blue Gene ve Cray sistemlerinde paket enjeksiyonu için donanım gecikmesi yaklaşık 1 ABD'dir. Herhangi bir şey olursa, düğüm düzeyinde eşzamanlılık artışı, bu sayının bu kadar düşük tutulmasını zorlaştırır, ancak donanım tasarımcılarının öngörülebilir gelecek için gecikmeyi 5'in altında tutmanın yollarını bulacağı konusunda iyimserim.

Ağ bant genişliği arttıkça ağ bant genişliği önemsiz şekilde artar. Ancak bu, hikayenin sadece bir kısmı. Bir tanesi bir düğüm üzerine 1000 giden bağlantı koydu ve eğer işlemci (ler) ağı tam bant genişliğinde süremiyorsa kullanamazlar. Örneğin, bazı süperbilgisayarlar, enjeksiyon bant genişliği bakımından ağda değil, veriyolunda (örn. HyperTransport) darboğaz.

Ağ bant genişliği için temel sınır yoktur, sadece pratik sınırlar vardır. Bant genişliği para ve güç maliyeti. Sistem tasarımcılarının gelecekteki sistemler geliştirilirken ağ bant genişliği ve makinenin diğer parçaları arasındaki değişimleri hesaba katmaları gerekecektir. Pek çok kod ağ bant genişliği sınırlı değildir, bu nedenle gelecekte bağlantı başına bant genişliği daha önemli olan makineleri görmemiz muhtemel görünmektedir. Bununla birlikte, düğüm başına bant genişliği, hesaplama gücüyle orantılı olarak artmalı, böylece ölçek büyütmek için düğüm başına çoklu bağlantıların olması gerekir.

Resmi modellerde sıklıkla göz ardı edilen ağların üçüncü özelliği, bir seferde kaç mesaj gönderilebileceğidir. Bir seferde sadece 1 mesaj gönderebilen 1 ns gecikmeli ve / veya 1 TB / s bant genişliğine sahip bir ağa sahip olmak çoğu kullanım için tamamen yararsızdır. Aynı anda birçok iş parçacığından çok sayıda ileti gönderebilmek ve ağın çekişme halinde çökmemesi önemlidir. Hem Cray hem de Blue Gene sistemleri şimdi 1 MMPS'den (saniyede milyon mesaj) fazladır. Kesin sayıları hatırlayamıyorum, ancak her ikisi de küçük mesajlarla tepe bant genişliğinin önemli bir kısmını elde edebiliyor. İdeal bir ağ, herhangi bir boyuttaki mesajla en yüksek bant genişliğine ulaşabilir, ancak bu, paket başlığı ve ilgili defter tutma giderleri nedeniyle pratikte mümkün değildir. Ancak,

Bu eksik ve eksik bir cevaptır. Diğerleri onu iyileştirmeye veya geliştirmem gereken şeyleri önermeye çalışırlar.

Bölümlenmiş Global Adres Alanı dilleri petascale makinelerinde "üretimde" mevcut olacak mı?

Cray XE, XK ve XC sistemleri, üretim kalitesinde bir UPC ve CAF derleyicisine sahiptir. Blue Gene sistemleri XLUPC ve XLCAF ile sağlanabilir, ancak kimse bunu istemez, bu yüzden teslim edilmez. PERCS, XLUPC ve XLCAF derleyicilerinde üretim sınıfına sahiptir ancak bilimsel topluluğun erişebileceği büyük ölçekli kurulumlara sahip değildir.

Coarrays, Fortran 2008'in bir parçası olmasına rağmen, Intel ve GNU Fortran'daki uygulamalar henüz yüksek kalitede değildi. Intel uygulamasının işe yaradığı söyleniyor ancak oldukça yavaş çalışıyor (PGAS12'de bununla ilgili bir makale var).

PGAS programlama modeline gelince (programlama modelleri - programlama dilleri değil - orijinal sorunun konusu olduğundan), Global Diziler kütüphanesi çoğu durumda üretim kalitesine makul bir yaklaşımdır. Bir çalışma zamanı olarak, MPI kadar sağlam değildir, ancak MPI uygulamaların kalitesi açısından oldukça benzersizdir. ARMCI'nin ARMCI-MPI uygulaması, Global Dizileri, bazı durumlarda daha yavaş da olsa, çok daha istikrarlı kılmaktadır.

PGAS tarzı yapıları MPI-3 RMA kullanarak üretim kalitesinde uygulamak oldukça kolaydır. Birisi bu konuda yeni bir soru gönderirse, cevap vermekten mutlu olurum.

Gerçekten çok büyük miktarlardaki çekirdekler de önemsiz fakat şaşırtıcı derecede faydalı bir bakış açısı açar - sadece bütün simülasyonun birçok tekrarını çalıştırmak için kullanmak.

Hesaplamalı araştırmanın önemli bir kısmı bugünlerde bazı parametre alanlarını taramaya, büyük başlangıç ​​koşulları havuzunu taramaya ya da bazı sonuçların dağılımını yeniden örnekleme şeklinde hesaplamaya; Tüm bu görevler utanç verici bir şekilde paraleldir, bu nedenle Amdahl geçirmez.

Bu sorunun en iyi düşünülmüş cevaplarının bile beş ila on yıl içinde kullanılmayacağından şüpheleniyorum. Gelecekteki programlama paradigmalarının belirsizliği göz önüne alındığında, kod tabanınızı önceden optimize etmek için çok fazla zaman harcamak faydalı olmayabilir.

Ben sadece bu soruyu bu soruya göndermek üzereydim , ama bunun bir kopyası olarak kapatıldı, işte şöyle:

Bu biraz Solomonic gelebilir, ama benim deneyimlerime göre, gelecek çok parçacıklı çekirdeği çalıştıran çok paylaşımlı bellek çok çekirdekli düğümlerin MPI gibi dağıtılmış bellek paradigmasıyla bağlandığı karma yaklaşımlara aittir .

Bununla birlikte, birkaç problem vardır ve bunlar hiç donanımı içermemektedir. Her şeyden önce, çoğu paralel programcılar MPI tipi kodlara yoğun bir şekilde yatırım yapar ve kod parazitlerinin parçalarını veya tümünü, yeni bir paradigma kullanarak yeniden uygulayan ilk kişi olmak için çok isteksizdir. Paylaşılan bellek yaklaşımlarını kullanan kişilerin eksikliği, o alan için algoritmalarda daha yavaş ilerlemeye neden olur ve bu da herhangi bir yatırımın daha da anlamsız görünmesini sağlar.

İkinci bir problem ise herkesin paylaşılan hafıza paralelliğini OpenMP ile ilişkilendirmesidir . OpenMP, az sayıdaki işlemcideki küçük, basit sorunları çözmenin güzel ve hızlı ve kirli bir yolu olsa da, gerçek paylaşılan bellek paralelliğine yönelik kesinlikle korkunç bir programlama modeli . Hepimiz bir noktada veya başka bir yerde öğrenmiş olsak da, örneğin Thread havuzları veya Zamanlayıcılar gibi bir dizi basit ve verimli paralel programlama paradigması öğrenmiş olsak da , bunların OpenMP kullanarak uygulanması kolay değildir ve açıkçası bu, bu tür paralelliğin türü değildir. OpenMP, programcıların kullanmasını sağlar.

Özetle, tamamen dağınık bellekten, tamamen / kısmen paylaşılan bellek paradigmasına geçme engeli oldukça yüksektir. Eğer konuları verimli bir şekilde kullanmak istiyorsanız, OpenMP'yi unutmalı ve konuları yönetmeli ve eşzamanlılığı kendiniz yönetmelisiniz (merhaba pthreads , elveda Fortran).

Ama neden hiç bir hibrid yaklaşıma geçelim? Her ne kadar MPI binlerce çekirdeğe ölçeklense de, altta yatan model kilit adımlı senkronizasyon ve statik iletişim modellerinden biridir. Bu, milyarlarca parçacık simülasyonu gibi bazı problemler için iyidir, fakat daha zor veya daha hassas taneli problemler için idealdir. Paylaşılan bellek paradigmaları dinamik yük dengelemesini ve / veya asenkronize iletişimi çok daha kolay hale getirir, ancak bunu yapmak büyük bir programlama çabası gerektirir.