Programlamada Single-theread mi daha iyi yoksa multi-theread mı?
- Konuyu başlatan 533388
- Başlangıç Tarihi
- Mesaj 8
- Görüntüleme 1.440
Algoritmik
Hectopat
- Katılım
- 6 Temmuz 2022
- Mesajlar
- 4.265
- Çözümler
- 6
Rehber: Multi-Threading ile Single-Threading kullanma arasındaki fark
Merhabalar. Bu rehberde Multi-Threading ile Single-Threading arasındaki farkı ve kullanım yapısını anlatmaya çalışacağım. Öncelikle bunlar nedir? Single-Threading; Bu art arda işlem yapmaya denir. Yani bir işlem bitmeden diğer işleme geçmez yazılım. Yani bir işlem normalde 3 dakika...
- Katılım
- 22 Nisan 2020
- Mesajlar
- 5.421
- Makaleler
- 1
- Çözümler
- 19
Şimdi böyle bir durumda daha iyi veya daha kötü demek hata olur. İkisinin de önemli olduğu yerler var. Mesela oyunların çoğunda Single-thread daha önemlidir. Render, 3D tasarım gibi durumlarda da Multi-thread daha önemlidir.
Burada sorulan şey işlemci performansı değil. Oyunlarda da artık multi thread daha önemli. Programlayan kişilerin, bir işi sıralı olarak yapmak yerine paralel olarak yapmasına verilen isim multi threading.
Paralel programlama için iki yöntem var, biri multi processing, diğeri multi threading. Multi processing işlemi gerçekleştirmek için yeni bir process execute etmeye denirken, multi threading aynı işlem içerisinde paralelleşmeye (thread iplik demektir, birden fazla iplik tek bir halatı oluşturur, buradan gelmekte ismi) verilen isimdir.
Multi thread'de sistem işlemcinin diğer çekirdeklerinden ve/veya threadlerinden yararlanmaya çalışır aynı işlemi devam ettirmek için. Çok fazla kontrol gerektiren durumlarda single thread işlemi yavaşlatacağı için single thread yerine multi thread kullanılır. Atıyorum bir veriyi 50 tane işlemden geçiriyorsundur ve bu işlemlerden 3-4'ü ağır işlemdir uzun sürüyordur dolayısıyla. Bir sonraki veriye geçebilmek için bir önceki verinin bitmesini beklemek single thread oluyor, eğer sliceing riski yoksa (aynı verinin birden fazla alanda veya threadde kullanılması) sıralı işlemlerde O(N) durumunda genelde doğrusal bir hızlanmaya sebep olur çünkü yeni zaman O(N/thread sayısı) olacak.
Oyunlarda eskiden DirectX'in ve Vulkan'ın yapısı nedeniyle single thread geliştirme yapılıyordu. Şimdilerde DirectX 12'nin çıkışıyla birlikte multi threaded yapıya geçebildiler fakat bunu da henüz efektif kullanamadıkları için çeşitli optimizasyon problemleri görüyoruz oyunlarda. O yüzden bu yanlış bir bilgi. Single thread ve multi thread kendi kullanım alanlarına sahipler fakat bu oyunlar için böyle, başka şeyler için şöyle diye bir şey değil.
Son düzenleme:
Dynamics
Kilopat
Daha fazla
- Cinsiyet
- Erkek
Çözümlenmesi gereken problem, hedef donanım ve mimariye göre uygun olanı kullanırsın. Multithread'ın en bilinen dezavantajı race condition denilen olay, örneğin iki farklı thread aynı anda aynı değişkene erişip değiştirmeye çalışırsa programın çökmesi de dahil olmak üzere birçok kestirilemeyen hataya sebep olur. Ayrıca multithread daha fazla bellek ve cpu tüketir. Single thread'ın pek bir avantajı olduğunu söyleyemem dezavantaj olarak aynı anda yapılması gereken işler için kendi eşzamanlı kodunuzu kurgulamanız gerektiğidir ancak günümüzde coroutine denilen zımbırtıyla bu mevzuya da pek gerek kalmıyor.
Sonuç olarak ihtiyaca göre hangisini kullanman gerektiğine yine sen karar vereceksin.
Sonuç olarak ihtiyaca göre hangisini kullanman gerektiğine yine sen karar vereceksin.
Multithreadin dezavantajlarından güzelce bahsedilmiş, single thread avantajları da tabi ki multinin dezavantajları oluyor; single thread daha az kaynak kullanan basit bir işlemdir, kodlaması da basittir, kontrolü vs. de basittir, bakımı da basittir, böyle avantajları vardır.
Böyle olmasa zaten mesela her for döngüsü içindeki işlemi thread olarak run etmeye çalışırdık.
Böyle olmasa zaten mesela her for döngüsü içindeki işlemi thread olarak run etmeye çalışırdık.
- Katılım
- 22 Mart 2018
- Mesajlar
- 9.573
- Makaleler
- 1
- Çözümler
- 81
Bu tarz muhendislik kiyaslamalarinda cevap hep duruma gore degisir olacaktir.
- Eger yapilan is CPU bound ise multi-thread ile daha iyi performans alabilirsin. Ama bunun da exceptional durumlari var. Reactive programming yapiyorsundur, reactor threadini bloklamazsin, Aspect oriented programlama yapiyorsundur, cross-cutting yapmamak icin mevcut thread context'inden yurursun, CPU da calisacak instruction flow dependency yuksektir, multi thread ile performans almazsin ( ornegin 3. islem 2. islemin sonucuna, 2. islem de 1. islemin sonucuna baglidir ), multi-thread icin uygundur fakat thread sayisi secimini yanlis yapmissindir ve context-switch sebebiyle performans kaybedersin bu sebeple yapmazsin ya da her zaman daha iyi olmaz. Data ve flow uygundur, hardware yetersizdir, her thread paralel calisamaz ya da her islemci register'a yazilmayacak volatile data miktarini support edemiyor olabilir; yapmazsin.
en.wikipedia.org
en.wikipedia.org
- Ekipte concurrency bilen yoktur ki yuksek TPS application tecrubesi olmayan kisinin custom concurrency implemente etmemesi gerekir, multi-thread yapip bugli spagetti cikarmak istemezsin. 1 tane amatorun yazdigi kazma concurrency kodunu 40 tane usta fixleyemez. Oturup yeniden yazmak zorunda kalirsin.
- Yapilan is CPU bound degildir, her turlu I/O bekleyeceksindir; gerek kalmaz. Zincirin gucu en zayif halkanin gucune esittir.
- Kullandigin dil lightweight thread desteklemiyordur, 3 saniye kazanacagim diye 8GB ram kemirirsin hic gerek yoktur.
- Kullandigin teknolojiler concurrency test edecek, race condition expose edecek destek sunmuyordur bu riski almak istemezsin. Concurrency implementasyonundaki buglari reproduce etmesi de duzeltmesi de zordur. Kullanici "Bazen X oluyor" seklinde gelir.
- Os agnostic dillerde gelistirdigin multithread programlarin calisacagi isletim sistemindeki davranisina hakim olman gerekir. Bu da ciddi teknik bilgi ister. Ornegin Linux sistemde static thread priority tanimlaman beklenirken ( sched(7) - Linux manual page ) windows implementasyonu farklidir. Gelistirdigin algoritma dynamic weighted thread priority uzerinden yuruyecekse ve bunu OS agnostik dilde yazdiysan daha ilk koddan cicegi burnunda bug yazdin demektir. Her isletim sisteminin scheduling mekanizmasi farklidir ve senin bunu utilize edebilmen icin olayi bilmen gerekir.
Kabaca is paralelize etmeye uygun ve sen de paralelize etmeyi biliyorsan yapmalisin. Suphe varsa yapmamalisin, zaten cogu yazilim muhendisi de duzgun yapamaz bunu.
- Eger yapilan is CPU bound ise multi-thread ile daha iyi performans alabilirsin. Ama bunun da exceptional durumlari var. Reactive programming yapiyorsundur, reactor threadini bloklamazsin, Aspect oriented programlama yapiyorsundur, cross-cutting yapmamak icin mevcut thread context'inden yurursun, CPU da calisacak instruction flow dependency yuksektir, multi thread ile performans almazsin ( ornegin 3. islem 2. islemin sonucuna, 2. islem de 1. islemin sonucuna baglidir ), multi-thread icin uygundur fakat thread sayisi secimini yanlis yapmissindir ve context-switch sebebiyle performans kaybedersin bu sebeple yapmazsin ya da her zaman daha iyi olmaz. Data ve flow uygundur, hardware yetersizdir, her thread paralel calisamaz ya da her islemci register'a yazilmayacak volatile data miktarini support edemiyor olabilir; yapmazsin.
Context switch - Wikipedia
Data dependency - Wikipedia
- Ekipte concurrency bilen yoktur ki yuksek TPS application tecrubesi olmayan kisinin custom concurrency implemente etmemesi gerekir, multi-thread yapip bugli spagetti cikarmak istemezsin. 1 tane amatorun yazdigi kazma concurrency kodunu 40 tane usta fixleyemez. Oturup yeniden yazmak zorunda kalirsin.
- Yapilan is CPU bound degildir, her turlu I/O bekleyeceksindir; gerek kalmaz. Zincirin gucu en zayif halkanin gucune esittir.
- Kullandigin dil lightweight thread desteklemiyordur, 3 saniye kazanacagim diye 8GB ram kemirirsin hic gerek yoktur.
- Kullandigin teknolojiler concurrency test edecek, race condition expose edecek destek sunmuyordur bu riski almak istemezsin. Concurrency implementasyonundaki buglari reproduce etmesi de duzeltmesi de zordur. Kullanici "Bazen X oluyor" seklinde gelir.
- Os agnostic dillerde gelistirdigin multithread programlarin calisacagi isletim sistemindeki davranisina hakim olman gerekir. Bu da ciddi teknik bilgi ister. Ornegin Linux sistemde static thread priority tanimlaman beklenirken ( sched(7) - Linux manual page ) windows implementasyonu farklidir. Gelistirdigin algoritma dynamic weighted thread priority uzerinden yuruyecekse ve bunu OS agnostik dilde yazdiysan daha ilk koddan cicegi burnunda bug yazdin demektir. Her isletim sisteminin scheduling mekanizmasi farklidir ve senin bunu utilize edebilmen icin olayi bilmen gerekir.
Kabaca is paralelize etmeye uygun ve sen de paralelize etmeyi biliyorsan yapmalisin. Suphe varsa yapmamalisin, zaten cogu yazilim muhendisi de duzgun yapamaz bunu.
Son düzenleme:
Single threading yapmak, kodların sırayla çalışmasını sağlar.
Multi threading ise kodların aynı anda çalışmasını sağlar.
Bir kaç seneryo da kullanılabilir.
1. Kullanımı
Genelde işlemlerin sonuçları birbirine bağlı ise single threading yapılır.
İşlemler birbirinden bağımsız ise de multi-threading yapılır.
Örnek verirsek eğer birbirinden farklı kronometre çalıştırmak. Kronometre oluştururuz. Süresi ayarlarız ve süresi düşer. Sürenin azalması için birbirini beklemezler
2. Kullanımı
Süreden tasarruf etmek için kullanılır. Örnek olarak 1000 veri var.
Single thread ile 1000 veriyi yazdırırken 1000 birim zamanda yapar.
Multithreading ile bu verileri bölersek 4'e bölüp yazdırırsak 250 birim zamanda yapar.
Multi threading ise kodların aynı anda çalışmasını sağlar.
Bir kaç seneryo da kullanılabilir.
1. Kullanımı
Genelde işlemlerin sonuçları birbirine bağlı ise single threading yapılır.
İşlemler birbirinden bağımsız ise de multi-threading yapılır.
Örnek verirsek eğer birbirinden farklı kronometre çalıştırmak. Kronometre oluştururuz. Süresi ayarlarız ve süresi düşer. Sürenin azalması için birbirini beklemezler
2. Kullanımı
Süreden tasarruf etmek için kullanılır. Örnek olarak 1000 veri var.
Single thread ile 1000 veriyi yazdırırken 1000 birim zamanda yapar.
Multithreading ile bu verileri bölersek 4'e bölüp yazdırırsak 250 birim zamanda yapar.
