Hatalar, hatalar, sorular - sayfa 1573

[Alexey Navoykov]

Anton Zverev :

100Kb'lik bir kaynak proje, 1325 yapısında bir saniyeden daha kısa sürede derlenir. Katı OOP, birçok sanal işlev ve aşırı yükleme, şablonlar, işaretçiler, const değiştirici (mümkün olan her yerde). DLL ve OpenCL olmadan.

Frenlerinizin nedenini öğrenmek istiyorum. Belki de derleyicinin hızlı bir şekilde optimize etmesine yardımcı olan const'tır. Frenlerle hiç uğraşmadım. Lütfen kaynak kodunu, yavaşlayan kod tabanından sağlayın.

Peki Duc 100 kb - bu gerçekten çok mu? Neredeyse bir megabaytım var. Her şey seninkiyle aynı. Ayrıca bir sürü makro var. Sadece burada const ekli her yerde değil. Ancak bu, böyle çılgın frenler için bir neden değil. Ayrıca, yapı 1159'da her şey neredeyse anında derlendi.

1325 derlemesinde test edemiyorum çünkü proje orada hiç derlenmiyor, bir sürü hata var ve birdenbire. Vaughn ve yoldaş A100, yeni yapıda ortaya çıkan bir grup hata hakkında abonelikten çıktı. Bu böcekleri seçerek zamanımı boşa harcamak istemiyorum. Çalışan bir yapı yayınlayana kadar bekleyeceğim.

Bu nedenle, frenler hakkında söylediklerim 1241 yapısına atıfta bulundu. Üzerinde test etme fırsatınız varsa, en son sürümle karşılaştırmayı deneyin. Ancak yeni yapıda önemli ölçüde hızlanacaklarından şüpheliyim. Aksine tam tersi. Sonuçta, derleme hızı MT geliştiricileri için çok az endişe vericidir, çalışma zamanında yalnızca ek nanosaniyeleri sıkıştırmaları gerekir, böylece daha sonra MQL programlarının hızı hakkında C++ ile karşılaştırılabilir (yalnızca soyut örneklerde olsa da) pazarlama açıklamaları yapabilirler. . Ve anladığım kadarıyla optimizasyonun etkinliği hakkında rahatsız etmiyorlar. Onlar. muma değer bir oyundur.

Kod tabanında kaynak aramaya çalışacağım ama benzerini bulabileceğim bir gerçek değil. Büyük bir proje olmalı. Ve orada, çoğunlukla küçük el sanatları ücretsiz erişim için düzenlenmiştir.

[Alexey Navoykov]

Renat Fatkhullin :

Büyük olasılıkla, metnin ayak örtüsü şeklinde devasa işlevleri vardır.

Bu tür ayak örtülerinde, optimize edici birçok geçiş yapmak zorunda kalır ve kodu tekrar tekrar geliştirir. Optimize edicinin hızının önemli ölçüde artması için işlevlerin boyutunu azaltmak yeterlidir.

Pekala, hem kaliteyi hem de hızı sürekli olarak iyileştirdiğimiz için en son yapılara geçtiğinizden emin olun.

Dev özellikler yok. Maksimum 150 satır (ya da bu devasa sayılır mı?). Ve eğer böyle düşünürseniz, derleyici bir sürü küçük fonksiyondan geçecekse, fonksiyonun boyutunun bununla ne ilgisi var? Diyelim ki büyük bir işlevi 10 kez çalıştırıyor. Pekala, onu 5 küçük parçaya böleceğim. Ve her biri 2 kez geçecek. Aynı sonucu alıyoruz. Onlar. toplam kod miktarı önemli, değil mi? Ama sonuç büyük fonksiyonları ezerek biraz hızlandırılsa bile, ne olmuş yani? Sonuçta, derlemeyi 10 (!) kat yavaşlatmaktan bahsediyoruz.

Programı olabildiğince hızlı çalıştırmak istemeniz anlaşılabilir, bu yüzden bir şeyi geliştirmek için çok fazla geçiş yapıyorsunuz. Ve dili ne kadar karmaşıklaştırırsanız, bu geçişlerin tamamlanması o kadar uzun sürer ve programcının zamanını alır. Ve sonra doğal olarak, tüm bunların etkinliği hakkında soru ortaya çıkıyor. Optimizasyonun tamamlanmasını bekleyen programcının kapalı kalma süresi ile karşılaştırıldığında, optimizasyonunuzdan programın hızlanması ne kadar önemlidir?

