Beowulf NASIL

Yazan: Jacek Radajewski ve Douglas Eadline

Çeviren: A. Murat EREN

v1.1.1, 22 Kasım 1998

Özet

Bu belge, sizi Beowulf Super Bilgisayar mimarisi ile tanıştırmak ve Koşut Programlama ile ilgili bilgi vermek amacıyla bir araya getirilmiştir. Lütfen belge/çeviri ile ilgili düşünce ve tavsiyelerinizi <meren~comu.edu.tr> adresine gönderiniz. Ayrıca Beowulf ve Koşut Hesaplama (Parallel Computing) ile ilgili sorularınızı da aynı adrese gönderebilirsiniz.


İçindekiler

1. Önsöz
1.1. Feragatname
1.2. Telif Hakkı
1.3. Bu NASIL Hakkında
1.4. Yazarlar Hakkında
1.5. Teşekkürler
2. Başlangıç
2.1. Bu NASIL'ı kimler okumalı?
2.2. Beowulf Nedir?
2.3. Sınıflandırma
3. Mimariye Bakış
3.1. Nasıl görünüyor?
3.2. Diğer düğümler nasıl kullanılacak?
3.3. Beowulf ile COW arasındaki fark nedir?
4. Sistem Tasarımı
4.1. Koşut Hesaplama üstüne temel bilgiler
4.2. Koşut Hesaplama Yöntemleri
4.2.1. Neden birden fazla işlemci?
4.2.2. Koşut Hesaplama Mağazası
4.2.2.1. Tek Görevli İşletim Sistemleri
4.2.2.2. Çok Görevli İşletim Sistemleri
4.2.2.3. Çok İşlemcili Çok Görevli İşletim Sistemleri
4.2.2.4. Çok İşlemcili Çok Görevli İşletim Sistemlerinde Kanallama
4.2.2.5. Çok İşlemcili Çok Görevli İşletim Sistemlerinde İletilerin Gönderilmesi
4.3. Koşut Hesaplama Mimarileri
4.3.1. Donanım Mimarileri
4.3.2. Yazılımsal Mimariler
4.3.2.1. İletiler
4.3.2.2. Kanallama
4.3.3. Uygulama Mimarisi
4.4. Uygunluk
4.5. Writing and porting parallel software
4.5.1. Determine concurrent parts of your program
4.5.2. Estimate parallel efficiency
4.5.3. Describing the concurrent parts of your program
4.5.3.1. Explicit Methods
4.5.3.2. Implicit Methods
5. Beowulf Kaynakları
5.1. Başlangıç Noktaları
5.2. Belgeler
5.3. Sayfalar
5.4. Yazılım
5.5. Beowulf Makinalar
5.6. Diğer ilgi çekici siteler
5.7. Geçmiş
6. Kaynak Kod
6.1. sum.c
6.2. sigmasqrt.c
6.3. prun.sh

1. Önsöz

1.1. Feragatname

Bu belgelerdeki herhangi bir yanlış açıklama ile ilgili veya belgelerde aktarılan bilgilerin uygulaması sırasında meydana gelebilecek zararlarla ilgili hiçbir sorumluluk kabul edilmez.

1.2. Telif Hakkı

Telif Hakkı © 1997 - 1998 Jacek Radajewski and Douglas Eadline. Türkçe çevirisini telif hakkı © 2000 A. Murat EREN. Bu belgenin yayın ve değişim hakkı GNU Genel Kamu Lisansı altında saklıdır.

Copyright © 1997 - 1998 Jacek Radajewski & Douglas Eadline. Turkish translation: Copyright © 2000 A. Murat EREN. Permission to distribute and modify this document is granted under the GNU General Public Licence.

1.3. Bu NASIL Hakkında

Bu belge Kasım 1997 yılında Jacek Radajewski tarafından oluşturulmaya başlanmış, ve Douglas Eadline daha sonrasında çalışmalara katılmıştır. Birkaç ay içinde Beowulf NASIL büyük bir belge haline geldi ve Ağustos 1998'de 3 belgeye ayrıldı: Beowulf NASIL, Beowulf Mimari Tasarımı NASIL ve Beowulf Kurulumu ve Yönetimi NASIL. Beowulf NASIL'ın 1.0.0 sürümü 11 Kasım 1998'de Linux Belgelendirme Projesi altında dağıtıma girdi.

1.4. Yazarlar Hakkında

  • Jacek Radajewski Ağ Yöneticisi olarak çalışmakta ve halen Avusturalya`daki University of Southern Queensland`de Bilgisayar Bilimleri üzerine akademik kariyer yapmaktadır. Radajewski, Linux ile ilk kez 1995 te tanışmış ve bu işletim sisteminin yenilikleri ve yapısından ilk görüşte etkilenmiştir. Radajewski, kendisinin ilk Beowulf grubunu 1997 Mayısında oluşturmaya başlamış ve bu güne dek daha iyi şekilde çalışması için gereken ayarlamaları yapmakla meşgul olmuştur. Radajewski`ye <jacek~usq.edu.au> posta adresinden ulaşabilirsiniz.

  • Douglas Eadline, Amerika'daki Paralogic Inc.`ın başkanı ve en önemli bilim adamıdır. Fiziksel/Analitik Kimya üzerine eğitim almıştır ve bilgisayarlarla 1987 de kimya endüstrisi için geliştirdiği ilk Single Board Computer`dan bu yana iç içedir. Dr. Eadline şu an Linux, Beowulf grupları ve koşut algoritmalarla ilgilenmektedir. Eadline'a <deadline~plogic.com> adresinden ulaşabilirsiniz.

1.5. Teşekkürler

Beowulf NASIL uzun bir uğraşının sonunda bitti. Aşağıda ismi geçen kişilere yardımları ve katkılarından ötürü teşekkür etmek istiyorum;

  • Anlayışı, sevgisi ve desteğinden dolayı Becky...
  • Tom Sterling ve Don Becker başta olmak üzere Beowulf projesini NASA`da başlatan kişilere...
  • Beowulf`u test etmek ve incelemek üzere oluşturdukları topcat Beowulf Machine için Thanh Tran-Cong ve Mühendislik Fakültesine...
  • Mükemmel fikirlerinden ötürü danışmanım Christopher Vance`e...
  • Programlama aşamasındaki fikirlerinden, projeye olan desteğinden ve desteğinden türü arkadaşım Russell Waldron`a...
  • Bu belgeyi denetleme ve incelemesinden ötürü arkadaşım David Smith`e...
  • Ve Beowulf eposta listlerinde bana program hakkındaki görüşlerini sunan ve eleştiride bulunan herkese teşekkür ederim.

2. Başlangıç

