Yüksek Performanslı Hesaplamanın Sanatı

 (theartofhpc.com)
3 puan yazan GN⁺ 2023-12-31 | 1 yorum | WhatsApp'ta paylaş
  • The Art of HPC, TACC’den Victor Eijkhout tarafından hazırlanan, yüksek performanslı hesaplama ders kitapları serisidir; bilimsel hesaplamanın temellerinden paralel programlama ve geliştirme araçlarına kadar konuları tek bir akışta birleştirir
  • İlk cilt, bilgisayar mimarisi, aritmetik, doğrusal cebir ve ODE/PDE’nin büyük ölçekli hesaplamalarda nasıl iç içe geçtiğini ele alan bir bilimsel hesaplama arka plan kitabıdır
  • İkinci cilt, MPI ve OpenMP merkezinde paralel programlamayı açıklar; PETSc, Kokkos, Sycl ve Co-array Fortran’a da kısaca yer verir
  • Üçüncü cilt, bilimsel ve mühendislik programlamasında kullanılan C++17 ve Fortran2008’i ele alır; hem yeni başlayanlar hem de C programcıları için okunabilir
  • Dördüncü cilt, derleyiciler, derleme sistemleri ve kaynak kod yönetimi gibi gerçek HPC işleri için gerekli geliştirme iş akışı araçlarını tanıtır

The Art of HPC ders kitaplarının yapısı

  • The Art of HPC, TACC’den Victor Eijkhout tarafından hazırlanan yüksek performanslı hesaplama ders kitapları serisidir
  • Seri; bilimsel hesaplama arka planı, paralel programlama, bilimsel programlama dilleri ve HPC geliştirme ekosistemini ciltlere ayırarak ele alır

