mdakin's Pardus blog

JavaStruct ve yol ayrımı

2007-07-20T15:56:00.000+03:00

Yıllar önce soket haberleşmesi için tonlarca farklı türden mesajı kodlamak veya çözmek için işimizi kolaylaştıracak kodlar yazmıştık. Java sınıflarının C veya C++ structları gibi kullanılabilmesini sağlıyordu. O çalışmayı tekrar, daha az kodla, daha hızlı çalışacak şekilde ve Java 5 özelliklerini kullanarak yaptım ve JavaStruct adında minik bir projeye dönüştürdüm. Özellikle gömülü sistemlerle veya başka C uygulamaları ile haberleşen Java uygulamaları yazıyorsanız çok işinize yarayabilir. Eğer sabredip eksiklerini giderirsem Apache Mina projesine eklenme ihtimali de var. Bu arada JavaStruct içerisinde sevgili dostum Ateş Göral'ın çözdüğü Adobe Photoshop Color book formatını okuyup yazan bir örnek de var.

Son olarak ta, artık Pardus projesinin resmi geliştiricilerinden biri değilim. Tabi bu, özgür yazılımın Türkiye'deki en büyük ümidi ve en güzel ürünü Pardus için çalışmaya devam etmeyeceğim demek değil. Bir aksilik çıkmazsa yakında başlayacağım yeni işimde de Pardus için ayıracak vakit bulacağımı düşünüyorum.

Korkunç kodlar

2007-06-25T09:54:00.000+03:00

ff'in blogunda ilginç bir proje faciası yazısı gözüme çarptı. Exceptionlarla ilgili bölüm neler yapılmaması konusunda gayet eğitici, ilk örnekteki sıralama işlemi de evlere şenlik. Gerçekten de arkadaşlar hazır sıralama fonksiyonlliğini kullamak yerine kendileri bir tür selection sort algoritması yapmaya çalışmış ama felaket bir şekilde :).

Erlang, Java, Büyük sayılarla çarpma ve Optimizasyon

2007-04-29T18:22:00.000+03:00

Geçen gecenin bir yarısı Barış'la kısa bir süre konuştuk. Erlang ile yazdığı bir faktöryel kodunu ve 100.000! hesabının sonuçlarını gösterdi. Birden fazla sürecin mesaj aktarımı ile yaptığı hesaplama gerçekten ilginç. Bir nokta da ikimizin de Erlang kodlarının pek hoş görünmediği konusunda hemfikir olması :). Barış belki Erlang ile ilgili tecrübeleri konusunda bir şeyler yazar o yüzden o kodları buraya koymuyorum.

100.000! işlemi acaba java'da ne kadar sürer diye hemen bir deneme yapmaya karar verdim. Öncelikle klasik sayıların büyüklüğü yetmeyeceğinden BigInteger kullanmak gerekiyor. Klasik recursive faktöryel hesabı tekniği için şu kod yeterli:


public static BigInteger factoriel(long n){
    if (n == 1) return BigInteger.ONE;
    return  BigInteger.valueOf(n).multiply(factoriel(n - 1));
}

Tabi bu kod parçası n'nin büyük değerlerinde (n>5000) stack taşmasına yol açacağından rekürsif olmayan daha basit bir yönteme geçmem gerekti, stack'i büyüterek de problem aşılabilirdi ama tembellik işte. Rekürsif çağrı yapmayan kod:


public static BigInteger factoriel2(long n){
    BigInteger res = BigInteger.ONE;
    for(long i=2 ; i<=n; i++){
        res = res.multiply(BigInteger.valueOf(i));
    }
    return res;
}

Bu metodun performansı fena değil..


n        süre(saniye) 
----------------------
 10000       0.84          
 20000       2.55
 40000      10.09 
 60000      23.41
 80000      42.57
100000      67.8

Acaba performansı biraz iyileştirebilir miyim diye düşünürken aklıma yukarıdaki algoritma ile BigInteger'in çarpma yöntemini gereksiz yere yorduğum geldi.. Algoritmada rakam aşırı büyümesine rağmen bu dev rakamı sürekli minik sayılarla çarpılıyordu. O yüzden küçük bir numara yaparak rakamları 200'lü gruplar halinde çarpıp ara çarpımları bir listeye koyup en sonunda sadece bu listedekileri çarpmayı denedim. Sonuçta şu rakamları elde ettim..


n        süre(saniye) 
----------------------
 10000       0.32          
 20000       0.70
 40000       2.08 
 60000       5.13
 80000       9.25
100000      14.82

Bu basit optimizasyonla faktöryel hesabım yaklaşık 5 kat iyileşti. tabi bedeli de algoritmanın biraz daha karışması.. Algoritmayı çok threadedli yapıp çift çekirdekli bir makinede de denemek istiyorum.