Her geçen gün bilgisayar malzemelerinin ve ağ donanımlarının fiyatları düşmekte ve performansları artmaktadır. Ve bununla beraber her geçen gün koşut sistemler oluşturmak diğer pahallı Super bilgisayarlara nazaran çok daha ucuza maledilebilir hale gelmektedir. Ve ispatlanmış bir gerçektir ki, Beowulf tipi bir makine bilindik Super bilgisayarlara nazaran 3 ila 10 kat daha yüksek performans ortaya koymaktadır. Beowulf`un kaliteli mimarisi ve kolay kurulumuyla beraber sadece donanıma para verirsiniz. Beowulf üzerinde çalışan programların çok büyük çoğunluğu bedavadır.

2.1. Bu NASIL'ı kimler okumalı?

Bu NASIL, en azından biraz araştırma yapmış olan kişiler için hazırlanmıştır. Beowulf teknolojisini anlamak için karmaşık işletim sistemleri uzerine uzmanlaşmış olmak ya da ağ yönetimi konusunda çok fazla bilgiye sahip olmak şart değildir. Fakat koşut programlama hakkında daha önceden araştırma yapmış olmak bir getiri sağlayabilir.. Bu NASIL belgesi elbette sizin bütün sorularınızın cevabını bulabileceğiniz kadar geniş bir kaynak değildir, fakat umarız ki size doğru yönde ilerlemeniz için ihtiyacınız olan fikirleri ve yönergeleri verebilir.

2.2. Beowulf Nedir?

Beowulf: far flew the boast of him, son of Scyld, in the Scandian lands. So becomes it a youth to quit him well with his father's friends, by fee and gift, that to aid him, aged, in after days, come warriors willing, should war draw nigh, liegemen loyal: by lauded deeds shall an earl have honor in every clan.

Beowulf, bu güne kadar gelebilmiş en eski ingilizce destansı şiirlerden birisidir. Bu, süper güçlü ve yaşadığı dönemlerde Grendel olarak anılan canavarı yenmeyi başarmış olan bir kahramanın hikayesidir. Daha fazla bilgi için bkz. Geçmiş.

Muhtemelen Beowulf üzerine bir çok tanım yapılmıştır; Beowulf ile yaratılan super bilgisayarları kullananlar veya bu bilgisayarları kuranlar tarafından. Sadece NASA daki orjinal makinenin kurulum yolunu izleyerek kurulmuş bir makine gerçekten Beowulf super bilgisayarı olarak adlandırılabilir. Benim eposta listlerine de postaladığım Beowulf tanımım şöyledir:

Beowulf, koşut hesaplamalarda kullanılabilen bir çok bilgisayarlı mimaridir. Bu sistem, bir sunucu düğümü altında bir veya daha fazla istemci düğümünün ethernet ya da diğer ağ çözümleri yoluyla birleştirilmesiyle oluşturulur. Sistem oluşturulurken, herhangi bir PC'de bulunan ethernet kartı ve switch'ler gibi donanım bileşenleri kullanılır. Özel donanım bileşenlerine ve gereksiz parçalara ihtiyaç duymaz. Beowulf ayrıca yazılım ürünlerini Linux işletim sistemi, Koşut Sanal Makina (Parallel Virtual Machine - PVM) ve İleti Aktarım Arabirimi (Message Passing Interface - MPI) gibi kullanır. Sunucu düğümü bütün grubu kontrol eder ve istemci düğümlerine dosya paylaşımını gerçekleştirir. Ve ayrıca sunucu, istemcilerin konsoludur ve dış dünya ile iletişimlerini sağlar. Büyük bir Beowulf makinede birden fazla sunucu düğümü olabilir ve diğer düğümler farklı işleri ve görevleri yerine getirebilirler örneğin, konsollar ve görüntüleme istasyonları gibi çalışabilirler. İstemci bilgisayarlarlar sunucu bilgisayar tarafından yapılandırılır ve kontrol edilir. İstemci düğümleri sadece kendilerine suncu tarafından söyleneni yaparlar. Bir disksiz istemci yapılandırmasında, istemci düğümü, kendi adını ve IP adresini bile bilmez. Ve sunucu onları bu konuda bilgilendirinceye dek bu sekilde devam eder. Beowulf makineler ve İşistasyonu Topluluğu (Cluster of Workstations - COW) arasındaki en önemli fark, Beowulf sistemler, diğer çoğu sistemden, çok daha fazla tek bir bilgisayar gibi davranmayı başarır. Çoğu durumda istemci düğümlerde klavye, monitör, fare gibi aygıtlar bulunmaz; ve bu makinelere ulaşım sadece uzaktan erişim veya seri uçbirim yoluyla gercekleştirilebilir. Her Beowulf düğümü, anakarta kolayca monte edilebilen bir işlemci + bellek paketi gibi düşünülebilir.

Beowulf, ne özel bir yazılım, ne yeni bir ağ mimarisi, ne de yeni bir çekirdek mantığıdır. Beowulf, Linux bilgisayarları gruplayarak, bir araya getirerek, sanal bir super bilgisayar yaratma teknolojisidir. Her ne kadar, Beowulf mimarisini hızlandırmak ve yapılandırmak için birçok çekirdek değiştirici yazılıma, PVM ve MPI kütüphanelerine ve yapılandırma araçlarına ihtiyacınız varsa da, aslında Beowulf sınıfında bir makineyi standart Linux dağıtımlarından çıkan yazılımlardan daha fazlasına ihtiyaç duymadan oluşturabilirsiniz. Eğer bir ağ üzerinde, birbirlerinin /home dizinlerini NFS aracılığıyla paylaştırmış ve birbirleri üzerinde program çalıştırma hakkına sahip iki Linux makine varsa, iki düğümlü basit bir Beowulf sisteme sahip olduğunuzu söyleyebiliriz.

2.3. Sınıflandırma

Beowulf sistemler cok çeşitli parçalardan oluşturuldu. Bir tek üreticinin standart parçalarıyla inşa edilmediğinden dolayı çok çeşitli Beowulf sistemlerine rastlamak mümkündür. Farklı şekilde imal edilen Beowulf makineleri daha kolay şekilde ele alabilmek için aşağıdaki gibi sınıflara ayırdık:

1. Sınıf BEOWULF
Bu sınıfa dahil olan makineler tamamiyle kullanıma hazır parçalardan oluşturulmuştur. Aşağıda "Computer Shopper"'ın (Computer Shopper aylık yayınlanan ve 1 inç kalınlığında bir bilgisayar magazin dergisi) test sonuçlarını göreceksiniz:

Birinci Sınıf Beowulf makinesi, en azından 3 uluslararası reklam kataloğunda bulabileceğiniz parçaların biraraya getirilmesiyle oluşturulmuştur.

1. Sınıf Beowulf sistemin getirileri:

  • Donanımın temin edilmesi çok kolay ve ucuzdur.
  • Tek bir donanım üreticisine bağımlılık zorunluluğu yoktur.
  • Linux sürücüleri donanımları desteklemektedir.
  • çoğunlukla standart kartlarla inşa edilmiştir (SCSI, Ethernet, vb.)

1. Sınıf Beowulf sistemin götürüleri:

  • En iyi başarım için 2. Sınıf donanımı gerekmekte.

2. Sınıf BEOWULF
Bir 2. sınıf Beowulf makineler sadece Computer Shopper'ın yaptığı sertifika testinden geçemeyen makinelerdir. Testten özellikleri itibarıyla geçememişlerdir, fakat bu kötü bir şey değildir, bunu sadece sınıflara ayırmak için kullandık.

2. Sınıf Beowulf sistemin getirileri:

  • Performans oldukça iyi.

2. Sınıf Beowulf sistemin götürüleri:

  • Sürücü desteği yetersiz olabilir.
  • Tek bir donanım üreticisi ile çalışılmaktadır.
  • 1. Sınıf sistemlerden daha pahalıya malolabilir.

Bir sınıf, bir diğerinden daha iyidir ya da daha kötüdür demek anlamsız olacaktır. Bu sadece sizin bütçenize ve ihtiyaçlarınıza bağlıdır. Bu sınıflandırma sistemine sadece kolay karşılaştırmak için başvurulmuştur. Sistem Tasarımı bölümü muhtemelen ihtiyacınız olan sistemin sahip olması gereken özelliklere karar vermenize yardımcı olacaktır.

3. Mimariye Bakış

3.1. Nasıl görünüyor?

Bence Beowulf süper bilgisayar mimarisini açıklamanın en iyi yolu gerçek Beowulf'a mümkün olduğunca benzeyen bir bilgisayar üzerinde örnekler vermektir. Ben örnek olarak, USQ Faculty of Science'deki, DEC Alpha bilgisayar laboratuvarını kullanacağım. Buradaki sunucu makineye beldin adı verilmiş ve istemci makineler de scilab01, scilab02, scilab03, ...,scilab20 şeklinde isimlendirilmiş. Bütün istemci makinelere Digital Unix 4.0'ın yerel bir kopyası kurulmuş fakat, kullanıcı alanı (/home ve /usr/local) NFS yoluyla sunucudan temin edilmekte. Her bir kullanıcının sunucuya bir girisi var ve diğer bütün istemci bilgisayarların isimleri /etc/hosts.equiv dosyasında yazılı ve bu yolla her bir istemci bir diğer isteci makinesinde bir kabuk (rsh yoluyla) çalıştırabiliyor. Sunucu makine bütün laboratuvar için bir NIS sunucusu olduğundan dolayı, kullanıcı hesapları bilgileri bütün makinelerde aynı. Bir kullanıcı scilab02 konsolunun başına oturup sisteme giriş yaptıktan sonra, aynı zamanda sunucuya ya da scilab15 makinesine de giriş yapmış olur. Bütün istemci makinelerde aynı işletim sistemi aynı şekilde yüklenmiştir ve bilgisayar yapılandırmaları aynıdır. Her kullanıcı sisteme giriş yapmak suretiyle NFS yoluyla sunucuda kendisine ait olan /home ve /usr/local dizinlerine fiziksel olarak erişme hakkında sahiptir. NIS ve NFS ile ilgili daha fazla bilgi için bu konularla ilgili olan NASIL'ları okumalısınız.

3.2. Diğer düğümler nasıl kullanılacak?

Şimdi, sistem mimarisi ile ilgili az da olsa fikrimiz olduğuna göre, laboratuvadaki diğer makinelerin sahip olduğu işlemcilere nasıl ulaşabileceğimize bakalım. Herhangi bir kullanıcı, herhangi bir makine ile sistme giriş yapıp, kendi /home dizinindeki bir programı çalıştırabilir. Ve aynı programı basit bir şekilde başka makinelerin kabukları üzerinde de çalıştırabilir. Örneğin, farzedelim ki 1 ile 10 arasındaki sayıların sırası ile karelerini alarak toplayamak istiyoruz. Bu basit progamı sigmasqrt ismi ile yazdık; bu kaynak kodu sigmasqrt.c bölümünde bulabilirsiniz. Şimdi 1 ile 10 arasındaki sayıların karelerinin toplamını bulmak için programı çalıştırıyoruz:

[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10
22.468278

real    0m0.029s
user    0m0.001s
sys     0m0.024s

Kullandığım time komutu Unix'de bir işin başlangıcından son buluşuna değin geçen zamanı öğrenmeyi sağlar. Gördüğünüz gibi bu örnek çok küçük bir zaman içerisinde gerçekleştirildi (0.029s). Peki biz 1 ile 1 000 000 000 arasındaki sayıların kareleri toplamını hesaplamak isteseydik ne olurdu? Şimdi hesaplamayı deneyelim ve çalışma süresine bakalım.

[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
21081851083600.559000

real    16m45.937s
user    16m43.527s
sys     0m0.108s

Bu kez, programın çalışması çok daha uzun zaman aldı. Kendimize sormamız gereken en önemli soru, programın çalışma hızını nasıl arttırabiliriz? Nasıl bir yol izlemeliyiz ki yaptığımız değişiklik programın çalışma zamanını düşürsün? Cevap kesinlikle şudur ki, programın çalışmasını belirli kısımlara ayırmalı ve bu alt işleri bütün koşut bilgisayarlara dağıtmalıyız. Örneğin bu laboratuvarı göz önünde bulunduracak olursak, büyük bir işi buradaki 20 bilgisayara bölmeli ve her birinin gönderdiği sonucu bir araya getirerek asıl sonucu bulmalıyız. Programı çalıştırmadan önce, geri dönecek olan değerleri bir araya toplamak için bu yazma işlemini gerçekleştirecek bir boruhattı oluşturmalıyız.

[jacek@beldin sigmasqrt]$ mkfifo output
[jacek@beldin sigmasqrt]$ ./prun.sh & time cat output | ./sum
[1] 5085
21081851083600.941000
[1]+  Done                    ./prun.sh

real    0m58.539s
user    0m0.061s
sys     0m0.206s

Bu kez işlem yaklaşık 58.5 saniye zaman aldı. Bu süre bilgisayarların işi yapmaya başlamalarından, bütün düğümlerden gelen sonuçların boruhattına yazılmasına kadar geçen zaman. Bu süreye 20 sonucunda dönmesinin ardından hepsinin toplanarak gerçek sonuca ulaşılma zamanı dahil değildir fakat, bu süre saniyenin çok küçük bir parçası olduğundan dolayı gözardı edilebilir. Bu örnekle, koşut çalışmanın ne denli önemli olduğunu görmüş olduk. Neticede yaptığımız ilk işleme göre yaklaşık 17 kat daha hızlı çalıştı ve bunun için 20 işlemciyi bir araya getirmiş olduk. Yukarıda verdiğimiz örneğin amacı birazda, en basit haliyle koşut çalışma prensibi için gerekli olan kodun nasıl olacağınıda göstermekti. Çok mükemmel ve değişik teknikler de (PVM ve PMI API'leri) koşutluk kullanılarak başarıya ulaştırılmaktadırlar.

3.3. Beowulf ile COW arasındaki fark nedir?

Bilgisayar laboratuvarı bize İşistasyonu Topluluğunun (COW - Cluster of Workstations) açıklaması için çok iyi bir örnek teşkil etti. Peki Beowulf`u özel hale getiren şey nedir ve bir COW ile arasındaki fark nedir? Doğruyu söylemek gerekirse, aslında pek fazla farkları yoktur fakat, Beowulf`u özel kılan bir kaç karekteristik özellik vardır. Bunların ilki, çoğu Beowulf sistemi istemci makinesinde, klavye, fare, monitör ya da ekran bağdaştırıcı kartları gibi aygıtlar yoktur. İstemci makinelere tüm erişim yalnızca sunucu düğümünden yapılan bağlantılar sayesinde gerçekleştirilir. Çünkü, ne bir istemci makinenin topluluğun dışındaki bir makineler ile haberleşmesine ne de topluluğun dışındaki bir makinenin direk olarak topluluğun içerisindeki bir istemci bilgisayara erişmesi gerekli değildir. Topluluk içerisindeki istemci bilgisayarlar 10.0.0.0/8 yada 192.168.0.0/16 gibi ozel IP adresleri kullanırlar (RFC 1918 http://www.alternic.net/rfcs/1900/rfc1918.txt.html). Çoğunlukla bir tek bilgisayar dış dünyaya ikinci bir ağ kartı ile bağlanır ve bu bilgisayar da sunucu düğümüdür. Sistemi kullanmak için uygulanan yollardan en kullanışlısı, doğrudan sunucu uçbiriminden erişmek ya da, erişimi uzaktan telnet ya da buna benzer uzaktan sisteme giriş uygulamaları aracılığı ile sağlamaktır. Sistemi kullanmaya yetkili kullanıcılar, kodlarını sunucu düğümünde oluturşup, çalıştırabilir ve program çalışırılırken sistemin bütün düğümlerinin bu çalışmaya katılmasını sağlayabilirler. Çoğu durumda COW`lar kullanılarak gerçekleştirilmek istenen koşut hesaplamalar ve işler geceleri ya da insanların ağdaki bilgisayarları kullanmadıkları haftasonu, tatil gibi günlerde yapılabilir. Ancak bu şekilde işlemci performansı maksimum olur ve kullanıcılar sistemin yavaşlığından yakınmazlar. Beowulf'un diğer bir getirisi de budur ki, Beowulf makineler her zaman koşut hesaplama uygulamalarına hazırdır ve bu işi en iyi şekilde gerçekleştirebilmesi için eniyilenmişlerdir. Beowulf aynı zamanda, kullandığı kullanıma hazır donanımlar ve çalışması için gerekli olan programların bedava olmasıyla muazzam bir fiyat/performans oranı sergiler.

