7-8-9 Ocak'ta, yani geçtiğimiz birkaç gün boyunca Intel sponsorluğunda bir MPI/OpenMP semineri düzenlendi. Seminerler ODTÜ Bilgisayar Mühendisliği bölüm lablarındaydı. Ben son gün Debugger oturumuna katılabildim ama gördüğüm kadarıyla eğitimler zevkli ve bilgilendiriciydi. Öğrendiğime sevindiğim bilgiler şunlar:

# qsub -I

qsub'ın interactive (etkileşimli) modu olduğunu bilmiyordum doğrusu. Hep bir iş tanımı yapıp ona qsub ile gönderiyorduk, bu yöntemin farkında değildim. Aslında Nar'da ilk zamanlarda mpirun programına bir nodefile gösterip istediğimiz uçlarda direk çalışmasını (yani iş yöneticisine uğramadan) sağlayabiliyorduk ama sonra bu yöntem çok verimli olmadığı için kapatıldı. Sanırım etkileşimli seçenek de istediğimiz uçları bloke ettiği için aynı şekilde verimsiz. Bu da belki kapatılabilir, veya sırf Intel göstersin diye de açılmış olabilir. Örneğin

# qsub -I -l nodes=2:ppn=8 -q cenga

diyerek 2 uçta 8 çekirdeğin bize verilmesini isteyebiliriz.

Etkileşimli qsub'ın güzel özelliklerinden birisi de direk HPC makinesinde debug yapabilmemiz. Bunun için kendi MPI kütüphanenizin binary dosyalarının yardımlarına bakın "mpirun --help" ile. OpenMPI'da debug için -debug, MVAPICH'de sanırım -gdb demeniz gerekiyor. qsub etkileşimli modda örnek bir komut şöyle:

# mpirun -r ssh -gdb -n 4 ./a.out

Tekrar söylüyorum, bunun çalışması için etkileşimli modda olmanız gerekiyor.

Bunun dışında debugger olarak paralı olan TotalView ve Intel Traceanalyzer gibi programlardan bahsedildi. Paralı ve ticari oldukları için çok dikkate almadım ben. OpenMPI'ın kendi web sitesinde debug etmek için programın bir yerinde sleep çağırılması ve sonra debugger ile attach etmek öneriliyor. Benim de kullandığım yöntem bu aslında. HPC makinelerde debug yapılmasını çok önermiyorum, kendi yerel makinenizde (birden fazla işlemciniz olmasa bile) küçük verilerle başlayarak testler ve hata ayıklama yapabilirsiniz.

Intel'den gelen eğitimciler gerçekten hakim görünüyorlardı işlerine. Bence HPC, Grid konusu gelişecekse üniversitelerin ve/ya TÜBÜTAK/Ulakbim'in de uzun dönemli kaliteli araştırmacı/eğitici yetiştirmesi gerekiyor. Bilgili ve bilgisini kolay/eğlenceli bir şekilde anlatabilen insanlara ihtiyaç var. Tabii bu üniversite/kadro ve geleceğe/gençlere yatırım sorunlarının bir parçası aslında.


Konuşmak istediğim bir başka konu ise Boost kütüphaneleri. MPI'ı saf C kütüphanesi olarak kullanırsanız çok esnek/güçlü bir platforma sahip olursunuz ama eğer karmaşık sınıflarınız varsa, objeye yönelik programlama yapmak istiyorsanız MPI C biraz zayıf kalacaktır. Bunun için Boost::MPI kütüphanelerini kullanabilirsiniz. Boost::MPI kütüphaneleri arka planda herhangi bir MPI C kütüphanesini kullabiliyorlar (OpenMPI ve MVAPICH de tabii ki destekleniyor). Boost sayesinde serialize edebildiğiniz sınıf objelerini kullanabilir, direk uçlara yollayabilirsiniz. Güzel değil mi?

Bugün seminerde OpenMP/MPI hibrit konusu açıldı. Aslında MPI'ın OpenMPI implementation'ı SMP sistemlerde ortak belleği kullanıyor. Bu biraz OpenMP'nin yaptığına benziyor ama şöyle bir temel farktan kaynaklanan bir durum var: OpenMP'de işler threadlerle halledilirken MPI'da bunlar process'ler. Yani OpenMPI'ın spec'lere göre yapması gereken ayrı bir hafızasının olması. Bu durumda hafıza kopyalanıyor bir adresten diğer adrese ve diğer uç onu kullanabiliyor. Tabii bu TCP üzerinden vs. olmadığı için gayet hızlı, ama hiç kopyalama yapmadan direk olarak hafıza bölgesini kurcalayabilen OpenMP'ye göre de yavaş. Ama OpenMP de çok esnek bir yapı değil, parallelleştirebileceğiniz belirli yapılar (for döngüsü gibi) var. Yani her zaman olduğu gibi bir nevi trade-off. "Doğru işe doğru alet" mantığıyla işinize en uyan yöntemi kullanmanız gerekiyor. Bu hibrit bir yöntem de olabilir, tek başına MPI veya OpenMP de.

Bu arada unutmadan, Boost kütüphanelerinde varsayılan olarak MPI kurulmuyor. "./configure"dan sonra user-config.jam dosyasını değiştirip "using mpi ;" satırını eklemeniz gerekiyor. Bundan sonra "make install" işiniz görecektir. Boost'taki birçok kütüphane zaten sadece header'lardan oluştuğu için derlenmesine de gerek yok, ama yine de diğer kütüphanelerin derlenmesi biraz zaman alıyor. /usr/local/lib ve /usr/local/include dizinlerine dosyaları yazmak için root yetkinizin olmasına dikkat edin.