Sevgili hal 2000, process/threaları sen dağıtmazsın. O işi zaten OS/kernel kendisi yapar.
CPU veya Core sayısını artırmak performansı lineer olarak artırmaz. 2. CPU ile en fazla %5 bir artış alman bile mümkündür. Hatta, eğer kodu yeterince kötü yazar, birde üstüne böyle affinity vs. ayarlarını kurcalarsan, aksine performans kaybın bile olabilir. Bilhassa iki threadı (process değil) aynı core üzerinde çalıştırmak işi çok çok daha hızlandırabilir de. Bir zamanlar bir Pentium II'ler vardır. Intel bunları kırpıp, cache olmayan Celeron versiyonunu çıkardı. Sonra hangi akla hizmetse, birde cache'li versiyonu olan Celeron 300A çıktı. Pentium 2, işlemcinin yarı hızında (175 MHz) çalışan 512K cache ile geliyordu. Celeron 300A ise CPU hızında (300 MHz) çalışan 128K cache ile çıkmıştı. Sonuç, Celeron 300A performans olarak P2'leri evire çevire döven bir CPU olmuştu. Kıssanın hissesi şu: Olay ALU ile bitmaz, işlemleri ne kadar hızlı yaptığınız tamam ama, birde işlenecek bilgilere ne kadar hızlı ulaştığınız da önemlidir. eğer siz iki threadı bir CPU'ya bağlarsanız, cache'in her iki thread için güncel kalmasını sağlamış olursunuz (belki), o zamanda performans artıverir, hatta misliyle. Kısaca, olay threadları alıp dağıtmak olayından daha karmaşık. Ama asıl önemlisi, ortada çalışan daha bir sürü process var, hiç bir şey yoksa, mesela harddiskten veri okuyan eden kernelin kendisi var. Sonuçta, siz makinenin o anki gerçek durumunu bilemezsiniz, bunu ancak kernel bilir. Ve kernel threadları işlemcilere gayet uygun şekilde dağıtabilir. Detayı biraz karışık. Ama şöyle söyleyeyim. Siz bilinen perfroman kurallarına uyarak kodunuzu yazın. Bırakın gerisini derleyici ve kernel halletsin. Bu gibi alt seviye işlere bulaşmayın. Yok, eğer bilinen performans gereklerinden farklı bir yapı oluşturan algoritma veya kodunuz varsa, o zaman ancak threadların hangi CPU'ya atanacağı vs. gibi işlere müdahale edin. Bunu da, "ben yazdım kodu, böyle olsun" diyerek değil, kodu taaa başından bu yönde tasarlayarak, şurası ayrı bir CPU'da burası aynı CPU'da vs. diyerek yazmanız lazım. Belli bir thread/scheduling modeli sunan bir kod yazacaksınız ve sistemi o modele uyduracaksınız olabildiğince. Yapılması gereken bu. 2011/5/25 hal 2000 hal <[email protected]>: > Haklı gibi gözüküyorsunuz, sched_setaffinity() pthread ile uyumlu mu ? > değil mi ? bilmiyorum. > Fakat şöyle bir durum var Linux çekirdeğinde process ve thread ayrımı > yok. İş böyle olunca aslında bizim posix'de ki "thread yarat" > fonksiyonu bir sys_clone çağrısından ibaret > Yani kısaca ortak bir virtual space'i paylaşan process'leri thread > diye yutturuyorlar. > (Windows'da tamamen farklılar) > > Peki biz neden process/thread'ları cpu/core'lara tek tek dağıtmak isteyelim ? > Parallel işlem için. > Yazdığımız programı 2 çekirdeğide aynı anda kullanacak şekilde dizayn > edersek, hızı artacaktır. (2 cpu için 1.4 ile 2 kat arasında bir artış > olur) > ANCAK ! Eğer bu 2 thread aynı core üzerinde çalışmaya başlarlarsa > hızlanmak yerine yavaşlarız. O yüzden thread'ları core'lar üzerine > dağıtmalıyız. > 2011/5/25 Serdar KÖYLÜ <[email protected]>: >> Linkte verilen sched_setaffinity() bu meselenin çözümü değil gibi >> görünüyor bana. >> >> Linkte anlatılan yöntem, threadları işlemci çekirdeklerine dağıtmaktan >> biraz daha farklı bir durum. Bu daha ziyade bir processi sadece bir >> tek CPU'da çalıştırmaya yönelik bir mesele. Process başka, thread >> başka şey. >> >> Affinity, temel olarak bir process'i tek bir CPU'ya bağlamak için >> kullanılır. Bunun pratikte tek faydası (başka bir takım minör şeyler >> olabilir) cache üzerinde her zaman güncel bilgiyi tutmak olabilir. >> >> Threadların CPU'lar üzerine dağılmasını istiyorsanız, hiç bir şey >> yapmayın. "pthread_create()" ile threadı yaratıp öylece bırakın. Çok >> çok büyük ihtimalle kernel threadları CPU'lara dağıtacaktır kendisi. >> Ve bunu sürekli güncelleyecek maksimum performansı vs. sağlayacaktır. >> Kernel bunu yapamıyorsa, bunu yapmak daha kötü olacağı için yapamıyor >> olacaktır. >> >> Sizin affinity değerleri ile oynamanız, size ek performans filan >> kazandırmayacak gibi görünüyor buradan bakınca. >> >> 2011/5/25 hal 2000 hal <[email protected]>: >>> http://www.ibm.com/developerworks/linux/library/l-affinity/index.html >>> >>> 2011/5/25 Cihat YILDIZ <[email protected]>: >>>> Merhabalar, >>>> Linux konsol uzerinde calisan multithread bir uygulama yazmak istiyorum. >>>> Multithread yapmak istememin nedeni olusturdugum threadlerin islemci >>>> cekirdeklerine dagilmasini istemem. >>>> Ama bunun yapilip yapilamadigi veya nasil yapilacagi hakkinda bir fikrim >>>> yok. >>>> Bu konuda onerineriniz almak istiyorum. >>>> Ayrica bununla ilgili bir dokuman onerebilirseniz sevinirim. >>>> Kolay gelsin, >>>> >>>> --- >>>> Cihat YILDIZ >>>> Electronics Engineer >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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