4. Sistem Tasarımı

Herhangi bir donanıma para verip satın almadan önce, sisteminizin yapısını hesaba katarak iyi bir şekilde düşünmek pek isabetli olacaktır. Basit olarak sisteminizin ihtiyac duyacağı donanımları kararlaştırmadan önce sisteminizi oluşturacak olan kısımları iki ana başlık altında toplayabiliriz: Kullanacağınız bilgisayarların ya da düğümlerin yapıları ve bu bilgisayar düğümlerini birleştirmek için izleyeceğiniz yolun ne olduğu. Sizin donanım kararlarınızı etkileyecek olan yazılım sorunu, API kütüphanesinde karşınıza çıkacaktır. Donanım ve iletişim yazılımlarının daha ayrıntılı açıklaması bu belgenin devamında yapılacaktır.

Seçenek sayısı çok çok fazla olmadığında, "Beowulf" sistemiyle karşılaştırıldığında alınması gereken bazı yapı kararları vardır. "Koşut Hesaplama" bilimi (sanatı?) hakkında birçok farklı görüş olduğu için aşağıda konuyla ilgili kısa bir giriş bulunmaktadır. Eğer bu temel bilgileri okumak istemezsenis bu bölümü geçebilirsiniz. Ancak sistemle ilgili son kararlarınızı vermeden önce Uygunluk bölümünü okumanız tavsiye edilmektedir.