100000!'in sonucu 456 bin basamaklı bir sayı ve String'e dönüştürmek maalesef çarpmanın kendisinden fazla sürüyor (107s).

Bir sonraki blog girişinde belki büyük sayılarla çarpmanın nasıl yapıldığından bahsederim. Bu arada Python çalışmaya devam ediyorum.

Tüm testler için ortam özellikleri: AMD AthlonXP 2.2Ghz, Pardus 2007.1, Java 6, JVM Parametreleri: -server -Xms500m -Xmx1000m

Java ve Thread'ler

2007-04-26T15:14:00.000+02:00

Thread programlama zor iştir. Ne kadar tecrübeli olursanız olun mutlaka bir şeyleri gözden kaçırırsınız, bir yerlerde ölümcül kilitlenme, yarış durumu veya performans sorunu çıkar ve bu durumla çoğu zaman sadece sistem belli bir yük altındayken veya özel bir durumdayken karşılaşırsınız, dolayısıyla çok threadli bir uygulamada hata ayıklaması da çok zordur.

Java 5 ile beraber eş zamanlı programlamanın üstatlarından Doug Lea'nın yürütücülüğünü yaptığı JSR-166 yani java.util.concurrent paketi kulanıma sunuldu. Java'yı çok threadlı programlama alanında bir kaç seviye daha yukarı taşıyan ve kütüphane bazında belki de Java 5'in en büyük yeniliği diyebileceğim bu yeni pakette neler var?

Yeni Thread Güvenli Koleksiyonlar: ConcurrentHashMap, Queue (PriorityQueue, LinkedList, ConcurrentLinkedQueue) ve CopyOnWriteArrayList ve CopyOnWriteArraySet. Özellikle iterasyon sırasında kilitlemeye gerek kalmaması, çok threadin erişimi sırasında daha iyi performans göstermeleri dikkati çeken yenilikler
Görev Yönetim Sınıfları: Executor, ExecutorService ve Future gibi görev yönetimi konusunda kolaylık sağlayan arayüz ve sınıflar. ExecutorService sayesinde bir thread havuzu oluşturup kullanmak artık çocuk oyuncağı.
Senkronizasyon Sınıfları: Semaphore, Mutex gibi temel yapılar ve CyclicBarrier, CountDownLatch ve Exchanger gibi birden fazla threadin davranışını kontrol eden Sınıflar. Örneğin çok işlemcili bir sistemde büyük bir işi 10 thread'e paylaştırmak, bu 10 thread'in işi bitince çözümün doğruluğunu test edip, sonuç yanlışsa tekrar başlamak istiyorsunuz. CyclicBarrier sınıfı sayesinde belli miktarda thread'in iş parçalarını yapmasını, ve tüm threadler işini tamamlayana kadar bekleyip tekrar başlamalarını sağlamak mümkün.
Alt Seviye Senkronizsyon Sınıfları: Lock, ReadWriteLock ve Atomic değişkenler. Lock sınıfının gerçeklemesi olan ReentrantLock sayesinde Java'da synchronized anahtar kelimesi ile gerçekleştirilen senkronizasyon fonksiyonelliğine daha iyi performansla ve daha çok fonksiyonellikle erişmek mümkün.Peki artık synchronized kelimesini kullanmayacak mıyız? Hayır, çünkü temel senkronizasyonu sağlamanın kolay yolu olan bu yöntemin en büyük artısı kilitleme ve açma işlemlerini otomatik olarak yapması. Lock gibi yapılarda mutlaka kod içerisinde .lock() ve .unlock() metodlarını kullanmak gerekiyor.

Bu yeni sınıflarla ilgili bulabildiğim en iyi öğretici doküman IBM dokümanları arasındaki Brian Goetz'in "Concurrency in JDK 5.0" dokümanı (Malesef kayıt gerektiriyor) google'de aynı isimle aratırsanız bir kopyasını bulabilirsiniz :). Brian Goetz'in JavaPolis'te konu ile ilgili konuşmasını dinleyebilir veya sunumu okuyabilirsiniz. Bunun yanında java.sun.com sitesinde de çeşitli dokümanlar var.

Python ve Java

2007-04-19T12:04:00.000+02:00

