![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Aklıma gelen tek mantıklı açıklama havuzda çalışan thread sayısı üzerinde manuel kontrol (varsayılan async | deferred'e güvenmiyorsak) - örneğin, sistemin çok yüklendiğini görüyoruz, görev göndermeyi bırakıyoruz. zaman uyumsuz bayrak ile ertelenmiş göndeririz.
Genel olarak, async'in () yavaşlığından biraz hayal kırıklığına uğradım, hafif iplik havuzumu uydurmak için zamanım olacak, bana öyle geliyor ki çok daha hızlı olacak.
Varsayılan zaman uyumsuz|ertelenmiş modu, kitapta şu anda yeterli fiziksel kaynak yoksa, görev yeni bir iş parçacığı oluşturmayacak, ancak ana iş parçacığında engellenerek yürütülecek şekilde açıklanmıştır.
Ve varsayılan modda ana iş parçacığının olası engellenmesini her zaman hatırlamalısınız, çünkü temel olarak, aksine, ana iş parçacığını engellememek için çözümlere ihtiyaç vardır.
Yani varsayılan mod, fiziksel kaynak, yani işlemci üzerindeki yüke bağlı olarak görevin nerede yürütüleceğini otomatik olarak değiştirir.
Bu nedenle, fiziksel kaynağın taşmayacağından eminsek, bayrağı açıkça std::launch::async belirtmek daha iyidir.
Ve modern işlemcilerin fiziksel kaynağını aşmak için, tam potansiyeli seçmek için bu tür hesaplamaları aramak hala gereklidir))
Hala teori çalıştığım için hız hakkında henüz bir şey söyleyemem))
Bu nedenle, fiziksel kaynağın taşmayacağından eminsek, bayrağı açıkça std::launch::async belirtmek daha iyidir.
Ve modern işlemcilerin fiziksel kaynağını aşmak için, tam potansiyeli seçmek için bu tür hesaplamaları aramak hala gereklidir))
İşlemci en azından bir dizi iş parçacığına dayanacak, ancak işletim sisteminin yetenekleri - daha ziyade bir darboğaz olacak. Eh, sonsuz sayıda iş parçacığı üretemez, er ya da geç async(lauch::async, ...) atılmış bir istisna ile karşılaşacaktır.
İşlemci en azından bir dizi iş parçacığına dayanacak, ancak işletim sisteminin yetenekleri - daha ziyade bir darboğaz olacak. Eh, sonsuz sayıda iş parçacığı üretemez, er ya da geç async(lauch::async, ...) atılmış bir istisna ile karşılaşacaktır.
Evet, fiziksel sınır her zaman mevcuttur, ancak MT5 için görevlerimizde bu sınırın ötesine geçmek pek olası değildir.
Ayrıca, dönüş değerlerinde async ve future, bu değeri nasıl elde ettiğimize bakılmaksızın, lambda işlevi, ref() veya .get() aracılığıyla ortaya çıkarlarsa istisnalar döndürür.
Ve dönüş değerindeki std::thread istisnaları döndüremez.
Evet, fiziksel sınır her zaman mevcuttur, ancak MT5 için görevlerimizde bu sınırın ötesine geçmek pek olası değildir.
Ayrıca, dönüş değerlerinde async ve future, bu değeri nasıl elde ettiğimize bakılmaksızın, lambda işlevi, ref() veya .get() aracılığıyla ortaya çıkarlarsa istisnalar döndürür.
Ve dönüş değerindeki std::thread istisnaları döndüremez.
IMHO, zaman uyumsuzluğa fazla kapılma. Kolaylık sağlamak için yapmışlar gibi görünüyor, ancak tüm bu güzellikler özellikle performansı vuruyor gibi görünüyor. Bu bir artı değil...
Ve dönüş değerindeki std::thread istisnaları döndüremez.
Ancak gerekirse, bu bir düzine ekstra satırdır (daha hızlı çalışmasına rağmen - yığında herhangi bir tahsis olmadan).
Asılsız olmamak için:
On bile almadı. Evet, herhangi bir packaged_task ve gelecek olmadan daha da düşük seviyeli olabilir, ancak fikir - istisnalar atmak - bir tür zaman uyumsuz süper özellik değildir ve iş parçacığı hiç değildir.
MT4|MT5'in ertelenmiş hesaplamalar, havuzlar vb. gerektiren karmaşık görevleri yoksa neden karmaşık olsun?
Aslında görevler var. MT'nin seçeneği yoktur.
Arkadaşlar araştırmamı paylaşıyorum.
İplik havuzumu dizlerimin üzerine yazdım. Bunun tamamen işlevsel bir sürüm olduğuna dikkat edilmelidir, herhangi bir işlevi herhangi bir parametre ile geçebilirsiniz, yanıt olarak bir gelecek döndürülür, yani. istisnaları yakalamak ve tamamlanmasını beklemek şeklinde tüm güzellikler mevcuttur. Ve oradaki gibi kullandım https://www.mql5.com/ru/forum/318593/page34#comment_12700601
Kimin std::async yazdığını ve hangi durumda olduğunu bilmiyorum, ancak diz boyu zanaatım standart olandan yaklaşık 4 kat daha hızlı (10 çalışan iş parçacığı ile). Ayrıca, çekirdek sayısından daha fazla iş parçacığı artışı sadece bir yavaşlama sağlar. Havuz boyutu == çekirdek sayısı (2) ile zaman uyumsuz yaklaşık 30 kez kaybeder. Bu kadar.
Bir iş parçacığı havuzu istiyorsam, kesinlikle standart zaman uyumsuz olmayacaktır))).
Arkadaşlar araştırmamı paylaşıyorum.
İplik havuzumu dizlerimin üzerine yazdım. Bunun tamamen işlevsel bir sürüm olduğuna dikkat edilmelidir, herhangi bir işlevi herhangi bir parametre ile geçebilirsiniz, yanıt olarak bir gelecek döndürülür, yani. istisnaları yakalamak ve tamamlanmasını beklemek şeklinde tüm güzellikler mevcuttur. Ve oradaki gibi kullandım https://www.mql5.com/ru/forum/318593/page34#comment_12700601
Kimin std::async yazdığını ve hangi durumda olduğunu bilmiyorum, ancak diz boyu zanaatım standart olandan yaklaşık 4 kat daha hızlı (10 çalışan iş parçacığı ile). Ayrıca, çekirdek sayısından daha fazla iş parçacığı artışı sadece bir yavaşlama sağlar. Havuz boyutu == çekirdek sayısı (2) ile, async yaklaşık 30 kat kaybeder. Bu kadar.
Bir iş parçacığı havuzu istiyorsam, kesinlikle standart zaman uyumsuz olmayacaktır))).
Araştırma için teşekkürler. İyi bir örnek, çalışmak için düşünülecek bir şey var.
Ancak genel tartışmamızdan çoğumuz, iş parçacığı havuzunun aslında gerçekten gerekli olmadığı sonucuna vardık.
Benim durumumda bu kesin, havuzun iş parçacığı sayısı açısından statik olduğunu fark ettiğim için bu bana uymuyor.
Ve evet, bir havuza ihtiyaç duyulduğunda, o zaman örneğiniz sadece bunun iyiliği için olacaktır. Örnekleri gösterdiğin için teşekkürler.
Hala basit bir anlayışla anlamaya başlıyorum))