4.1. Koşut Hesaplama üstüne temel bilgiler

Bu bölüm "Koşut Hesaplama" sistemi üzerine temel bir bilgi sağlamayı amaçlamıştır. bu bilgiler Koşut Hesaplama bilim ve teknolojisini tam bir tanımını yapmamaktadır. Sadece, "Beowulf" tasarımcı ve kullanıcıları için önemli olacak kısa bir tanımdır.

Beowulf sistemini kurarken kararınızın doğru olması için önemli olacak birçok konu aşağıdaki bölümde tanımlanmaktadır. Sistemin bileşim mantığına bağlı olarak, bir Beowulf Super Bilgisayarı, herşeyi ile bizim kontrolümüz altında olduğu için, bir çok etkeni dikkatlice düşünmemizi gerektirir. Genelde Koşut Hesaplama ile ilgili konuları anlamak hiç de zor değildir. Aslında konular anlaşıldığında beklentileriniz daha gerçekçi ve başarınız daha muhtemel olacaktır. Başarı hızının tek ve en önemli faktör olduğu "ardışık evren"'in aksine başarı hızı, "koşut evren"'de sistemin başarı ve yeterliliğini sağlayacak bir çok etkenden sadece biridir.

4.2. Koşut Hesaplama Yöntemleri

Koşut Hesaplama, kullanıcının perspektifine bağlı olarak birçok biçim alabilir. Her yöntemin getirilerinin ve götürülerinin olduğu düşünülmelidir. Aşağıdaki bölüm Koşut Hesaplama yöntemleri hakkında bazı yaklaşımlar sunmakta ve Beowulf makinelerinin bu yaklaşımın neresinde olduğunu göstermektedir.

4.2.1. Neden birden fazla işlemci?

Bu soruyu cevaplandırmak önemlidir. Kelime işlemciniz için 8 işlemci kullandığınızı düşünün. Bu biraz lüks olur gercekten. Fakat bir web sunucusunun, bir veritabanının, dönüştürücü bir programı ya da proje tasarımcısının çalıştırıldığı bir makine için fazladan işlemcilerin bir faydası olabilir. Örneğin karmaşık bir benzetim de kesinlikle fazladan işlemcilerin katkısı olacaktır. Ve kesinlikle, çoklu işlemci kullanımı ile çok çok ağır ve zor sorunların çözümleri kolaylaşmıştır.

