Wındows için yazdığımız programda fonksiyonları parçalamak - Thread

[z]

Yazdığımız program A ve B adındaki iki fonksiyondan oluşsun.

Bir döngü içerisinde A-B-A-B şeklinde fonksiyonları ard arda çağırıyor olalım.

A ve B 1 ms de işletiliyor olsun. Bu durumda bir döngü 2 ms de tamamlanacak demektir.

Eğer A ve B yi iki ayrı thread olarak yazarsam ve B ve A arasında veri aktarımı olmayacaksa

A ve B nin her ikisinin birden işletilme süresi 2 ms nin altına inebilirmi?

Eğer B, A nın çıktılarına ihtiyaç duyuyorsa bu durumda fonksiyonları threadlere ayırma herhangi bir avntaj getirirmi?

[vsalma]

A ve B nin her ikisinin birden işletilme süresi 2 ms nin altına inebilirmi?

Bu biraz threadlerin kullandigi kaynaklara bagli. Mesela A bir okuma yazma isi(veya memory allocation, database transaction vs.) bekliyosa, o beklerken B nin farkli threadde kosmasi toplam isletilme suresini kisaltir.

Ozellikle islemsel yuku agir A ve B icin farkli cekirdekte calistirma toplam performansi cok etkiler. (Tabi bu multithreading değil multicore)

Eğer B, A nın çıktılarına ihtiyaç duyuyorsa bu durumda fonksiyonları threadlere ayırma herhangi bir avntaj getirirmi?

Birbirlerinden data bekliyorlarsa her halukarda hizli olan yavas olani bekleyecek. Threadlere bolmek veya multicore yapmak fayda getirmez gibi duruyor. Threading, haberlesme overheadleri gelecek...

[engerex]

 Delphi'de multithread için omnithread oldukça kullanılıyor. Bunda mi veya hangisinde tam hatırlamıyorum ("ExThreads"dı): İşlemci kaç çekirdek görüyorsun. İstediğin thread istediğin çekirdeğe atayabiliyorsun. İstediğini thread istediğin zaman başlatıp durdurabiliyorsun. Hepsine ayrı ayrı öncelik atayabiliyorsun. (Yüksek öncelik verirsen diğer açık uygulamalardan daha az etkilenirler.) Kaç thread aktif görebiliyorsun. Normalde de yapılan şeylerdir ancak bu bileşenle oldukça kolay şekilde yapmıştım.
Bir ara test etmiştik. İşlemci 4 çekirdek. Her birine 1'er thread atıyordum. Hepsi aynı işlemi yapıyor. Tamamlanma süreleri t1: 5150ms, 5010ms, 5051ms, 5020ms gibi aralarında farklar oluyor. Buda açık diğer uygulamalardan kaynaklanıyor.

Eğer threadlar durmaksızın peş peşe çalışacaksa ayrı ayrı olarak ayrı çekirdekte çalışmaları daha hızlı sonuç verecektir. Ancak arada bekleme zamanı varsa ayrı ayrı çalışmalarına gerek yok. Asenkron thread olursa çalışma anında birbirleriyle haberleşemezler.

[z]

omnithread için basit bir kod örneği verebilirmisin?

[Icarus]

A ve B'nin algoritmalarının bu işe uygun olarak tasarlanması lazım.
A ve B ortak veri kullanmalarına rağmen asla birbirlerini beklemeyecek şekilde dizayn edilebilirler. Aynı veriyi kullanmalarına rağmen seknronizasyon araçlarını kullanmazlar (Evet bu yazdıklarım konvensiyonel fikirlerle çelişiyor gibi gözüküebilir ama değil sadece modern)

[z]

Eeee.

Devamı getir. Nasıl yani?

[Yuunus]

Ben de meraklandım şimdi!!! Thread lari durdurma devam ettirme oncellik bunlari biliyordum ama core bazli yazilabiliyorsa super.

