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.