Şimdi sorulacak soru ise muhtemelen, "Neden 986 süper-turbo-hiper-hede-hödö-çip için beklemek yerine 2 ya da 4 işlemci kullanayım ki?" olacaktır. İşte size birkaç neden:

  1. Çok görevli işletim sistemlerinden beklenen şey aynı anda birden fazla görevi yerine getirebilmektir. Ve bu zaten doğal bir koşutçuluktur ve birden fazla ucuz işlemci ile çok daha yüksek performans gosterebilir.

  2. Her 18 ayda hızları ikiye katlanan işlemciler üretiliyor. Peki ya RAM ya da HDD hızları? Ne yazık ki bu aygıtların hızları işlemci hızlarının arttırıldığı kadar hızlı arttırılamıyor. Çoğu kez karşılaşmışızdır, kullandığımız programlarda "yetersiz bellek alanı" ya da "düşük sabit disk kapasitesi" gibi uyarı mesajları ile. Ve şu bir gerçektir ki, sistem kullandığı donanımların en yavaşı hızında çalışacaktır. Ve koşutçuluk mantığı bu sınırların yükseltilmesi için varolan tek yoldur.

  3. Tahminlere göre, işlemci hızları 2005 yılından sonra şimdi olduğu gibi her 18 ayda ikiye katlanamayacak. Ve bu yükselişin devamını engelleyecek olan çok ciddii sorunlar ortaya çıkacak.

  4. Hıza ihtiyaç duyan bir uygulama çalıştırılacağında, Koşut Hesaplama ile hızı 2 ila 500 kat arttırmak mümkündür (hatta bazı durumlarda daha bile fazla). Bu performansı tek bir bilgisayardan almanın mümkünatı yoktur. Önceleri üretilen Super Bilgisayarlar bir tane özel işlemci kullanırken, artık üretilen Super Bilgisayarlara çok sayıda normal işlemci koyma yoluna gidilmektedir.

Eğer sağlıklı olan (bilgisayarınızın herhangi bir I/O problemi ya da donanımsal bir problemden ötürü sorun yaşamadığı durum) makinenizin hızı gerçekleştirdiğiniz ileri uygulamaların ihtiyacına cevap veremeyecek kadar yavaşsa, koşutluk sorununuza çözüm getirebilir.

4.2.2. Koşut Hesaplama Mağazası

Varsayalım ki büyük bir mağazanın ön kısmında grup halinde 8 tane kasiyer var. Ve her kasiyer bir işlemci olsun. Ve bu mağazanın içindeki her müşteride bir bilgisayar programı. Aşağıdaki örnekler bu alışverişi örneklemek için kullanılabilir.

4.2.2.1. Tek Görevli İşletim Sistemleri
Bir kasiyer (işlemci) her an kullanımdadır ve her seferinde sadece bir müşterinin ihtiyacına yanıt verebilir, sıradaki müşteri kendisinden önceki müşterinin kasiyer ile işini bitirmesini beklemelidir.

Örnek İşletim Sistemi: MS DOS

4.2.2.2. Çok Görevli İşletim Sistemleri
Yine sadece bir kasiyer açıktır ve her an kullanımdadır ama bu sefer müşterilerin aldığı malzemeler parçalara bölünerek her birinin sırayla bir parçası işlenir. Hepsini bir hat üzerinde düşünecek olursak, müşteriler bu hat üzerinde hareket ederek kasiyerin kendileriyle de ilgilenmesini sağlarlar. Eğer sadece bir tek hattımız varsa (bir işlemcimiz varsa), yapmamız gereken şey bu hattı mümkün olduğunca hızlandırmaktır.

Örnek İşletim Sistemi: Tek işlemcili UNIX ve NT

4.2.2.3. Çok İşlemcili Çok Görevli İşletim Sistemleri
Şimdi müşterilerle ilgilenebilecek birkaç kasiyer daha var. Bu durumda her bir müşteri farklı bir kasiyerden alışveriş yapabilir ve hat daha hızlı hareket eder. Bunun adı Bakışımlı Çok İşlemcililik (SMP - Symmetric Multi-Processing)'dir. Her ne kadar fazladan kasiyer açık olsa da, hiçbir zaman bir kasiyer ve bir müşteri hızının üstünde bir performans alamayacaksınız.

Örnek İşletim Sistemi: Çok işlemcili UNIX ve NT

4.2.2.4. Çok İşlemcili Çok Görevli İşletim Sistemlerinde Kanallama
Eğer isteklerinizi belirli parçalara bölerseniz, aynı zamanda birçok kasiyer kullanarak hattın devinimini hızlandırabilirsiniz. İlkönce çok miktarda ürüne sahip olduğumuzu düşünelim. Siparişlerinizi bölümlerine ayırırken kaybettiğiniz zamanı bir çok kasiyer kullanmanın size kazandıracağı hızdan geri kazanabilirsiniz. Teorik olarak öncekine göre işlem hızının kasiyer sayısı kadar katlanması gerekli. Bilgisayarlar birbirleri arasında çok hızlı bir şekilde iletişim kurarak daha önceden parçalanmış olan işlemden kendilerine düşen kısmın sonucunu birbirlerine iletirler. İşin daha hızlı sona erdirilmesi için gerekli olan bir bilgiye ulaşmak için bilgisayarlar birbirlerinin işlerine burunlarını sokabilirler. Herhangi bir yerde bir mağazanın etkili biçimde çalışabilmesi için kaç tane kasa olması gerektiği çok önemlidir ve bir sınıra sahiptir.

Örnek İşletim Sistemi: Aynı anakart üzerinde çok işlemci bulunan bir makinada çok kanallı uygulamalar çalıştıran UNIX ve NT.

4.2.2.5. Çok İşlemcili Çok Görevli İşletim Sistemlerinde İletilerin Gönderilmesi
Performansınızı artırmak için mağazanın arka kısmına 8 kasa daha eklensin. Bu durumda kasiyerler birbirinden uzak olacaklarından ara toplamları birbirlerine telefon yoluyla bildirmeleri gerekecektir. Bu uzaklık kasiyerler arasındaki iletişimin sağlanması için fazladan bir zaman gerektirecektir. Fakat bu iletişim bir şekilde azaltılabilirse problem olmaz. Bütün kasiyerleri kullanmak zorunda olduğunuz büyüklükte bir siparişe sahipseniz bu işe başlamadan önce kasiyerlerin iletişimi esnasında kaybedilecek zamanı düşünmelisiniz. Bazı durumlarda mağaza, bütün mağazalar arasında yerleşmiş tek bir kasiyere sahip olabilir. Bu durumda bütün kasiyerler birbirleri ile telefon yoluyla görüşmelidir. Ve dolayısıyla bulundukları yer sonun teşkil etmeyecekir.

Örnek İşletim Sistemi: İleti gönderirken aynı veya farklı anakart üzerinde çok işlemcili UNIX ya da NT'nin bir ya da birden fazla kopyasının olması durumu.

4.3. Koşut Hesaplama Mimarileri

Koşut Hesaplama mimarisi ve genel teknikleri aşağıda sunulmaktadır. Bu tanımlar çok ayrıntılı değillerdir fakat Beowulf tasarımının içerdiği temel konuları anlamak için yeterlidir.

4.3.1. Donanım Mimarileri

Koşut Hesaplama donanımını bir araya getirmek için temel olarak iki yol vardır:

  1. İletilerle haberleşen paylaşımsız bellekli makineler. (Beowulf Toplulukları)
  2. Bellek üzerinden haberleşen paylaşımlı bellekli makinalar (SMP makinaları)

Tipik bir Beowulf sistemi, hızlı ethernet kullanarak bağlanan tek işlemcili makinelerin biraradalığıdır. Bu sebeple paylaşımsız bellekli[1] bir makinedir. 4 yollu SMP kutusu, paylaşımlı bellekli bir makinedir ve paylaşımlı bellek kullanarak iletişim sağlayan koşut uygulamalar sayesinde koşut hesaplama için kullanılabilir. Paylaşımlı bellekli makinelerdeki işlemcilerin sayısı belleğin içeriğine bağlı olarak sınırlandırılırken, paylaşımsız bellekli makineler çok sayıdaki işlemcilere göre ayarlanır.