Tabii ki, bazı tavizler aramaya çalışabilirsiniz, ancak yukarıda yazdığım gibi farklı derleme modları yapmak çok daha verimli. Programın tüm optimizasyonlarla birlikte yayınlanması yalnızca en sonunda gereklidir. Ve bir programcı, optimizasyonlarınıza boşuna ihtiyaç duymadığında zamanının %99'unu kod yazmak ve hata ayıklamak için harcar.

[Vasiliy Sokolov]

Alexey Navoykov :

Derlemenin her güncellemesinden sonra kodların derlenmesi ne kadar sürecek! Derlerlerse, eskisinden farklı çalışmaya başlarlar (ki bu daha da kötüdür). Kim böyle bir programlama diline ihtiyaç duyar?

...

Ne demek istediğini anlamıyorum. 20.000 bin kod satırından fazla kod hacmine sahip, gerçekçi olmayan karmaşık MQL projelerim var. Yeni yapılarda iki kez derlenir. Şimdiye kadar sadece iki sorun oldu. Bir kere benim canım yüzünden, diğeri ise geliştiricinin canı yüzünden.

[Vasiliy Sokolov]

Alexey Navoykov :

Maksimum 150 satır

Bu çok büyük ve yanlış bir işlevdir.

[Alexey Navoykov]

Vasiliy Sokolov :
Ne demek istediğini anlamıyorum. 20.000 bin kod satırından fazla kod hacmine sahip, gerçekçi olmayan karmaşık MQL projelerim var. Yeni yapılarda iki kez derlenir. Şimdiye kadar sadece iki sorun oldu. Bir kere benim canım yüzünden, diğeri ise geliştiricinin canı yüzünden.

Şanslı olan sensin. Kodunuz, kodumda bulunan yapıları karşılamadı. Burada garip olan ne?

Yukarıdaki birkaç sayfada gezinin, oradaki kişi ayrıca yeni yapıda, bazıları ince olan bir sürü hata yakaladı. Sence onları bilerek mi aramıştı?

[Renat Fatkhullin]

Alexey Navoykov :

Şanslı olan sensin. Kodunuz, kodumda bulunan yapıları karşılamadı. Burada garip olan ne?

Yukarıdaki birkaç sayfada gezinin, oradaki kişi ayrıca yeni yapıda, bazıları ince olan bir sürü hata yakaladı. Sence onları bilerek mi aramıştı?

Tekrarlanabilir bir fren örneği gösterin lütfen.

Ne yazık ki, geliştiricilere doğrudan saldırılar da dahil olmak üzere asılsız açıklamalar yaparken.

Fonksiyonların boyutları ve programın genel boyutu hakkında yanılıyorsunuz. Bireysel işlevlerin boyutu, hem sözdizimi ağacındaki artıştan hem de optimize edicinin çoklu geçişinden dolayı her bir belirli işlevin optimizasyonunu doğrudan ve doğrusal olmayan bir şekilde etkiler. Küçük işlevler anında optimize edilir.

[Vasiliy Sokolov]

Alexey Navoykov :

Şanslı olan sensin. Kodunuz, kodumda bulunan yapıları karşılamadı. Burada garip olan ne?

Yukarıdaki birkaç sayfada gezinin, oradaki kişi ayrıca yeni yapıda, bazıları ince olan bir sürü hata yakaladı. Sence onları bilerek mi aramıştı?

1) Kodumda olmayan ne tür yapılar kullandınız ilginç? Kodumun hacmi binlerce satır, ancak tasarımlarınız değil mi? Bu süper benzersiz bir şey mi?

2) Aslında, önceki derlemede, sınıfların birbirine karşılıklı referansı durumunda ortaya çıkan dahili bir derleyici hatası vardı. Bu bir geliştirici hatası, ancak düzeltildi. Başka bir hata hatırlamıyorum.

[A100]

Vasiliy Sokolov :

2) Aslında, önceki derlemede, sınıfların birbirine karşılıklı referansı durumunda ortaya çıkan dahili bir derleyici hatası vardı. Bu bir geliştirici hatası, ancak düzeltildi. Başka bir hata hatırlamıyorum.

https://www.mql5.com/ru/forum/1111/page1591#comment_2463820

Ve sınıfların birbirine karşılıklı referansı nerede?

Burada daha da basitleştirdim, karşılıklı bağlantılar bulmada ve hangi yapıları kullanmadığınızı anlamada size kolaylık sağlamak için.

