Geliştiricilere soru - optimizasyon sırasında tüm bilgi işlem çekirdeklerinin kullanımı - sayfa 6
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
Bu doğru bir yaklaşım değil - görevleri birer birer vermek değil, ücretsiz kaynaklar varsa kapasiteleri yeniden dağıtmak, yani. önceden verilmiş görevleri iptal edin ve yürütmeleri için başkalarına verin. Aynı zamanda, çekirdeğe yürütme için gerekli sayıda yeni görev vermek için her ajan için performans analitiği yapmak gerekir.
bu tam bir saçmalık, üzgünüm
> önceden verilmiş görevleri iptal edin ve bunları yürütmeleri için başkalarına verin
Bunun hiç gerçekçi olmadığını düşünüyorum ve neden, bir toplu iş oluşturmak daha kolay olduğunda, ilk boş iş parçacığına bir görev verin, tamamlanana kadar bekleyin, sonraki görevi ilk serbest iş parçacığına verin (Dikkat ediyorum iş parçacığı kelimesine, işlemci çekirdeği değil, iş parçacıkları üzerindeki kısıtlamanın kaldırılması gerekir - bu programcıların hakkı değil, kullanıcının hakkıdır, şimdi size hatırlatmama izin verin, iş parçacığı değil, ağ akışları gibi davranın, performansı yapay olarak yarı yarıya düşürür)
> çekirdeğe yürütme için gerekli sayıda yeni görev vermek için her aracı için performans analitiği yürütmeniz gerekir.
ve bu hiç gerekli değil, çünkü aynı işlemcinin aynı performansa sahip çekirdekleri, görevlere bağlı olarak farklı hızlarda sayılır, hiçbir şey sayamazken saymak için ne var?
bu tam bir saçmalık, üzgünüm
> önceden verilmiş görevleri iptal edin ve bunları yürütmeleri için başkalarına verin
Bunun hiç gerçekçi olmadığını düşünüyorum ve neden, bir toplu görev oluşturmak daha kolay olduğunda, ilk boş iş parçacığına bir görev verin, tamamlanana kadar bekleyin, sonraki görevi ilk serbest iş parçacığına verin (öderim işlemci çekirdeğine değil, thread kelimesine dikkat edin, threadler üzerindeki kısıtlamayı kaldırmak gerekir - bu programcıların hakkı değil, kullanıcının hakkıdır, şimdi size hatırlatmama izin verin, thread değil, sadece gerçek çekirdekler, ağ akışları gibi davranır , performansı yapay olarak yarı yarıya düşürür)
> çekirdeğe yürütme için gerekli sayıda yeni görev vermek için her aracı için performans analitiği yürütmeniz gerekir.
ve bu hiç gerekli değil, çünkü aynı işlemcinin aynı performansa sahip çekirdekleri, görevlere bağlı olarak farklı hızlarda sayılır, hiçbir şey sayamazken saymak için ne var?
Optimize edici ile çok az deneyiminiz var gibi görünüyor ve tamamlanan geçişler hakkındaki bilgilerin geç geldiğini, görev tamamlandıktan sonra aracının çok ağır olabilecek bir çerçeve gönderdiğini anlamıyorsunuz, tüm bunlar iletişim gecikmelerine ve optimizasyonu yavaşlatın. Bu nedenle, görevlerin gruplar halinde yayınlanması ve uygulanmasının dinamiklerini takip etmesi gerekir - işi tamamlamaya yakın olan aracılara yeni görevler vererek.
Optimize edici ile çok az deneyiminiz var gibi görünüyor ve tamamlanan geçişler hakkındaki bilgilerin geç geldiğini, görev tamamlandıktan sonra aracının çok ağır olabilecek bir çerçeve gönderdiğini anlamıyorsunuz, tüm bunlar iletişim gecikmelerine ve optimizasyonu yavaşlatın. Bu nedenle, görevlerin gruplar halinde yayınlanması ve uygulanmasının dinamiklerini takip etmesi gerekir - işi tamamlamaya yakın olan aracılara yeni görevler vererek.
> Optimize edici ile ilgili deneyiminiz zayıf görünüyor,
şaka mı??? 6 yıl sürekli
> tamamlanan geçişlerle ilgili bilgiler geç gelir, bu nedenle görevi tamamladıktan sonra aracı çok ağır olabilen bir çerçeve gönderir , tüm bunlar iletişim gecikmelerine ve optimizasyonun yavaşlamasına neden olur. Bu nedenle, görevlerin gruplar halinde yayınlanması ve uygulanmasının dinamiklerini takip etmesi gerekir - işi tamamlamaya yakın olan aracılara yeni görevler vererek.
>bu, iletişim gecikmelerine yol açacak ve optimizasyonu yavaşlatacaktır.
ve önemli değil, ağlar artık hızlı.
ancak talihsiz bir çekirdeğin bir paketten bir sürü görevi sayarken çekirdeklerin boşta olması, optimizasyonu son derece yavaşlatır çünkü geri kalan her şey (onlarca çekirdek) ayaktadır, çekirdekler sürekli ve durmadan saymalıdır.
pek çok parametre için hiç optimize etmemişsiniz gibi görünüyor ... ve pratik deneyiminiz olmadığını iddia etmeyin
> Optimize edici ile ilgili deneyiminiz zayıf görünüyor,
şaka mı??? 6 yıl sürekli
> tamamlanan geçişlerle ilgili bilgiler geç gelir, bu nedenle görevi tamamladıktan sonra aracı çok ağır olabilecek bir çerçeve gönderir, tüm bunlar iletişim gecikmelerine ve optimizasyonun yavaşlamasına neden olur. Bu nedenle, görevlerin gruplar halinde yayınlanması ve uygulanmasının dinamiklerini takip etmesi gerekir - işi tamamlamaya yakın olan aracılara yeni görevler vererek.
>bu, iletişim gecikmelerine yol açacak ve optimizasyonu yavaşlatacaktır.
ve önemli değil, ağlar artık hızlı.
ancak talihsiz bir çekirdeğin bir paketten bir sürü görevi sayarken çekirdeklerin boşta olması, optimizasyonu son derece yavaşlatır çünkü geri kalan her şey (onlarca çekirdek) ayaktadır, çekirdekler sürekli ve durmadan saymalıdır.
pek çok parametre için hiç optimize etmemişsiniz gibi görünüyor ... ve pratik deneyiminiz olmadığını iddia etmeyin
Kendine güvenen bir egoist olamazsın, ağları hızlı, ne kadar ben merkezli. Aksine, onlarca ve yüzlerce megabayt söz konusu olduğunda ağlar hızlı değildir.
İlkel Uzman Danışman optimizasyonu , optimizasyonun kullanıldığı tek şey değildir - ufkunuzu genişletin ve matematiksel hesaplamayı kullanın.
Evet ve bunun öncelikle kar amaçlı bir proje olduğunu ve kullanıcıları memnun etmediğini ve bu bağlamda, mekanizmanın görevlerin rastgele dağılımını ve bunların uygulanması için doğru finansal muhasebeyi dikkate alması gerektiğini unutmayın ...
Kendine güvenen bir egoist olamazsın, ağları hızlı, ne kadar ben merkezli. Aksine, onlarca ve yüzlerce megabayt söz konusu olduğunda ağlar hızlı değildir.
İlkel Uzman Danışman optimizasyonu , optimizasyonun kullanıldığı tek şey değildir - ufkunuzu genişletin ve matematiksel hesaplamayı kullanın.
Evet ve bunun öncelikle kar amaçlı bir proje olduğunu ve kullanıcıları memnun etmediğini ve bu bağlamda, mekanizmanın görevlerin rastgele dağılımını ve bunların uygulanması için doğru finansal muhasebeyi dikkate alması gerektiğini unutmayın ...
Onlarca ve yüzlerce megabayt hiçbir şey değildir, harcanan zaman minimumdur ve bu arada bununla hiçbir ilgisi yoktur, yazmadan önce bu trafiğin hala bir pakette iletilmesi gerektiğini düşünürdünüz.
> İlkel Uzman Danışman optimizasyonu , optimizasyonun tek amacı değildir - ufkunuzu genişletin ve matematiksel hesaplamayı kullanın.
Ufuklar için de aynısını diliyorum
ve bencillik hakkında da
ve benimki ilkel olmaktan uzak ve genel olarak neden gerekli o zaman, peki, bizi aydınlatın cahiller
Girişiminizi zaman maliyeti ve optimizasyon hızı açısından tamamen saçma buluyorum
Siz sadece kendi optimizasyon durumunuzu düşünürsünüz ve Alexey de kendi durumunu düşünür (birkaç yüz MB Uzman Danışmanı vardır ve göndermesi uzun zaman alır).
Ve MQ, optimize edicinin genel kullanımına bakar ve bunu size ve Alexey'e değil, çoğunluğa göre ayarlar.
Görevler, en azından benim için yerel çekirdeklerde yeniden dağıtılır. Bir yerde yeniden dağıtılmazsa, geliştiricilerin bunu da hesaba katabilmesi için çoğaltmak için bir örnek sağlayın.
Siz sadece kendi optimizasyon durumunuzu düşünürsünüz ve Alexey de kendi durumunu düşünür (birkaç yüz MB Uzman Danışmanı vardır ve göndermesi uzun zaman alır).
Ve MQ, optimize edicinin genel kullanımına bakar ve bunu size ve Alexey'e değil, çoğunluğa göre ayarlar.
Görevler, en azından benim için yerel çekirdeklerde yeniden dağıtılır. Bir yerde yeniden dağıtılmazsa, geliştiricilerin bunu da hesaba katabilmesi için çoğaltmak için bir örnek sağlayın.
Benim durumumun özel olduğuna katılıyorum.
Yeni uzak aracılar bağlanırsa görev tahsisinde bir sorun vardır - bu, kaynaklar diğer görevlerden serbest bırakıldığında gerçekleşir.
Siz sadece kendi optimizasyon durumunuzu düşünürsünüz ve Alexey de kendi durumunu düşünür (birkaç yüz MB Uzman Danışmanı vardır ve göndermesi uzun zaman alır).
Ve MQ, optimize edicinin genel kullanımına bakar ve bunu size ve Alexey'e değil, çoğunluğa göre ayarlar.
Görevler, en azından benim için yerel çekirdeklerde yeniden dağıtılır. Bir yerde yeniden dağıtılmazsa, geliştiricilerin bunu da hesaba katabilmesi için çoğaltmak için bir örnek sağlayın.
Muhtemelen benim de özelim var ama gerçek şu ki "muhtemelen"
>geliştiricilerin bunu da hesaba katabilmesi için çoğaltmak için bir örnek verin.
gerçek değil ... Danışmanımı yükleyemiyorum, standart olanlarla ilgilenmiyorum, yeniden dağıtılmadığını görebilmek için ekran görüntüleri alabilirim
yeniden dağıtılsaydı - sorunlara bir çözüm olurdu
hesaplama süresinin üç katı .... optimize edici normal çalışmaya getirilecek mi???? bir sürü boş çekirdek boşta ...
ikinci gün hiçbir şey sayılmaz, 12 yerel ve yaklaşık 30 ağdaki tüm çekirdekler boşta, bilerek dokunmuyorum ... tam numaralandırma, ne düşündüğünü bilmiyorum , muhtemelen hayatın anlamını veya koronovirüs için bir tedavi arıyor :-)
Çalışamazlığı ve yavaşlığı nedeniyle optimize ediciden vazgeçmek gerektiğini düşünüyorum.
ve yalnızca fiziksel çekirdekleri sınırlamak, bir dizi görevi inatla ve aptalca her bir çekirdeğe değil, yalnızca belirli çekirdeklere dağıtmak gibi MT tarafından alınan en son kararlar - bir görev - yüksek performanslı hesaplamaların geliştiricileri tarafından tamamen yanlış anlaşıldığından bahsediyor