Paylaşımlı bellekli melez bir makine yaratmak için birçok paylaşımlı bellekli makine arasında bağlantı sağlamak mümkündür. Programcıya tek bir bellek olarak göründüğü ve farklı gecikme sürelerine sahip olan işlemciler tarafından paylaşıldığı için bu melez makineleri kullanıcıya tek parça ve büyük bir SMP makinesi gibi görünür ve bu NUMA (Non Uniform Memory Access) olarak adlandırılır. Ancak bazı seviyelerde bir NUMA makinesi paylaşımsız bellek havuzları arasında mesaj diyaloğunu sağlayabilmelidir. Aynı zamanda, SMP makinesini paylaşımsız bellekli bilgisayar düğümü olarak bağlayabilir.

Tipik bir 1. sınıf anakart, ya 2 ya da 4 işlemciye sahiptir ve sistemin bütün maliyetini azaltmak için bir araç olarak kullanılabilir. Linux'un dahili yapılandırması bu işlemcilerin nasıl paylaşılacağını belirler. Bu noktada kullanıcı, herhangi bir SMP işlemcisini özel bir amaca tahsis edemez, işlemler için işlemci tahsisinden sadece Linux sorumludur. Kullanıcı ancak 2 bağımsız işlemci ile ya da bir bağlantılı işlemci ile başlayabilir ve bu durumda tek bir işlemci üzerinde performans artışı görebilir.

4.3.2. Yazılımsal Mimariler

Bir uygulamada çok görevliliği ifade etmenin iki yolu vardır:

  1. İşlemciler arasında gönderilen iletileri kullanmak
  2. İşletim sistemi kanallarını (thread) kullanmak

Bunun için başka yöntemler de vardır ama en yaygın olarak bu ikisi kullanılır. Çok görevliğin ifade edilmesinin belirli bir donanımla kontrol edilen bir gereklilik olmadığını unutmamak gerekir. Öbekleşmiş sistemlerde, SMP'de ve NUMA-SMP'de uygulanabilen İletiler ve Kanallar ile verimlilik ve uydurulabilirlik önemli konulardır ve aşağıda açıklanmıştır.

4.3.2.1. İletiler
İleti aktarım teknolojisi ilk paylaşımsız bellekli koşut bilgisayar tasarımını akla getirdi. Kanallama bir yerde verileri kullanırken, iletiler, kopyalanmış verileri kullanır. İletilerin kopyalanmasındaki gecikme ve hız ileti aktarım yöntemlerinde sınırlayıcı bir faktördür. Bir iletinin içeriği oldukça basittir: bazı veriler ve verilerin gönderileceği işlemci adresi. Genel ileti aktarım API'lerı PVM ve MPI'dır. İleti aktarımı, hem SMP makinelerinde hem de makine öbekleri arasında iyi çalışan kanllar ve iletilerle sağlanabilir. Bir SMP makinesinde kanallama yerine iletileri kullanmanın getirisi, eğer ilerde öbekleri kullanmaya karar verirseniz uygulamalarınızı ayarlamakta ya da makinenize ilave yapmakta kolaylık sağlaması olacaktır.

