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)
Kullandığımız yazılımlar ise şöyle:
İ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
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.
zaman: Kasım 28, 2009
Etiketler: 64bit, gezegen, pardus, test
suhaaktas 29 Kasım 2009 Pazar 10:37:00 GMT+2
Elinize emeğinize sağlık. :claps:
Melih 29 Kasım 2009 Pazar 18:47:00 GMT+2
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)?
Necdet Yücel 29 Kasım 2009 Pazar 22:02:00 GMT+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.
Melih 30 Kasım 2009 Pazartesi 00:24:00 GMT+2
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.
erkangur 1 Aralık 2009 Salı 23:27:00 GMT+2
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.
Babaların ve oğulların hikayeleri: Kurdun Postu
2019 Yaşar Nabi Nayır Öykü Ödülü'nü kazanan Batuhan Aşıktoprak'ın altı hikayesinden oluşan Kurdun Postu  Varlık ...
Hiçi İle Buluşma - Frederik Pohl
PiSi ve Bağımlılıkları
64-bit için rootfs hem hazır, hem hazır değil
64-bit ekibinden ilk ayrılış
Halford - Halford III - Winter Songs
H1N1 aşısı olmayacağım