> 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.
Bir download programı, multi-thread bir uygulama için sanırım verilebilecek en son örneklerden biri olurdu. Bir yandan internetten dosya çekiyor, bir yandan kullanıcıya durum bilgisi gösteriyorsanız, diğer yandan da diske yazıyorsanız, bu durumda ben olsam multithread işine hiç bulaşmam. Zira, herşeyden önce bariz bir race condition oluşturacağı ortada olan "kullanıcıya durum gösterme" olayı var. BU iş için en temiz yol event-driven ve tek threadla işi bitirmek olabilir. Soket ve dosya yazma okuma fonksiyonları asenkron yöntemleri destekler. Non-blocking IO iyi bilinen bir şeydir ve multitihreaddan bu hususta daha verimlidir. Genellikle atlanılan şey, performans kazancı için multithread kullanmanın pek çok durumda aslen yanlış bir seçim olduğudur. Eğer paralel yürütülebilir iki işlem varsa, bu ikisini ayrı threadlara atamak performans kazancı getirir/getirebilir ama bir seri işlemi, yani soketten oku/diske yaz/ekranı güncelle işlemini threadlara bölmek performans kazancından ziyade, kaybı ile sonuçlanabilirde. Bir bitmapı döndürdüğünüzü düşünelim. Bu durumda bitmapı 4 yatay banda böler, her birini ayrı ayrı threadlara döndürtebilirsiniz. Böylece 4 CPU birden size hizmet eder. Fakat, acaba CPU'lar arasındaki senkronizasyon vs. işlevleri, sizin bu perfromans kazancınızı ne kadar karşılayabilecektir? Sanırım bu mesele "Amanda thread, yok yok monolith" gibi bir noktaya doğru uzayıp gider. Gene boş bir tartışma olur. Asıl bilinmesi gereken şeyler şunlardır bence. Uygulamayı multithread yapmak otomatikman performans kazancı getirmez, kaç CPU'nuz olursa olsun. Tek bir threadın var olması, uygulamanın yavaş kalacağı anlamına da gelmez. Uygulama performansını belirleyen şeyler, çoğu zaman bottlenecklerdir. Bunlara dikkat etmek gerekir. Bu noktada asıl husus şudur. Birden fazla process veya thread, birden fazla CPU, aynı zamanda bir thread ve CPU senkronizasyon yükü getirir. Bu yük bazen ana uygulamanın üzerine ciddi bir yük olabilir. Diğer yandan, bir tek oturum açmış olmanız, birden fazla CPU'nun gücünün atıl kaldığı anlamına gelmez. Çoğu zaman işlemcinin çoğu yükünü sistemin kendisi oluşturur. Ethernetten geleni oku, yaz, ekranla ilgilen, diskle ilgilen, ekranda saati göster vs. vs. Çoğu zamanda tek bir uygulama gibi görünen şey, bir sürü uygulamadan ibaret olabilir. Bir browser penceresi, flashları vs. başka threadlar ile oynatıyor olabilir mesela. Bir noktayı ifade etmekte fayda var. Download programı event-driven ve tek thread olarak daha performanslı şekilde yazılabilir. Fakat, bu öyle bir uygulamanın multithread yazılırak daha kolay ve daha responsive bir uygulama yapılabileceği gerçeğini (elbette varsa böyle bir gerçek) değiştirmez. 2011/5/25 Mehmet Gürevin <[email protected]>: > 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 > _______________________________________________ Linux-programlama mailing list [email protected] https://liste.linux.org.tr/mailman/listinfo/linux-programlama Liste kurallari: http://liste.linux.org.tr/kurallar.php