Python gerçekten de tatlı bir dil (gereksiz "self"'leri ve görüntü kirleten __hede__ leri saymazsak :) )

Geçenlerde Peter Norwig'in minicik bir Python kodu ile nasıl yazım düzeltme işi yapılabileceğine dair yazısını biraz inceleme şansım oldu. Gerçekten de çok güzel bir şekilde işi halletmiş Norwig. Temel olarak bir sözlük ve bu sözlük üzerinde verilen bir kelimenin 1-2 düzeltme mesafesindeki varyasyonlarının aranmasından ibaret olan algoritma gerçekten de şaşırtıcı derecede kısa. Aşağıdaki Python kodu ile verilen bir kelimedeki bir düzeltme mesafesinde olabilecek varyasyonları bulabiliyorsunuz.

def edits1(word):
n = len(word)
return set([word[0:i]+word[i+1:] for i in range(n)] +                     # deletion
           [word[0:i]+word[i+1]+word[i]+word[i+2:] for i in range(n-1)] + # transposition
           [word[0:i]+c+word[i+1:] for i in range(n) for c in alphabet] + # alteration
           [word[0:i]+c+word[i:] for i in range(n+1) for c in alphabet])  # insertion

Bu tekniğin bir benzeri Myspell ve Hunspell içerisinde de kullanılıyordu ve Daha önceden zemberek için de denemeyi düşünmüştük. Yukarıdaki kodun Java'cası şu şekilde oluyor:


public static List adaylariBul(String s, char[] alfabe){
    List adaylar = new ArrayList>(20);
    // Tek harf Eksik olanları bul
    for(int i=0; i< s.length(); i++){
        adaylar.add( s.substring(0 ,i) + s.substring(i+1) ); 
    }
    // Degisiklikleri ve eklemeleri bul
    for(char c : alfabe){
        for(int i=0; i< s.length(); i++){
            adaylar.add( s.substring(0 ,i) + c + s.substring(i+1) ); 
            adaylar.add( s.substring(0 ,i) + c + s.substring(i) );
        }
    }
    // Transpozisyonları bul
    for(int i=0; i< s.length()-1; i++){
        adaylar.add( s.substring(0 ,i) + s.charAt(i+1) + s.charAt(i) + s.substring(i+2) ); 
    }
    return adaylar;
}

Java versiyonu nispeten karmaşık görünse de anlaşılması pek güç değil, Python'un String dilimleme kolaylıkları Java'da yok. Yine de Java programcılarının çoğu kodların biraz kalabalıkça olmasına ("verbose") alışıktır ve garipsemez. Kodlar aralarında küçük farklar var, Python kodu sanırım sadece Ascii kodlu Stringler için çalışıyor ve alfabe'yi global bir değişkenden alıyor.

Peki bu kodlar Türkçe için kullanılabilir mi? Kısmen evet.. eğer yazının orijinalindeki en çok kullanılan kelimeler büyük bir sözlükten okunup onunla bu metodlar kullanılarak elde edilen karşılaştırılacaksa bir miktar başarı sağlanabilir. Ancak Türkçe gibi kelime üretim olasılıkları çok çok fazla olan eklemeli dillerde hem başarım belli bir seviyede kalacaktır hem de bellek kullanımı kötü olacaktır.

Ancak bu yaklaşımın bir varyasyonunu yine de Zemberek'te hatalı kelimeler için kök seçiminde kullanmayı denemek istiyorum.

byte byte

2007-04-15T00:46:00.000+02:00

Java'da tüm veri tipleri işaretlidir, yani C deki unsigned kavramı yoktur. Dolayısıyla Java ile biraz alt seviye işlem yapmış olanlar byte cinsinden verilerin sadece -128 ile +127 arasındaki değerleri taşıdığını bilirler. Hatta çoğu yerde byte cinsinden değişkene 0-255 arası bir değer atandığı zaman, onun işaretsiz versiyonunu elde etmek için 0xFF ile & (bit and) işleminden geçirirler, peki bu nasıl çalışıyor? Örneğin,

// b'nin değeri -15
byte b = (byte)241;

// y'nin değeri -15
int y = b;

// x'in değeri 241
int x = b & 0xFF;

Bir byte'lık veriyi 0xFF ile & yapmak yine aynı değeri vermez mi? Java spesifikasyonuna göre byte, short gibi işlemler üzerinde gerçekleştirilen bit işlemleri sırasında operandlar otomatik olarak int'e dönüştürülür.

byte a = (byte) 0xf1; // int olarak +241
int x = a;

deyince x değeri de -15 yani hex olarak 0xfffffff1 değerini alır.

Siz herhangi bir byte değerini 0xff ile and işlemine tabi tutarsanız (a & 0xff) işlem sırasında iki değer de int karşılıklarına dönüştürülür. yani aslında şu işlemi yapmış olursunuz:

0xFFFF FFF1 & 0x0000 00FF

ve sonuç ta işaretin kaybolduğu, rakamın pozitif karşılığıdır. yani +241 (0xF1)

buradaki önemli noktalar:

byte -> int dönüşümünde işaret korunur
bit işlemleri sırasında byte ve short tipindeki değerler değil int karşılıkları kullanılır.

Java ile ilgili arada bir küçük notlar yazmaya devam edeceğim.

Testing..

2007-03-21T16:45:00.000+02:00

Hopefully this will be a place where I'll post random rumblings about my adventures as a Pardus developer.