4.3.2.2. Kanallama
Paylaşımlı bellekli SMP tasarımları çok hızlı paylaşımlı bellek iletişimini ve bir programın uyumlu bölümleri arasındaki eşzamanlamayı sağladığı için, işletim sistemi kanalları (threads) geliştirilmiştir. İletişim paylaşımlı bellek sayesinde olduğu için, kanallama SMP sisteminde çok düzenli bir şekilde çalışır. Bundan dolayı, kullanıcı yerel verileri global verilerden ayırmalıdır, aksi taktirde programlar uygun şekilde çalışmayacaktır. İletilerin aksine veriler, süreçler (kanallar) arasında paylaşıldığı için çok sayıdaki kopya kanallarla seçilebilecektir. Linux POSIX kanallarını (POSIX threads) desteklemektedir. Bağlantılarla ilgili sorun, verilerin tek SMP makinesinden fazlasına genişletmedeki zorluk ve veriler işlemciler arasında paylaşıldığı için arabellek tutarlılığı konularının genele katılabilmesidir. Kanalların SMP sınırlarının ötesine genişletilmesi pahalı ve aynı zamanda da doğal olarak Linux tarafından desteklenmeyen NUMA teknolojisini gerektirmektedir. İletiler üzerinde kanalların uygulanması yapılmış bir şeydir (http://syntron.com/ptools/ptools_pg.htm/), fakat kanallar ileti kullanımı uygulamasında genelde yetersiz kalmıştır.

Aşağıda performansların nasıl olacağı belirtilmektedir:

              SMP makinası     Makina toplulukları  Ölçeklenebilirlik
              performansı        performansı
              ------------     -------------------  -----------------
    iletiler     good                  best               best

    kanallar     best                  poor*              poor*

    * Pahalı bir NUMA teknolojisi gerekir.

4.3.3. Uygulama Mimarisi

Bir uygulamanın çok sayıda işlemci üzerinde koşut olarak çalıştırılabilmesi için birbiriyle uyumlu çalışan parçalara net bir şekilde ayrılması gereklidir. Standart bir tek işlemci uygulaması, çok işlemcili bir bilgisayarda tek işlemcili bir bilgisayarda çalıştığından daha hızlı çalışmayacaktır. Programları çoklu işlemeye uygun hale getirmek için parçalara ayıran bazı uygulamalar vardır fakat, koşutlama kodları tak ve çalıştır değildir. Uygulamaya bağlı olarak koşutlama kodları kolay olabileceği gibi son derece zor da olabilir veya bazı durumlarda algoritma bağlantılarına göre imkansız olabilir.

Yazılımla ilgili konulara geçmeden önce uygunluk kavramının üzerinde durulması gerekmektedir.

4.4. Uygunluk

Koşut hesaplama hakkındaki bir çok sorunun cevabı şu olur:

"Herşey uygulamaya bağlıdır."

Bu konuya geçmeden, önce UYUMLULUK ve KOŞUTLUK arasındaki farkın çözülmesi çok önemlidir. Bu tartışmanın amacına uygun olarak öncelikle bu iki konunun tanımlamalarını yapacağız:

UYUMLULUK: Bir programı oluşturan parçalar birbirinden bağımsız hesaplanabilir.

KOŞUTLUK: Yukardaki UYUMLULUK kuralına uygun ayrılmış parçalar ayrı işleme ünitelerinde aynı anda hesaplanabilir.

Bu farklılık çok önemlidir çünkü, UYUMLULUK programın bir özelliğidir ve KOŞUTLUK da makinenin bir özelliğidir. Neticede KOŞUT çalışma en yüksek performansı doğurmalıdır. Koşutluğun başarımını sınırlayan etkenlerin başında, düğümler arasındaki haberleşme hızı ve düğümler arasındaki gecikmedir. Genel koşut başarımının ölçümleri çoğunlukla koşutluk, iletişim ve gecikmeye göredir ve bunlar işi zorlaştırmaz. Bu “alenen koşutluk” olarak adlandırılır (gecikme arabellek tutarlılığına bağlı olan SMP uygulamalarıyla oluşur). Diğer uygulamalar bu kadar basit değildir ve programn UYUMLU parçalarının KOŞUT olarak çalıştırılması programın çalışmasını yavaşlatabilir, bunun dengelenmesi, programın diğer UYUMLU parçalarının başarımının artışını sağlar. Basitçe söylemek gerekirse, iletişim zamanının fiyatı hesaplama zamanındaki kazançla karşılanır, aksi takdirde UYUMLU parçanın KOŞUT çalıştırılması verimsiz olur.

Programcının görevi, programın UYUMLU bölümlerinin hangilerinin KOŞUT çalıştırmaya konu olacağına karar vermektir. Bu soruların cevabı uygulamadaki VERİM‘i belirleyecektir. Aşağıdaki grafik programcı için durumu özetler:

             | *
             | *
             | *
   uygulama  | *
    sayısı   |  *
   % olarak  |  *
             |  *
             |  *
             |    *
             |     *
             |      *
             |        ****
             |            ****
             |                ********************
             +-----------------------------------
              iletişim süresi/işlem süresi

İyi bir koşut bilgisayarda iletişim ve işlem oranı birbirine eşit olacak ve UYUMLU olan herhangi bir şey KOŞUT olarak da uygulanabilecektir. Ne yazık ki, paylaşımlı bellekli makineleri içeren gerçek koşut bilgisayarlar y=1/x grafiğindeki etkilere tabidirler. Beowulf yaratırken, kullanıcı bu grafiği aklında tutmak isteyebilir çünkü BELLİ BİR KOŞUT BİLGİSAYAR için koşutluk verimi, iletişim ve işlem zamanının oranına bağlıdır. Uygulamalar koşut bilgisayarlar arasında taşınabilirlik özelliğine sahiptir fakat bunların farklı platformlarda verimli olacağının garantisi yoktur.

GENEL OLARAK, HEM TAŞINABİLİR HEM DE VERİMLİ KOŞUT UYGULAMA DİYE BİR ŞEY YOKTUR.

There is yet another consequence to the above graph. Since efficiency depends upon the comm./process. ratio, just changing one component of the ratio does not necessary mean a specific application will perform faster. A change in processor speed, while keeping the communication speed that same may have non- intuitive effects on your program. For example, doubling or tripling the CPU speed, while keeping the communication speed the same, may now make some previously efficient PARALLEL portions of your program, more efficient if they were executed SEQUENTIALLY. That is, it may now be faster to run the previously PARALLEL parts as SEQUENTIAL. Furthermore, running inefficient parts in parallel will actually keep your application from reaching its maximum speed. Thus, by adding faster processor, you may actually slowed down your application (you are keeping the new CPU from running at its maximum speed for that application)

UPGRADING TO A FASTER CPU MAY ACTUALLY SLOW DOWN YOUR APPLICATION

So, in conclusion, to know whether or not you can use a parallel hardware environment, you need to have some insight into the suitability of a particular machine to your application. You need to look at a lot of issues including CPU speeds, compiler, message passing API, network, etc. Please note, just profiling an application, does not give the whole story. You may identify a computationally heavy portion of your program, but you do not know the communication cost for this portion. It may be that for a given system, the communication cost as do not make parallelizing this code efficient.

A final note about a common misconception. It is often stated that "a program is PARALLELIZED", but in reality only the CONCURRENT parts of the program have been located. For all the reasons given above, the program is not PARALLELIZED. Efficient PARALLELIZATION is a property of the machine.

4.5. Writing and porting parallel software

Once you decide that you need parallel computing and would like to design and build a Beowulf, a few moments considering your application with respect to the previous discussion may be a good idea.

In general there are two things you can do:

  1. Go ahead and construct a CLASS I Beowulf and then "fit" your application to it. Or run existing parallel applications that you know work on your Beowulf (but beware of the portability and efficiently issues mentioned above)
  2. Look at the applications you need to run on your Beowulf and make some estimations as to the type of hardware and software you need.

In either case, at some point you will need to look at the efficiency issues. In general, there are three things you need to do:

  1. Determine concurrent parts of your program
  2. Estimate parallel efficiently
  3. Describing the concurrent parts of your program

Let's look at these one at a time.

4.5.1. Determine concurrent parts of your program

This step is often considered "parallelizing your program". Parallelization decisions will be made in step 2. In this step, you need to determine data dependencies.

>From a practical standpoint, applications may exhibit two types of concurrency: compute (number crunching) and I/O (database). Although in many cases compute and I/O concurrency are orthogonal, there are application that require both. There are tools available that can perform concurrency analysis on existing applications. Most of these tools are designed for FORTRAN. There are two reasons FORTRAN is used: historically most number crunching applications were written in FORTRAN and it is easier to analyze. If no tools are available, then this step can be some what difficult for existing applications.

4.5.2. Estimate parallel efficiency

Without the help of tools, this step may require trial and error tests or just a plain old educated guess. If you have a specific application in mind, try to determine if it is CPU limited (compute bound) or hard disk limited (I/O bound). The requirements of your Beowulf may be quite different depending upon your needs. For example, a compute bound problem may need a few very fast CPUs and high speed low latency network, while an I/O bound problem may work better with more slower CPUs and fast Ethernet.

This recommendation often comes as a surprise to most people because, the standard assumption is that faster processor are always better. While this is true if your have an unlimited budget, real systems may have cost constraints that should be maximized. For I/O bound problems, there is a little known rule (called the Eadline-Dedkov Law) that is quite helpful:

For two given parallel computers with the same cumulative CPU performance index, the one which has slower processors (and a probably correspondingly slower interprocessor communication network) will have better performance for I/O-dominant applications.

While the proof of this rule is beyond the scope of this document, you find it interesting to download the paper Performance Considerations for I/O-Dominant Applications on Parallel Computers (Postscript format 109K ) ftp://www.plogic.com/pub/papers/exs-pap6.ps

Once you have determined what type of concurrency you have in your application, you will need to estimate how efficient it will be in parallel. See Section Yazılım for a description of Software tools.

In the absence of tools, you may try to guess your way through this step. If a compute bound loop measured in minutes and the data can be transferred in seconds, then it might be a good candidate for parallelization. But remember, if you take a 16 minute loop and break it into 32 parts, and your data transfers require several seconds per part, then things are going to get tight. You will reach a point of diminishing returns.

4.5.3. Describing the concurrent parts of your program

There are several ways to describe concurrent parts of your program:

  1. Explicit parallel execution
  2. Implicit parallel execution

The major difference between the two is that explicit parallelism is determined by the user where implicit parallelism is determined by the compiler.

4.5.3.1. Explicit Methods
These are basically method where the user must modify source code specifically for a parallel computer. The user must either add messages using PVM or MPI or add threads using POSIX threads. (Keep in mind however, threads can not move between SMP motherboards).

Explicit methods tend to be the most difficult to implement and debug. Users typically embed explicit function calls in standard FORTRAN 77 or C/C++ source code. The MPI library has added some functions to make some standard parallel methods easier to implement (i.e. scatter/gather functions). In addition, it is also possible to use standard libraries that have been written for parallel computers. Keep in mind, however, the portability vs. efficiently trade-off)

