28 Kasım 2009 Cumartesi

64-bit Pardus'un ilk performans test sonuçları

İki aydır aşkla çalıştığımız 64bit Pardus projesinin işletim sisteminin performansında nasıl bir fark oluşturacağını herkes gibi biz de merak ediyoruz. Daha önce başka işletim sistemleri için yapılmış olan testlerden çok farklı bir sonuç beklemesek bile madem elimizde bu imkan var değerlendirelim diyerek bu bayram gününü test için ayırdık. Neleri test edebileceğimiz konusunda fazla tercihimiz yoktu doğrusu, bu yüzden diğerleri neleri test etmişse biz de yaklaşık onları test ettik.

Önce elimizdeki olanakları sıralayayım ki "neden şunları denemediniz" diyecekler için bir açıklama olsun (yine de öneriniz olursa duymaktan mutlu oluruz):

* System.base ve system.devel'i 64bit paketlenmiş oldukça minimum (üzerinde çok uğraşıldığı için böyle demeye de dilim varmıyor ama neyse:)) bir Pardus'umuz var. Temel alınan sistem corporate2, yani kurumsal 2. Henüz bir grafik ortamımız yok. Testteki araçlardan lame ve gnupg'yi teste yetiştirmek için paketledik.

* Hızın bir işletim sistemi için herşey olmadığını biliyoruz.

* Denemelerde kullanığımız yazılımların tamamı çalışırken tek işlemci kullanabildiğinden ve RAM'i çok az kullandığından işlemci sayısını değiştirmek (evet, yaptık bunu) veya hafızayı arttırmak (bunu da denedik) farkedilebilir bir değişikliğe neden olmadı.

Testleri birbiriyle özdeş şu donanımlar ile yaptık:
* 4 X AMD Opteron(tm) Processor (2.3GHz)
* 4GB RAM

Kullandığımız yazılımlar ise şöyle:
* bc-1.06.95-5
* gnupg-2.0.11-26
* lame-3.98.2-11
* bzip2-1.0.5-10

İlk test faktöryel hesabı için bc ile yapıldı. 20000, 40000 ve 60000 faktöryeller hesaplandı.

$time bc factorial20k.bc > /dev/null

Yaklaşık %14 bir kazanç var.

İkinci test gnupg
ile Pardus-2009.iso (687MB) şifrelenerek yapıldı:

$time gpg --encrypt --recipient 'metin' Pardus-2009.iso

Yaklaşık %24 bir kazanç var.

Üçüncü test lame ile wav dosyasını (647MB) mp3 dosyasına çevrilerek yapıldı:

$time lame 32vs64.wav 32vs64.mp3

Yaklaşık %14 bir kazanç var.

Dördüncü ve son test bzip2 ile 687MB'lık bir dosyanın sıkıştırılmasıyla yapıldı:

$time bzip2 test_file.tar

Bu test sonucunda da yaklaşık %14 bir kazanç var. Bu sonuçlar değerlendirildiğinde 32bit ve 64bit Pardus arasında bir uçurum olmadığı ama kayda değer bir fark da olacağını söyleyebiliriz sanırım.

Her ne kadar sonuçlar olumlu çıkmış olsa da testleri yaparken sistemdeki işlemcilerden sadece birinin tam kapasite kullanıldığını kalanların ise hiç kullanılmadığını gördük. Bu elbette yazılımların çoklu işlemci kullanabilir olmamasından kaynaklanıyordu. "Eğer yazılımlar sistemdeki tüm işlemcileri verimli bir şekilde kullanabilseydi nasıl olurdu" diye düşünürken Metin bunu deneyebileceğimiz bir araç buldu. Biz sistemimize kurduğumuz bzip2 ile test yapmıştık ve birileri bzip2'yi paralel çalışacak hale getirmişti. İlk denemede gördük ki işlemcileri paralel kullanmak süreyi dramatik şekilde düşürüyor.

Paralel bzip2'yi kullanarak yine 687MB'lık bir dosyayı sıkıştırma testleri yaptık. Bu sefer işlemci sayısının da önemi olduğundan aynı makine üzerindeki işlemcileri de değiştirerek aşağıdaki grafiği elde ettik:

Sistemde tek işlemci varken kazanç %5 seviyesinde iken işlemci sayısı 8'e çıktığında kazanç da %15'e çıkıyor. Bu noktada tabi daha dikkat çekici olan programın paralel çalıştırılmasıyla elde edilen müthiş kazanım. Bu grafik iki veya dört çekirdekli, birden çok işlemcili bilgisayarlar alıp bunların aynı anda sadece birini kullanabilmek yerine tamamının verimli olarak kullanılabilmesi durumunda ortaya nasıl bir tablo çıkacağıyla ilgili bir ipucu veriyor.

Bir başka ekip de çıkıp "biz de paralel-pardus'u hazırlayalım" dese harika olur bence.

5 yorum:

  1. Hmm, neden 4 çekirdek ile 8 çekirdek arasında beklenen (x2) performans farkı yok sizce (tamamen bilgisayar mühendisliği ile ilgili bir merak bu, sizin ve öğrencilerinizin başarılı çalışması ile ilgili değil)?

    YanıtlaSil
  2. 4 çekirdekle 8 çekirdek arasında x2 fark olmasa da x1.74 gibi ona çok yakın bir fark var aslında. Eğer 16 çekirdekli bir test ortamımız olsaydı ondaki farkın da buna yakın olmasını tahmin ederdim.

    Uygulamanın paralel işlemci kullanmaya uygun yazılmış olmasıyla olmaması arasındaki fark göz yaşartıcı bence.

    YanıtlaSil
  3. Göz kararı oranı tam çıkaramamışım demek ki. 1.74 yeterince yüksek bence de. Evet, işlemleri paralel hale getirmek büyük hız farkları yaratacaktır günümüz çok çekirdekli mimarilerinde. Ancak önemli iki temel sorun var: 1) Her algoritma paralel hale getirilmeye uygun değil. 2) Multithread program yazmak gerçekten kolay bir iş değil. Araçların ve dillerin gelişmesiyle biraz daha kolaylaşması beklense de henüz kesin çözümü bulunamamış bir zorluk içeriyor.

    YanıtlaSil
  4. Tebrikler. Örnek oluyorsunuz bana, ayrıca teşekkürler.

    Hız farkıyla ilgili olarak, bildiğim kadarıyla; hızın net iki katına çıkmamasının sebebi işlemleri paylaştırıp tekrar birleştirme esnasında harcanan işlem gücü. Bu fark işlemci sayısı arttıkça küçülüyor ve hiç bir zaman net 2 kat hıza ulaşamasa da 2'ye yaklaşıyor.

    YanıtlaSil

Tutunacak bir geçmiş bırakmıyoruz

Yurtdışına çıkınca binaların ne kadar uzun süreler kullanıldığını görüp şaşırmamak elde olmuyor. Avrupalılar sadece tarihi değeri olan binal...