Ciltlere göre kapsam

  • Volume 1: The Science of Computing

    • Bilimsel hesaplamayı anlamak için gereken genel arka plan bilgisini ele alır
    • Bilgisayar mimarisi, paralel bilgisayar mimarisi, bilgisayar aritmetiği, doğrusal cebir ve ODE/PDE’yi içerir
    • Her öğenin büyük ölçekli hesaplamalarda nasıl birleştiğini açıklar; Volume 2 ile birlikte HPC’nin “ne/neden” ve “nasıl” yönlerini oluşturan yapıdır

  • Volume 2: Parallel Programming for Science and Engineering

    • Bilimsel hesaplamada önemli olan paralel programlamayı ele alan cilttir
    • Modern MPI ve OpenMP sürümlerini merkeze alarak tanıtır
    • PETSc, Kokkos, Sycl ve Co-array Fortran hakkında kısa bölümler de içerir
    • MPI ve OpenMP, C, Fortran ve C++ ile ele alınır; MPI ayrıca Python’ı da içerir

  • Volume 3: Introduction to Scientific Programming

    • Bilimsel ve mühendislik programlamasında yaygın kullanılan C/C++ ve Fortran arka planıyla, modern C++17 ve Fortran2008’i öğretir
    • C’ye kıyasla C++17’yi tercih eden bir yaklaşım benimser
    • Sıfırdan öğrenenler için bilimsel programlamaya giriş kitabı olarak da, C programcıları için C++ öğrenme kitabı olarak da okunabilir
    • Birden fazla uzun programlama projesi içerir

  • Volume 4: HPC Carpentry

    • Bilimsel hesaplama ekosisteminin yalnızca programlama dilleri ve paralel programlama sistemlerinden oluşmadığı noktasına odaklanır
    • Derleyiciler, derleme sistemleri ve kaynak kod yönetimi gibi bilimsel iş akışı için gerekli öğeleri tanıtır
    • Her şeyi kapsayan bir başvuru kitabından çok, bilimsel iş akışına göre hazırlanmış bir giriş derlemesine yakındır

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-31
Hacker News yorumları

  • Bu konunun donanım/veri merkezi tarafı da en az onun kadar ilginç
    Eskiden AWS’te yazılım/servis tarafında çalışıyordum; ara sıra veri merkezi ekibinin sunumlarını gizlice dinlemeye giderdim
    En büyük farkındalığım, veri merkezlerinde işlem gücünü artırmanın gerçek anlamda bilişimden çok bir termodinamik problemi olduğuydu. Düğüm yoğunluğu o kadar artıyor ki, enerjiyi içeri verip ısıyı dışarı atmak, üstüne bir de çeşitli yedeklilik katmanları eklemek son derece zorlaşıyor. Bir verimsizlik bulsanız bile bunu bir yazılım güncellemesi gibi düzeltemiyorsunuz
    Bu yaklaşık 10 yıl önceydi, dolayısıyla bugün bazı şeyler değişmiş olabilir; ama bir internet kitapçısı olarak başlayan Amazon’un termodinamik problemleri çözmenin en ön cephesinde yer alması şaşırtıcı

    • Seymour Cray daha 1970’lerde en büyük sorunun ısı dağıtımı olduğunu söylemişti
      Cray-2’de daha da uç bir yöntem seçilmişti: sık dizilmiş devre kartı yığınlarını Fluorinert™ adlı özel, iletken olmayan bir sıvıya daldıran bir soğutma yapısı kullanılıyordu: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
    • Veri merkezlerinde sıvı soğutmanın neden daha yaygın kullanılmadığını hep merak etmişimdir
      Suyun ısı kapasitesi çok yüksektir ve büyük miktarda ısıyı optimum sıcaklığa hızla soğutabilir. Sıvı soğutmaya uygun olmayan bileşenlerin ısısını uzaklaştırmak için fanlara ve klimalara hâlâ ihtiyaç olurdu; ancak CPU veya GPU/hesaplama motoru gibi yüksek güç tüketen büyük bileşenlerde muazzam miktarda ısıyı hızlı ve doğrudan uzaklaştırabilir
      Sızıntıların karmaşıklığı ve riski elbette bir sorun olurdu, ama Amazon ölçeğindeki veri merkezleri için bunun o kadar büyük bir endişe kaynağı olmayacağını düşünüyorum
    • Bu problemin ölçeğini gösteren iyi veriler veya görselleştirmeler var mı?
      En gelişmiş soğutma teknolojisinin nasıl göründüğünü merak ediyorum

  • HPC’nin donanımdan epey soyutlanmış göründüğü zamanlar ilginç geliyor
    Kitaplar SPMD programlama, algoritmalar ve veri yapıları, görev paralelliği, senkronizasyon gibi konuları çok ele alıyor gibi; ama süper bilgisayar bellek alt sistemleri, CXL gibi yüksek bant genişlikli ara bağlantılar, GPU mimarisi gibi bilgisayar mimarisi ayrıntıları az görünüyor
    Soyutlamalar ve araçlar zaten bu ayrıntıları dert etmeye gerek bırakmayacak kadar iyi mi, yoksa HPC pratisyenleri performansı çıkarmak için kara kutu ayar düğmeleriyle çok mu oynuyor, merak ediyorum

    • HPC’nin çoğunda donanım mimarisini ve çalışma biçimini derinlemesine anlamadan paralelliği ve iş hacmini en üst düzeye çıkarmak mümkün değil
      Genel ilke olarak, en iyi ölçeklenebilirlik için yazılımın topolojisi donanımın topolojisiyle mümkün olduğunca örtüşmeli. Verimli HPC yazılımı, donanım özelliklerinden güçlü biçimde etkilenir
      Yeni HPC donanımı için kod yazarken programlama belgeleri değil de sistem donanımı ve mimari belgelerini istediğimde insanlar her zaman şaşırırdı. Donanım tasarımını anlayınca, onun üzerinde yazılımın nasıl tasarlanması gerektiği ilk ilkelerden açık hâle geliyordu. Programlama belgelerinde, geliştiriciye işleri gerçekte olduğundan daha kolay göstermek için epey yarım doğru vardı
      Bazı HPC platformları “kullanımı kolay” görünmek uğruna, en yüksek performansa ulaşmak için geliştiricinin ne yapması gerektiğini sürekli yanlış aktardı; pazarlamanın ima ettiği şekilde yazılım yazıldığında da silikonun sağlayabileceği performans alınamadığı için büyük başarısızlıklar yaşandı
      HPC kodu soyutlamalar üzerinde yazılabilir ve pratikte birçok kişi öyle yapar; ancak performans ve ölçeklenebilirlik kaybı çoğu zaman kaçınılmaz, tam sayı katları düzeyinde olur. Diğer yazılımlarda olduğu gibi, daha az deneyimli bir geliştiricinin kodu tasarlayabilmesini sağlıyorsa bu kayıplar çoğu zaman kabul edilebilir bulunurdu
      HPC de diğer yazılımlar gibi; unvan olarak profesyonel geliştirici olsa bile, istikrarlı biçimde iyi sonuçlar üretmekte zorlanan çok kişi var. HPC’de kullanılan pahalı donanımların kayda değer bir kısmı, kötü yazılım tasarımından doğan performans kaybını hafifletmek için var
      En yüksek performansı istiyorsanız, donanımın gerçekte nasıl çalıştığını anlamaktan başka kestirme yol yok. Genel yazılımdan farklı değil; HPC’de sadece donanım sistemi daha büyük ve karmaşık
    • Fortune 100 şirketlerinden birinde yaklaşık 500 düğümlü bir kümede iki yıl kadar önce HPC işine başladım. Aslında %100 Linux yapacağım bir iş arıyordum ve şimdiye kadar eğlenceli geçti
      Ama beklediğimden farklı çıktı. Daha çok performans odaklı iş yapacağımı, sayıları analiz edip kümeden son performans kırıntısını da sıkıp çıkaracağımı sanıyordum. Açıkçası başta izleme bile yoktu. Kendim kurdum ama neredeyse hiç kullanılmıyor. Arada yönetim, bütçeyi gerekçelendirmek gibi nedenlerle “küme ne kadar yoğun?” diye soruyor
      ‘Optimizasyon’un çoğu, insanların betikleri yalnızca 16 CPU kullanırken 384 CPU istemediğini kontrol etmek ya da belirli bir yazılımın performans düşüşü olmadan kaç CPU’ya kadar çalıştığını test etmek gibi şeyler. Intel profil aracını tam iki kez açtım
      İşin büyük kısmı araştırmacıların işlerini yürütmesine yardım etmeye daha yakın. Genelde ticari veya açık kaynak programları çalıştırıp sorun gideriyoruz ya da başka bir ekibin başka bir kümede yazdığı kodu alıp bizim kümede derlenip çalışır hâle getiriyoruz. Berbat Python kodlarını kurcalıyor, daha modern bir kümeden CentOS 7 ortamına C++ projeleri derlemeye uğraşıyorum
      Kendi içinde eğlenceli. Birçok dille çalıştığım için bir şeyleri çalışır hâle getirmeyi, çökme ve yığın izlerinin içine dalmayı seviyorum. Büyük makinelerle uğraşınca, RAM’i ‘sadece’ 128 GB ya da diski 20 TB olan bir sunucu gördüğünüzde normal ölçünüz bozuluyor
      Korkutucu olan, bu sonuçların gerçek dünyada kullanılması; ama simülasyonları çalıştıran kişilerin bunu doğru yapmadığı durumlar olabiliyor. Hatalı kod, birbirine karışmış kaynak kodu, kullandıklarını sandıkları veri yerine başka veri kullanımı, üç yıldır var olan devasa bir hata bulduğum oldu. O zaman bu konuda şimdiye kadar yapılan tüm çalışma geçersiz mi oluyor diye düşünüyorsunuz
      Dezavantajı, HPC işlerinin önemli bir kısmının yalnızca küme işletmekten ibaret olmasına rağmen yüksek lisans derecesi istemesi. Bunu pek anlayamıyorum. Çalıştırdığım yazılımı yazmıyorum, en yeni TOP500 kümesini de işletmiyorum. Sadece birden fazla makineyi ağa bağlayıp kod çalıştırma işi
    • Çok soyutlama var; ama hangi soyutlamayı kullanacağını bilmek için hâlâ donanım hakkında çok şey bilmek gerekiyor
      CUDA geliştiricileriyle çalışma deneyimime göre, performansı ortaya çıkarmak için birçok ayarla oynanıyor. Shmoo Plot(https://en.wikipedia.org/wiki/Shmoo_plot, bazı sektörlerde ‘wedge’ olarak da adlandırılır) günlük optimizasyonun temel araçlarından biri
      Yine de buna kara kutu der miyim emin değilim. Sonuçta benzer olabilir. Ayar düğmelerinin ne yaptığını ve nasıl çalıştığını bilip gerekçeli tahminler yapsanız bile ölçüm yaptığınızda büyük sürprizlerle karşılaşmak yaygındır. Optimizasyonun ilk kuralı ölçmektir
      Michael Abrash’in “Black Book” kitabının ilk bölümü “The Best Optimizer is Between Your Ears” http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf hep aklıma gelir. Modern HPC değil de PC oyunlarına odaklı olsa da yüksek performans felsefesini iyi gösteren harika bir yazıdır
      Soyutlamalarla bağlantılı olarak, en ağır ayar düğmesi ince ayarını optimizasyon sürecinin sonunda yapmak en iyisidir. Çünkü refactor yaptığınızda ya da bir şeyi değiştirdiğinizde ayar düğmelerini yeniden ayarlamak gerekir. Register spill ya da önbellek erişim desenindeki küçük bir değişiklik bile iş parçacığı yapılandırması, önbellek, paylaşımlı bellek boyutu gibi ince ayarları tamamen sıfırlayabilir
      Yine de aralarda makul miktarda ayar düğmesiyle oynamak gerekir. Kontrol ve denge sağlamak, kodun çevresindeki performans uzayı hakkında sezgi kazanmak için
    • Bir HPC yöneticisi olarak genellikle “bilimin uzun kuyruğu”ndaki araştırmacıları destekliyorum
      Günümüz x86_64 donanımında süper bilgisayar bellek alt sistemi diye bir şey yok. Sadece gösterişli bir NUMA sistemi var; en büyük mesele de belleği çekirdeklere yakın tutmak, yani gecikmeyi azaltmak için veriyi ilgili NUMA düğümünün içinde yerel tutmak
      Kaynak eşlemesini zamanlayıcı halleder. Zamanlayıcı donanımı bildiği için gereksinimleri karşılayan ve mümkün olduğunca optimize edilmiş bir cgroup oluşturur, uygulamayı da o cgroup içine koyup çalıştırır

Günümüzde yüksek performanslı ara bağlantıların kralı InfiniBand ve MPI’yi fabric düzeyinde hızlandırıyor. Mesaj iletimi, broadcast ve sonuç indirgemeyi çok hızlı yapabiliyor. Mesaj geldiğinde zaten indirgenmiş oluyor; broadcast sırasında ise tek bir mesaj göndermek yetiyor, broadcast fabric katmanında gerçekleşiyor. Çok bağlamlı IB kartlarında çok sayıda kuyruk bulunduğundan, tek bir düğüm/kart üzerinde kuyruk/bağlam yalıtımıyla birden çok MPI işi çalıştırılabiliyor
GPU işleri için bir framework kullanırsanız yapı ve optimizasyonlar genellikle o düzeyde otomatik olarak halledilir. Zor işi çoğunlukla framework geliştiricileri yapar. NVIDIA sürücüsü de saf kara büyü gibi çalışır ve optimizasyonun bir kısmını üstlenir. GPU’lar arası bağlantıyı fiziksel fabric sağlar; bunu sürücü ve kendi daemon’ı yönetir
Darboğaz CPU ise kütüphaneler genellikle tedarikçi tarafından elle ince ayarlanmıştır. Intel MKL, BLAS, Eigen gibi; şahsen kullandığım Eigen’da işlemciye özgü ipuçları ve optimizasyonlar vardı
Dikkat edilmesi gereken, kodu doğru mimari için derlemek ve çalıştığı donanımın gereksinimleri karşılayabildiğinden emin olmaktır. Örneğin çok fazla rastgele bellek erişimi yapmamak, bir düğümde “mümkün olduğunca hızlı” gitmek için prefetcher ve branch predictor ile uyumlu çalışmak, disk erişimini kötüye kullanmamak gibi
Sayısal hesaplama tarafında kilit nokta, işleri bağımsız tutarak instruction-level parallelism/vektörleştirmeyi mümkün kılmak, gereksiz hesap yapmamak ve MPI’yi kötüye kullanmamak; yani düğümler arası konuşmayı gerçekten gerekli düzeye indirmektir
Söylemesi kolay, ama alışınca bunları düşünmek ikinci doğanız haline geliyor. Tabii bu tür işler zevkinize uyuyorsa

  • Hem doğru hem değil
    MPI ve OpenMP, HPC’de donanımı soyutlamanın başlıca yollarıdır. MPI, dağıtık bellekli paralel hesaplamanın; OpenMP ise paylaşımlı bellekli paralel hesaplamanın soyutlamasıdır. Birçok araştırmacı kodunu yalnızca bu ikisiyle yazar; aynı kodda ikisinin birlikte kullanılması da yaygındır. Bunları kullanırken çoğu zaman mimari ayrıntılarla ilgilenmeniz gerekmez
    Yine de daha fazla optimizasyon yapmayı seven araştırmacılar, performansı biraz daha artırmak için küçük mimari ayrıntılarla epey uğraşır. Örneğin loop unrolling oldukça yaygındır ve şahsen bunun epey kafa karıştırıcı olabileceğini düşünüyorum. Belirli bir CPU mimarisi nedeniyle çarpmaya göre toplamayı tercih edip işlemleri vektörleştirmeye çalıştıklarına dair belli belirsiz bir şey hatırlıyorum, ama bunu gerçekten görmüş değilim
    Cache miss’leri önlemek de büyük bir konudur. Bazı kodlar, en gerekli bilgileri bellek yerine CPU cache’inde tutacak şekilde yazılır. Çoğu kod bunu Fortran’da dizi işlemleri için sütun öncelikli dolaşımı, C’de ise satır öncelikli dolaşımı garanti etmekle sınırlı tutar; ancak kavram daha ileri taşınabilir. İşlemcinin cache boyutunu biliyorsanız, gerekli tüm bilgileri cache içinde tutacak şekilde bazı işlemleri optimize edip cache miss’leri en aza indirebilirsiniz. Bunu pratikte görmedim ama 2013’te aldığım bilimsel hesaplama dersinde aktif olarak ele alınmıştı
    Belirli bir GPU’nun kullanılıp kullanılmayacağı, çözmeye çalıştığınız probleme büyük ölçüde bağlıdır. Bazı problemler GPU’da harika çalışır, bazıları ise çok zordur. Ne yazık ki o kısmı pek bilmiyorum

  • Victor’un böylesine harika bir kaynak derlemiş olmasına hayran kaldım
    Kendisini şahsen tanımıyorum ama 1990’larda UT Austin’de doktora yaparken TACC’nin yönettiği kaynakları (Cray Y-MP, IBM SP/2 Winterhawk ve o dönem Cray T3E’yi ifade eden Lonestar ana makine adı) kullanarak araştırmamı tamamladım. Doktora jüri üyelerimden biri hâlâ orada. Hafızam doğruysa o zamanlar TACC’ye HPCC ya da CHPC deniyordu
    O dönemde programcıların kodu bizzat paralelleştirmesi gerekiyordu; benim durumumda UNICOS ortamındaki Cray T3E üzerinde MPI kullanıyordum. Alan henüz erken aşamada olduğu için donanım hakkında da bir miktar anlayış gerekiyordu. Sorunları gri Cray halkalı klasörlerini ve elimdeki Gropp ve diğerlerinin kitabını okuyarak çözdüm; elbette yukarıda bahsettiğim bilgili irtibat kişisi de çok yardımcı oldu

    • Lonestar5 yeniden Cray’di. Mevcut Lonestar6 ise A100 GPU’lara sahip, yağa daldırmalı AMD Milan kümesi
      Zaman asla durmuyor
    • TACC üzerinden büyük simülasyonlar yürütürken onunla çalışmıştım; yardımı için minnettar olduğumdan bu serinin 1. cildinin basılı kitabını satın aldım
      Benim alanımın biraz dışında olsa da çok ilginçti. Geri kalanlarına da bakmayı planlıyorum; ilgilenenlere incelemelerini öneririm

  • HPC’nin donanım yönetimi tarafıyla ilgileniyorum
    Sorunların nasıl tespit ve teşhis edildiğini; yeniden başlatma/yeniden kurulum/onarım gibi eylemlerle nasıl eşleştirildiğini; bu işlerin nasıl zamanlandığını ve en iyi hizmet düzeyini sağlayacak şekilde nasıl optimize edildiğini merak ediyorum
    Düğüm kullanılabilirliği ve toplam iş hacmi gibi aynı anda optimize edilmesi gereken birden fazla hedef olduğunda bunun nasıl yapıldığı; farklı topolojilerin yukarıdakileri nasıl etkilediği; başka kısıtların nasıl etki ettiği ve genel olarak bu sorunların sistem dinamiği bakış açısından nasıl ele alındığı da ilgimi çekiyor
    Bu bilgileri iyi işleyen çok fazla kaynak bulamadım. Bildiğiniz kaynaklar varsa paylaşırsanız sevinirim

    • Genel amaçlı tıkanmasız folded-Clos ağların ya da Little yasasının ötesinde, daha mühendislik odaklı bir bakış istiyorsan kuyruk teorisine dalman gerekir
      Kuyruk teorisi ilk öğrenildiğinde önemsiz ve kolay görünür ama pek çok açık problem barındırır
      Örneğin rastgele varış zamanları, bağımsız hizmet süreleri ve k sunucuya sahip bir sistemin (M/G/k) performans metrikleri bile hâlâ açık problemdir
      https://www.sciencedirect.com/science/article/pii/S0895717704905341
      Beklenenin aksine kuyruk teorisinde gerçekten çok sayıda açık problem var
    • Birkaç ay önce Meta ve nVidia ile mülakat yaparken bunun büyük bir konu gibi göründüğünü fark ettim
      Meta’nın bu ölçekte GPU’larla uğraşma sorununu anlatan birkaç iyi YouTube videosu vardı
    • Mark Russinovich neredeyse her yıl Azure’un iç yapısı ve onu çalıştıran sistemler hakkında iyi bir sunum yapıyor. [1] buna bir örnek; diğer yılların sunumlarına da bakmaya değer
      Meta da mühendislik sitesinde çok sayıda makale, blog yazısı ve açık kaynak proje yayımlıyor [2]
      AWS’ten James Hamilton da neredeyse her yıl altyapı hakkında sunum yapıyor. Birkaç yılın sunumlarına bakmaya değer [3]
      [1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
      [2] https://engineering.fb.com/category/data-center-engineering/
      [3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
    • Microsoft’un bu makalesi [1], bu alanda gördüklerim arasında en havalısıydı
      Temelde iş yükü, burada derin öğrenme işleri düzeyinde optimizasyon yaparak iş boyutunun ayarlanmasını ve öncelikli kesintiye uğratmayı mümkün kılıyor
      [1] https://arxiv.org/pdf/2202.07848.pdf
    • openbmc projesine ve DTMF konsorsiyumuna bakmak iyi olur

  • 2013’te bilimsel hesaplama dersi almıştım
    Bilgisayar bilimi ve uygulamalı matematik bölümleri arasında çapraz açılan bir dersti. Sorun, alanın genel olarak çok geniş olması nedeniyle HPC ve paralel programlama dâhil pek çok konunun çok yüzeysel ele alınmasıydı. Aldığıma pişman değilim ama peşinde olduğum uygulamalar için fazla genişti
    Birkaç yıldır hangi derslerin açıldığına bakmadım; ancak yüksek lisans/doktora öğrencisiyken paralel hesaplamayı tüm dönem boyunca ele alan özel bir ders gerçekten faydalı olurdu diye düşünüyorum. Özellikle paralel ve dağıtık hesaplamanın belirli algoritmaları ve veri yapıları üzerine derinleşen bir derse ihtiyaç vardı
    Aldığım bilimsel hesaplama dersinde bu konular çok üstünkörü ele alınmıştı; sanki ilk denemede tam olarak nasıl paralelleştirileceğini bilebilirmişsin gibi. Sonrasında pek çok HPC insanı gibi yıllar içinde kendi başıma ve meslektaşlarımdan çok şey öğrendim; ama bu kitaplar bir dönemlik özel bir dersin parçası olsaydı çok değerli olurdu

  • Yazarın C++ ve Unix araçları eğitimini bile içeren böylesine kapsamlı kitaplar hazırlayıp ücretsiz paylaşmış olması şaşırtıcı
    HPC’ye özel olmasa bile her programcının öğreneceği şeyler var
    İlgili kaynaklar arasında Jorg Arndt’ın “Matters Computational” kitabı ve FXT kütüphanesi de var: https://www.jjj.de/fxt/

  • Burada kullanılan C++ eğitim yaklaşımını nasıl gördüğünüzü merak ediyorum. Özel bir dezavantajı var mı?
    Python’ı çok uzun süredir kullanıyorum; C, C++ ve CUDA ile de biraz çalışıyorum ve HPC ortamında uygulama düzeyi araştırma (ML/DL) yapıyorum. C++ becerimi geliştirmek istiyorum; 3 cilde göz attığımda seviyeme tam uygun göründü. Çok yavaş ilerlemiyor; kapsayıcı olmayı hedeflemekten çok, yazarın iyi uygulama olarak gördüklerini öğreten bir yaklaşım izliyor

    • Bir C++ programcısı ve eğitimci olarak baktığımda, bu 3 cilt iyi yapılandırılmış başlangıç düzeyi eğitim materyali. Muhtemelen çoğunu zaten biliyorsunuzdur
      Aralık tabanlı for döngüsü, std::array ve std::span aradım; hepsinin olması sevindiriciydi
      Bu kitap HPC ile ilgili olduğundan birkaç şey eklemek isterim. Dönüş değeri optimizasyonu, move semantiği ve özyinelemeli fonksiyonlar bölümünde kuyruk çağrısı optimizasyonuna dair açıklama olsa iyi olurdu
      Başlangıç düzeyi materyal olarak güçlü şekilde tavsiye edebilirim
    • “The Art of HPC” 2. cilt “Parallel Programming for Science Engineering”in C, Fortran, C++ ve MPI için Python’da MPI ve OpenMP’yi ele alması dikkat çekici: https://theartofhpc.com/pcse/index.html
      Not olarak, MPI Python ile HPC yapmanın yalnızca bir yolu
      Yanlış hatırlamıyorsam ipyparallel, kendi oluşturduğu tünel üzerinden MPI işlerini çalıştırabiliyor
      dask-scheduler, CuDF, CuGraph(NetworkX), DaskML, CuPy ve dask-labextension hakkında bölümler olsaydı daha güncel olurdu
      Dask veri depolamayı sizin yerinize halletmediğinden, her bariyer öncesindeki veri deposunun performans darboğazı olmamasını sağlamak kullanıcının sorumluluğunda
      Dask belgelerinde High Performance Computers: https://docs.dask.org/en/stable/deploying-hpc.html
      Rastgele sayı kaynağı da darboğaz olabilir. Kümenin tamamında işi profillemeden bunu bilemezsiniz
      eBPF tabanlı izleme araçlarıyla ilgili: https://news.ycombinator.com/item?id=31688180
      Sonrasında GitOps ve ChatOps, kod inceleme ve revizyon, proje kaynak kotaları gibi konuların da olması iyi olurdu

  • 10 yıl önce bir HPC lisansüstü dersinde asistanlık rolünü paylaşmam için teklif almıştım ama reddetmiştim
    Üstünkörü baktığım kadarıyla, o zaman bu kitap olsaydı o fırsatı değerlendirmiş olacağımı dürüstçe söyleyebilirim
    Knuth tarzı görünen sanat olarak çerçeveleme, marangozluk benzetmesi ve kendi DevOps sorumlunuzdan daha iyi bir DevOps insanı olma gerekliliği birleşince ikna edici oluyor
    Yazarın başarısını alkışlıyorum. UT Austin, bilgisayar biliminde North Texas State’in müzikte başardığına benzer bir şey başarmış gibi görünüyor

  • UT Austin, HPC ve hesaplamalı yöntemler alanında gerçekten mükemmel bir kurum

    • Kullanmak isteyebileceğiniz neredeyse her BLAS, bir ölçüde UT Austin’in TACC’siyle bağlantılıdır

  • Büyük bir otomobil üreticisinin HPC mühendislerini destekleyen küçük bir şirkete katıldığımda, zamanlayıcı LSF etrafında bu kadar çok kurum içi geliştirilmiş script olmasına şaşırmıştım
    Çok daha sonra kişisel mini kümemde SLURM ile uğraşırken, zamanlayıcı yazılımının sürümlerinin birbirleriyle büyük ölçüde uyumlu olmadığını fark ettim. Yani küme içinde bir sürüm, dış istemci makinede başka bir sürüm kullanmak mümkün değildi
    Bu yüzden dışarıdan zamanlayıcıya iş göndermek ve daha sonra sonuçları almak için yapıştırıcı yazılıma ihtiyaç vardı. Kişisel olarak bunun zamanlayıcının değerini azalttığını düşünüyorum
    Yüksek performanslı dağıtık hesaplama 30 yıldır yapılıyorsa gereksinimlerin iyi bilindiğini ve en azından komut ve veri alışverişi protokolünün sabitlenmiş olduğunu sanırdım. Ama öyle değil gibi

    • Küme kimlik doğrulaması aslında tüm etkileşimlerde hâlâ baş ağrısı. Çoğu sistemde en düşük ortak payda, oturum açma düğümüne SSH ile girebilip giremediğiniz. O noktadan itibaren sbatch/squeue gibi ana iş komutları oldukça kararlı
      Geçmişte temel iş yönetimi API’sini standartlaştırma girişimleri de oldu; DRMAA dikkate değer bir örnek. Ancak DRMAA v2’yi yalnızca Grid Engine uyguladı ve aslında dahili API’nin hafifçe soyutlanmış bir sürümü olduğundan Slurm/PBS/LSF’de birinci sınıf destek elde edemedi
      Slurm’de REST API geleceğin yolu olarak görülüyor. Kimlik doğrulama sorunu, Apache/NGINX proxy üzerinden yöneticilerin bağlamak istediği herhangi bir yönteme devrediliyor. Temel iş gönderme ve durum API’leri, gelecekte istemci uygulamaların neredeyse her sürümünün tüketebileceği kadar kararlı hâle geldi