64bit ile ilgili ilk yazımdan[1] bu yana hep üzerinde durduğum şey bu çalışmaları bir öğrenim süreci olarak gördüğümüzdü. Bir işletim sistemini bir mimariden bir diğerine taşımak demek hem boot sürecini, hem paket yöneticisini, hem de işletim sisteminin geri kalanını detaylarıyla öğrenmek demek aslında. Sadece bunlarla da sınırlı değil öğrenme süreci; diğer paket yöneticileri nasıl çalışıyor, diğer dağıtımlar mimari farkı için paketlerde nasıl değişiklikler yapmışlar sorularına cevap verebilmek gerekiyor.
Bu öğrenme ve çalışma sürecinde en zor şey öğrendiklerini belgelendirmek. İnsan "bunları yazacağıma biraz daha çalışayım, başka şeyler öğreneyim" diye düşünüyor ama bu düşüncenin bizi hedefimizden uzaklaştıracağının da farkındayız. Aldığımız her notu henüz elektronik ortama geçirmemiş olsak bile (herkesin elinde not aldığı defterler var) sürecin temel aşamalarını wiki[2]'ye aktarmaya çalışıyoruz. Bu belge sürekli gelişme aşamasında, çünkü yazanlar sürekli öğreniyorlar ;)
RootFS'in hazır olduğunu bir süre önce yazmıştım[3]. Bir iki gün içinde bunu indirilebilir bir yere koyacağız. Elbette
RootFS sadece geliştiriciler için olacak. Meraklı ve heyecanlı son kullanıcılar en azından alfa sürümü beklemeliler.
Peki RootFS'i alan geliştiriciler ne yapacak? Elbette daha önce bir RootFS kullananlar için bir açıklama gerekmez ama yine de meraklılar için bir şeyler yazmak iyi bir fikir olabilir.
Her PiSi paketinin zaten bir geliştiricisi bulunduğundan ve pspec.xml ve actions.py dosyaları 32bit için hazırlanmış olduğundan 64bite geçişte yapılacak şey paketi sıfırdan hazırlamaya çalışmak değil. Bu aşamada yapılması gerekenleri wiki'de Paketlerin X86_64 Mimarisine Taşınmasında Yapılması Gerekenler bölümünde yazıyoruz ama burada da başlıkları yazayım. Merak eden wikiden devamına bakar herhalde.
64bite taşınırken inşa dosyalarında değişiklik gerektirecek paketler için altı farklı durum olabileceğini öngörüyoruz:
- farklı parametrelerle derlenenler
- ilave yamalar gerektirenler
- 32-bitte yapılan bazı yamaların çıkartılması gerekenler
- farklı kaynak dosyasına ihtiyaç duyanlar
- dosyaları farklı dizinlerde bulunduranlar
- x86_64 mimarisinde karşılığı bulunmayanlar
Geliştiricilerin bu durumlara uyan bir paketle karşılaşmaları durumunda bu değişikliği wikide uygun başlık altında yazmalarını bekliyor, karşılaştıkları sorunlara listede[4] beraber çözüm bulmayı umuyoruz.
[1] http://nyucel.blogspot.com/2009/07/64bit-pardus.html
[3] http://nyucel.blogspot.com/2009/11/64-bit-icin-rootfs-hem-hazr-hem-hazr.html
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.