[Vasiliy Sokolov]

A100 :

https://www.mql5.com/ru/forum/1111/page1591#comment_2463820

Ve sınıfların birbirine karşılıklı referansı nerede?

Burada daha da basitleştirdim, karşılıklı bağlantılar bulmada ve hangi yapıları kullanmadığınızı anlamada size kolaylık sağlamak için.

Tersine mühendisliktesiniz. Çalışma, derleyiciyi geliştirmek için kullanışlıdır, ancak pratik programlama açısından uygulanamaz. Sağladığınız kodu gerçekten kullanacak tek bir programcı tanımıyorum:

 //+------------------------------------------------------------------+
//|                                                      Test116.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
bool is( const string type, bool )
{
         return ( type == "1" || type == "2" || type == "3" || type == NULL );
}
bool _is( string type ) { return is( type, false ); }
//+------------------------------------------------------------------+
template < typename T>
bool __is( T ) { return _is( typename ( T )); }
//+------------------------------------------------------------------+
#define IS( T )         __is( T( 0 ))
//+------------------------------------------------------------------+
template < typename T>
int sh( T t )
{
        T tt = 0x1 ;
         for ( int i = 0 ; i < 4 ; i++, tt <<= 1 )
                 if ( (t & tt) == tt )
                         return i;
         return - 1 ;
}
//+------------------------------------------------------------------+
class D { public :
template < typename T1, typename T2>                                     
                        T2                              g( T1 t1, T2, int sh = - 1 ); 
};                                                                     
template < typename T1, typename T2>                                     
T2 D::g( T1 t1, T2, int sh )
{                                                                      
        sh = sh( t1 );                                   
        T2 t2 = T2(t1) >> 1 ;
         return (sh( t1 ) & sh) == sh( t1 ) && IS( T2 ) ? 1 : 0 ;
}                                                                      
//+------------------------------------------------------------------+
class M : public D {
         virtual void f1() { g( 0 , 0 ); }
};
//+------------------------------------------------------------------+
class A {};
void g( A* ) export {}
class B { public :
         void h() { A a; g( &a ); }
};
class C { public :
         void f() {}
};
void OnStart ()
{
        C c;
        c.f();
}
//+------------------------------------------------------------------+

[Alexey Navoykov]

Renat Fatkhullin :

Tekrarlanabilir bir fren örneği gösterin lütfen.

Maalesef geliştiricilere doğrudan saldırılar da dahil olmak üzere asılsız açıklamalar yaparken..

Bunun büyük bir proje olduğunu yazdım, tüm kaynakların toplam hacmi yaklaşık 1 MB. Frenleri nasıl gösterebilirsiniz? Tüm kodları chtol gönder? Bunun imkansız olduğunu anlıyorsunuz. Ve bireysel parçaların derlenmesi elbette çok daha hızlı.

Ve "asılsız ifadeler" ile ne demek istiyorsun? Optimize edici derleyicinizin önemli ölçüde yavaşlaması gerçeği mi? Ve umursamadığın gerçeği? Burada asılsız olan nedir?

Bu küresel optimizasyonu henüz tanıttığınız geçen Ekim ayındaki bir tartışmanın bağlantısını burada bulabilirsiniz: https://www.mql5.com/en/forum/1111/page1424#comment_1981722

Adam yazıyor:

Başka bir kod - zamana dikkat edin - muhtemelen 20 kat büyümüştür

Ve sonra cevap veriyorsun:

Bu, MQL5 için yeni bir optimize edici derleyicidir (MQL4'te yoktur), işte böyle çalışır.

Daha iyi hedef kod için daha uzun derleme ile ödeme yapmanız gerekir.

Pekala, o zaman ben de dahil olmak üzere birkaç kişi daha yavaş derlemeden şikayet etti. Ancak cevaplarınızdan, yalnızca "daha iyi hedef kod" ve bazı efsanevi "yürütme hızında 2'den 10 kata artış" ile ilgilendiğiniz açıktır, ancak gerçek iş projelerinde bu tür hızlanmalar gözlemlemedim.

Dediğim gibi son derlemede (22 Nisan tarihli) test edemedim çünkü. derleme sırasında hatalar vardı. Ancak, yeni derlemede hiçbir yerde derleyici hızlandırma duyurusu yapmadığınız için derleme hızının oradaki kadar yavaş olduğuna inanıyorum.