[engerex]

 Eğer B A'nın sonucunu beklemeye mecbursa

Burada olduğu gibi
A1
B1
A2
B2
...
An
Bn

Bizde 2 kat hız sağlayan bu yolu izleriz
A1
B1 A2
B2 A3
...
Bn-1 An
Bn

Sadece ilk ve son işlem tek.

Teknikte yeri var mı? Şimdi aklıma geldi.

[z]

Şu anda kağıda yaptığım karalamaları ne zaman gördün.

Motorun akımını hesapla, akımdan torku hesapla, torkdan motor milinin yeni konumunu hesapla ardından motorun mil açısından yararlanarak arabanın tekerini döndür ve arabanın konumlandığı yeni koordinatı hesapla

Şeklinde iki fonksiyonu arka arkaya işletmek yerine

Threadlere ayırırsak

1. Thread: Motorun mil açısından yararlanarak arabanın tekerini döndür ve arabanın konumlandığı yeni koordinatı hesapla
2. Thread: Motorun akımını hesapla, akımdan torku hesapla, torkdan motor milinin yeni konumunu hesapla

Şekline dönüştürebiliriz.

Bu durumda

Bir fonksiyon diğer fonksiyonun sadece 1 önce ürettiği sonuçları kullanabilir.

Threadlerin 1 ms de bir çalışmasına izin verirsem 1ms lik  gecikme elemanı koymuş gibi oluruz.

[sovalye]

hocam, bu tarz fonksiyonları niye thread lara ayırmak istiyorsunuz? Hesaplanmaları zaten ne kadar sürebilir ki. Ayrıca thread lara ayırmak core seçiminde pek etkili değil, olay yine işletim sisteminin kararı. İlla farklı core larda paralel çalışsın istiyorsanız ya kodunuz işletim sistemininden daha alt seviyede çalışacak yada profesyonelce yazılmış multi thread uygulamalarından faydalanmalısınız veya kodu önceden kararlaştırdığınız bir core un içinde çalışmaya zorlayacaksınız (pek önerilen bir yöntem değilmiş daha önce okuduğuma göre )

[z]

Saniyede 1000 kere hesap yapıp robot koordinatlarını hesaplamayı fakat ekrana saniyede 50 tane hareketli robot görüntüsü  basmayı deneyeceğim.

Ekrana görüntü basan fonksiyonla hesap yapan fonksiyonu thread yapmam daha mantıklı.

[sovalye]

niye saniyede 1000 kere diye bir sınır koyuyorsunuz? Bırakın program bulabildiği tüm kaynakla çalışssın. Bir saniyeyi 1000 parçaya ayrılmış halde modellemeniz bu şekilde hesaplamak zorunda olduğunuzu göstermiyor. programın hesap kısmı 1 sn de işini bitirsin sonra 15 saniye o görüntüyü gösterebilirsiniz.
aynısı görüntü içinde geçerli bırakın çalışsın. Kaynak tasarrufu yapmak istiyorsanız 50 fps hesaplamak biraz israf gibi geldi. Eğer büyük baskı altındak bir pro oyuncu veya jet pilotu falan değilse , tüm insan gözleri 24 fps(standart sinema) yada en en kötü 30fps ' nin üzerindeki görüntüleri devamlı olarak görür.

// bu örnek için yazmıyorum ama ilginç gelmişti. 50 fps üzerindeki sürekli harekete sahip görüntü insan gözünü yorup, arada çok fazla frame kaçırmasına sebep olarak, görüntünün donduğu hissine sebep oluyormuş.

[z]

Sorun şu. Robot simülatör bir program, robot kontroller ayrı bir program.

Bu iki program sürekli olarak veri paslaşacaklar.  Robotun gerçekteki hızında hareket edebilmesi için gerçek zamanda hesap yapmam ve ekrana basmam lazım.

Saniyede 50 kez görüntü basma ağzımdan çıkan öylesine bir söz. (TV tarama hızından)

