Merhaba, Listeye düşen ilk soruyu "Linux'da çok kanallı program geliştirme nasıl?" olarak algılıyorum.
Öncelikle bu arkadaşa yardımcı olabilmek adına hangi dil ile geliştirme yapacağını sormalıyım. ? Varsayılan olarak C düşünülmüş ve güzel bağlantılar/anahtar kelimeler zaten verilmiş. Bunun dışında konunun gittiği yer ve listeye düşen diğer mesajlar oldukça bilgilendirici ve eğlenceli. Merakla paylaşılan deneyimleri izliyorum. Bu arada bir kaç noktada bende fikrimi beyan edeyim, Burada concurrency progrraming hakkında bir çok görüş belirtilmiş, genel olarak bakış açısına göre tamamının doğru olduğunu düşünüyorum. Konuyu iki farklı boyutta ele alırsak, öncelikle bir kernel üzerinde çalıştığımızı ve örneğin linux'un scheduling konusunda epey deneyimli olduğunu unutmamak gerekiyor. Üzerinde koşacağımız kernelin scheduling yöntemleri, context switch maliyetleri çoğu uygulama için yeterli olacaktır. Çok kanallı programlamada, kanalların hangi çekirdekte/hangi sırada çalıştırılacağı hakkında plan yapmadan önce kaynak yönetimi düşünülmelidir. Mesela Hüsrev'in bahsettiği download programında çok kanallı programlamanın getireceği avantaj hesaplama yükünü kanallara dağıtmak değildir. Bir ağ kaynağını beklerken main loop'a devam etmeyi sağlar. Zira gelen paketler socketin cache'ini doldurana kadar zaten thread uykuda olacaktır. Bu gibi bir senaryoda 100 ayrı çekirdekte eşanlı koşan threadlariniz olsa bile burada darboğaz network olacak, gereksiz kaynak tüketimi yapmış olacaksınız. Çok kanallı uygulamanızın erişeceği ortak bellek bölgeleri, disk, network gibi IO noktaları, önceden tasarlanıp düşünülmeli ve her bir threadin bu kaynakları ne kadar süre ile meşgul edeceğini, beklenmedik gecikmeleri nasıl karşılayacağını planlamak gerekli. Ortak bellek alanına erişmek için seçilen platforma göre bir çok yol mevcut. En yalın hali ile mutex gibi yapıları kullanmak, deadlock olmamak için kanalların hiyeraşisini düzgünce planlamak gerekli. Kullanıdığınız platforma göre çok kanallı bir uygulama geliştirmiş iseniz, ve işletim sisteminin kanalları yanlış idare ettiğini düşünüyorsanız, performans beklentilerin altında ise belki de üzerinde çalıştığınız iş tek bir çalışma ortamı için gerçekten fazladır, belki bir cloud'a ihtiyacınız vardır. Belki işi yazılım yerine donanım ile çözmelisiniz ya da bazı noktalarda donanıma başvurmalısınız. Sinyal işleme için özel çipler, matris gibi hesaplar için gpu'lar, ihtiyaca uygun donanım üretmek için fpga'ler var. Böyle bir durumda belki de bu gibi sçeneklere bir göz atmak gerekiyordur. İşletim sisteminin scheduling yapısının dışına çıkmak belki deneysel olarak çok iyi sonuçlar verecektir. Ancak üretim ortamında kullanılacak bir projede bunca deneyimi göz ardı ederek sadece kendi deneyiminize güvenmek pahalı sorunlara sebep olabilir. Mümkün mertebe şimdiye kadar kazanılan tecrübe üzerine yapılar kurmak, gerektiği noktalarda yine tecrübe edilen, standarları oluşmuş yöntemler ile mimariyi genişletmek gerektiğini düşünüyorum. Ancak deneysel projelerde, örneğin bir scheduling algoritması implement etmek, mesela ip paketlerini ihtiyacınıza uygun hale getirip performans kazanmak kesinlikle eğlenceli ve ufuk genişleten işler olurdu. 25 Mayıs 2011 13:02 tarihinde Husrev Ozayman <[email protected]> yazdı: > 2011/5/25 Mucibirahman İLBUĞA <[email protected]>: >> Madem çoğu programlar çift işlemciyi desteklemiyor o zaman insanlar >> neden 2-3-4 işlemci bağlıyor makinalarına?... Eğer tek bir oturum >> açacaksa yani bir programı bir kere ekranda açacaksa bu çift-üc-dört >> XEON işlemci çılgınlığı nedir?.. > > Fifefox bir çekirdekte/işlemcide, sizin programınız bir çekirdekte, > messenger vs. bir çekirdekte ... > > Tabii sizin uygulamanın bilgisayarın yükünün yüzde 80'ini > oluşturacaksa ve sistem çok çekirdekli veya çok işlemciliyse sizin bu > tarz alt seviyeli işlere girişmeniz mantıklı olacaktır. > > Özellikle problemniz bunu gerektiriyorsa işletim sistemine ve > derleyiciye bıraktığınıza çok pişman olursunuz. > > Çünkü işletim sistemleri bugün birçok şeyi doğru dürüst yapamıyor. > Çünkü sizin probleminizi, ihtiyaç duyduğunuz kaynakları işletim > sistemi bilmez, tahmin etmeye çalışır. Sizin bu tür konularda bir > birikmişiniz varsa ve bu tür alt seviyeli şeylere girişirseniz, > performans ciddi şekilde fark edebilir. > > Mesela en basitinden bir download programını bile multi-thread veya > multi-process yazmazsanız düzgün performans alamazsınız. Çünkü sizin > probleminizin doğası çok işlemden oluşuyor. Siz bunu tek işleme > indirgerseniz asıl o zaman işletim sistemi yanlış şeyler yapar. Mesela > bir programda siz bir yandan, internetten bir dosya çekiyor, bir > yandan diske yazıyor, bir yandan kullanıcıya durum gösteriyor ve bunu > da birçok download için aynı anda yapıyorsanız, bir dosyanın yazılması > için geçek seek time'da bütün prosesiniz bekler. > > Çok çekirdekli programlama gerçekten zor bir iş. Ama kesinlikle > gereksiz değil. Özellikle mobil cihazların dahi çok çekirdekli olmaya > başladığı şu zamanlarda... > > > -- > Hüsrev Özayman > _______________________________________________ > Linux-programlama mailing list > [email protected] > https://liste.linux.org.tr/mailman/listinfo/linux-programlama > Liste kurallari: http://liste.linux.org.tr/kurallar.php > _______________________________________________ Linux-programlama mailing list [email protected] https://liste.linux.org.tr/mailman/listinfo/linux-programlama Liste kurallari: http://liste.linux.org.tr/kurallar.php