For historical reasons, most number crunching codes are written in FORTRAN. For this reasons, FORTRAN has the largest amount of support (tools, libraries, etc.) for parallel computing. Many programmers now use C or re- write existing FORTRAN applications in C with the notion the C will allow faster execution. While this may be true as C is the closest thing to a universal machine code, it has some major drawbacks. The use of pointers in C makes determining data dependencies extremely difficult. Automatic analysis of pointers is extremely difficult. If you have an existing FORTRAN program and think that you might want to parallelize it in the future - DO NOT CONVERT IT TO C!

4.5.3.2. Implicit Methods
Implicit methods are those where the user gives up some (or all) of the parallelization decisions to the compiler. Examples are FORTRAN 90, High Performance FORTRAN (HPF), Bulk Synchronous Parallel (BSP), and a whole collection of other methods that are under development.

Implicit methods require the user to provide some information about the concurrent nature of their application, but the compiler will then make many decisions about how to execute this concurrency in parallel. These methods provide some level of portability and efficiency, but there is still no "best way" to describe a concurrent problem for a parallel computer.

5. Beowulf Kaynakları

5.1. Başlangıç Noktaları

5.2. Belgeler

5.3. Sayfalar

  • Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese, Donald Becker, and Phillip Merkey A Design Study of Alternative Network Topologies for the Beowulf Parallel Workstation. Proceedings Fifth IEEE International Symposium on High Performance Distributed Computing, 1996. http://www.beowulf.org/papers/HPDC96/hpdc96.html
  • Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling Becker, and Phillip Merkey. Harnessing the Power of Parallelism in a Pile-of-PCs. Proceedings, IEEE Aerospace, 1997. http://www.beowulf.org/papers/AA97/aa97.ps
  • Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael R. Berry, and Chance Res. Achieving a Balanced Low-Cost Architecture for Mass Storage Management through Multiple Fast Ethernet Channels on the Beowulf Parallel Workstation. Proceedings, International Parallel Processing Symposium, 1996. http://www.beowulf.org/papers/IPPS96/ipps96.html
  • Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce Fryxell, Kevin Olson. Communication Overhead for Space Science Applications on the Beowulf Parallel Workstation. Proceedings,High Performance and Distributed Computing, 1995. http://www.beowulf.org/papers/HPDC95/hpdc95.html
  • Donald J. Becker, Thomas Sterling, Daniel Savarese, John E. Dorband, Udaya A. Ranawak, Charles V. Packer. BEOWULF: A PARALLEL WORKSTATION FOR SCIENTIFIC COMPUTATION. Proceedings, International Conference on Parallel Processing, 95. http://www.beowulf.org/papers/ICPP95/icpp95.html
  • Papers at the Beowulf site http://www.beowulf.org/papers/papers.html

5.4. Yazılım

5.5. Beowulf Makinalar

5.6. Diğer ilgi çekici siteler

5.7. Geçmiş

6. Kaynak Kod

6.1. sum.c

/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include <stdio.h>
#include <math.h>

int main (void) {

  double result = 0.0;
  double number = 0.0;
  char string[80];
  

  while (scanf("%s", string) != EOF) {

    number = atof(string);
    result = result + number;
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}

6.2. sigmasqrt.c

/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include <stdio.h>
#include <math.h>

int main (int argc, char** argv) {

  long number1, number2, counter;
  double result;
  
  if (argc < 3) {
    printf ("usage : %s number1 number2\n",argv[0]);
    exit(1);
  } else {
    number1 = atol (argv[1]);
    number2 = atol (argv[2]);
    result = 0.0;
  }

  for (counter = number1; counter <= number2; counter++) {
    result = result + sqrt((double)counter);
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}

6.3. prun.sh

#!/bin/bash
# Jacek Radajewski jacek@usq.edu.au
# 21/08/1998

export SIGMASQRT=/home/staff/jacek/beowulf/HOWTO/example1/sigmasqrt

# $OUTPUT must be a named pipe
# mkfifo output

export OUTPUT=/home/staff/jacek/beowulf/HOWTO/example1/output

rsh scilab01 $SIGMASQRT         1  50000000 > $OUTPUT < /dev/null&
rsh scilab02 $SIGMASQRT  50000001 100000000 > $OUTPUT < /dev/null&
rsh scilab03 $SIGMASQRT 100000001 150000000 > $OUTPUT < /dev/null&
rsh scilab04 $SIGMASQRT 150000001 200000000 > $OUTPUT < /dev/null&
rsh scilab05 $SIGMASQRT 200000001 250000000 > $OUTPUT < /dev/null&
rsh scilab06 $SIGMASQRT 250000001 300000000 > $OUTPUT < /dev/null&
rsh scilab07 $SIGMASQRT 300000001 350000000 > $OUTPUT < /dev/null&
rsh scilab08 $SIGMASQRT 350000001 400000000 > $OUTPUT < /dev/null&
rsh scilab09 $SIGMASQRT 400000001 450000000 > $OUTPUT < /dev/null&
rsh scilab10 $SIGMASQRT 450000001 500000000 > $OUTPUT < /dev/null&
rsh scilab11 $SIGMASQRT 500000001 550000000 > $OUTPUT < /dev/null&
rsh scilab12 $SIGMASQRT 550000001 600000000 > $OUTPUT < /dev/null&
rsh scilab13 $SIGMASQRT 600000001 650000000 > $OUTPUT < /dev/null&
rsh scilab14 $SIGMASQRT 650000001 700000000 > $OUTPUT < /dev/null&
rsh scilab15 $SIGMASQRT 700000001 750000000 > $OUTPUT < /dev/null&
rsh scilab16 $SIGMASQRT 750000001 800000000 > $OUTPUT < /dev/null&
rsh scilab17 $SIGMASQRT 800000001 850000000 > $OUTPUT < /dev/null&
rsh scilab18 $SIGMASQRT 850000001 900000000 > $OUTPUT < /dev/null&
rsh scilab19 $SIGMASQRT 900000001 950000000 > $OUTPUT < /dev/null&
rsh scilab20 $SIGMASQRT 950000001 1000000000 > $OUTPUT < /dev/null&



[1] Ç.N.: Paylaşımlı bellek tabiri çok işlemcili bir makinada işlemcilerin aynı belleği paylaşması anlamındadır. Bu kabulden yola çıkarak tek işlemcili bir makinanın belleği için paylaşımsız bellek tabiri kullanılmıştır. Birebir çevirisi olan yerel bellekli çok daha anlamlı olmayacaktı.