Ancak saniyede en azından 1000 kere iki program veri paslaşması yapmak zorunda. Saniyede 25 kare basarsam 1000/25 her 40 paslaşma ardından ekrana bir kare çizdirmem gerekecek.

1 saniyede tüm hesapları yapmak  ardından 15 saniye görüntü göstermek olmaz. Programlar etkiye tepki prensibinde işlemek zorunda.

[engerex]

 Saniyede 1000 kez hesaplayacaksan multithread gerek var mı? Saniyede kaç hesap yapıyor? Motorun akımını hesapla, akımdan torku hesapla, torkdan motor milinin yeni konumunu hesapla ardından motorun mil açısından yararlanarak arabanın tekerini döndür ve arabanın konumlandığı yeni koordinatı hesapla Bu döngüyü 1 milyon kez çağırsan kaç saniye sürüyor? PIC/Atmel 16Mhz veya STM32 168 Mhz'ye yakın sabit bir performans baz alınabilir.

@sovalye fps olayı dediğin kadar kesin olsaydı oyuncular 50 yerine 100 fps için veya 60 hz yerine 120 hz yerine fazladan nede para veriyor? Evet olayın büyük kısmı hastalık ama 50 ile 100 fps arasındaki akışkanlığı farkedebiliyorsun.

[sovalye]

"Robot simülatör bir program, robot kontroller ayrı bir program." anlamadım. hazır bir kütüphane mi kullanıyorsunuz? Eğer ikisinide siz yazıyorsanız niye böyle bir düzenlemeye gittiniz ? Yarışmacıdan gelen kodu bir program test eder, diğeri sonucu ekrana video şeklinde basar.
"Robotun gerçekteki hızında hareket edebilmesi için gerçek zamanda hesap yapmam ve ekrana basmam lazım." niye ?
"1 saniyede tüm hesapları yapmak  ardından 15 saniye görüntü göstermek olmaz. Programlar etkiye tepki prensibinde işlemek zorunda. " Ekrana resim çizecek bir programcık nasıl bir tepki verecek ?

programın hızlı kısmı matematik işlemleri yapan kısım. yavaş kısmı ekrana basan kısım. Siz bunları hızlı çalışsınlar diye thread lere ayırmak istiyorsunuz ama o kadar da hızlı çalışmasınlar mı istiyorsunuz?
Smülatörün içini bilmiyorum ama istediğiniz kadar kompleks yazın matematiksel işlemleri yapması çok çok kısa bir süre alacaktır. Ama ekrana basması normal yarışma zamanı sürecek yani niye bunları aynı zamanda bitirmek için boş yere hızlı olan kısmı boşta bekletmek istiyorsunuz?
Sadece her saniye için 24 tane konum verisine ihtiyaç duyan bir fonksiyonla niye saniyede 1000 kez iletişime geçip bir de bundan karşı veri almak istiyorsunuz anlamadım.

Demek istediğim bütün matematiksel işlemleri bir yere toplayın, bunların en genel sonucu arabanın hangi 24'te 1 lik saniye aralığında nerede olacağı değil mi? bu küçücük veriyi program kendi içinde saklasın daha sonra her ekrana basma döngüsünde çizim yapan fonksiyonunuz bu veriyi alsın. Bu veriye göre arabayı konumlandırıp, kullanıcıya göstersin.

mesaj birleştirme:: 06 Ekim 2015, 00:05:58
@engerex hocam, anlık olarak veya beyin kendini tehlikede hisstettiğinde algılayabildiğimiz fps çok daha yükseliyor(oyunlarda bunun içinde tabiki bir anlık heyecanla) ama burada gösterilecek şey en nihayetinde bir video olduğu(izleyen kişi aktif olmayak sadece sonucu izleyecek) 24-30 fps yeterlidir dedim. Yani oyun anında ne kadar 100 fps gerekiyor desede dvd görüntüsü için bu şey takılarak geçiyor diyen kişi görmedim.