Hatalar, hatalar, sorular - sayfa 2500

Yeni yorum
 
Vict :

Yanlış yerde bir yeri kazıyorsunuz, hizalama sizin için hiç gerekli değil, işlemcinin buna ihtiyacı var, böylece bazı int iki önbellek satırına girmez.

hayır, işlemci önbelleği genellikle önceden veri getirme ile yüklenir ve çeşitli önbellek seviyeleri genellikle dal tahminleriyle yüklenir, pack() oraya (önbelleğe) ulaşamaz, 1 üzerinde yürütülmek yerine herhangi bir aritmetik işlem (2 int eklenmesi) veya 3 (varsayımsal) döngü, veri hizalama analizi ve benzerleriyle sonuçlanacaktır.

Fiziksel düzeyde, şöyle çalışmalıdır: derleyici, içinde yürütülebilir kod oluşturdu, evet olacak   pack(), ancak RAM'den veri yüklerken, yalnızca int verileri okunacak ve veri segmenti işaretçisi hemen   pack() bayt (int bayt başına değil)


Çok yanılıyor olabilirim, ancak şimdi tüm işlemler (işlemcinin çalışması dahil) sanallaştırıldı ve optimize edildi, bu yüzden nedenim Pentium -1 hakkında okurken bir kitap okudum .... korku ne kadar pahalıydı bir kere))))

 
Igor Makanu :

hayır, işlemci önbelleği genellikle önceden veri getirme ile yüklenir ve çeşitli önbellek seviyeleri genellikle dal tahminleriyle yüklenir, pack() oraya (önbelleğe) ulaşamaz, 1 üzerinde yürütülmek yerine herhangi bir aritmetik işlem (2 int eklenmesi) veya 3 (varsayımsal) döngü, veri hizalama analizi ve benzerleriyle sonuçlanacaktır.

Fiziksel düzeyde, şöyle çalışmalıdır: derleyici, içinde yürütülebilir kod oluşturdu, evet olacak   pack(), ancak RAM'den veri yüklerken, yalnızca int verileri okunacak ve veri segmenti işaretçisi hemen   pack() bayt (int bayt başına değil)

Paket () belirtecinin CPU için bir hizmet bilgisi olduğunu söylemedim, demek istediğim - hizalı tüm bu danslar programcının değil CPU'nun çıkarınadır. Doğal olarak bu, derleyici tarafından yapılara boşluklar eklenerek gerçekleştirilir.

 
Alexey Viktorov :

Yani MQL5'te hiç hizalama yoktur.

Uzun bir süre, şimdiki gibi.

 
Vict :

Yanlış yerde bir yeri kazıyorsun, hizalama senin için hiç gerekli değil

Her ne kadar gerçek bir kullanım akla gelse de - çok iş parçacıklı bir ortamda, verileri farklı çekirdekler aynı önbellek satırına yazmayacak şekilde düzenlemek, bu, önbelleklerin sürekli senkronizasyonu nedeniyle performansı büyük ölçüde yavaşlatabilir. CPU türünde de birçok nüans var.

 
fxsaber :

Uzun bir süre, şimdiki gibi.

Bunun hakkında nerede yazdıklarını hatırlıyor musun?

 
fxsaber :

O zaman korkarım hizalamanın anlamı kaybolur

Hizalamanın ne yaptığını görmek için bayt cinsinden denedim:

 #property strict

const uint FFFF= 0xFFFFFFFF ;
//+------------------------------------------------------------------+
struct A pack( 4 )
  {
   ushort             j;
  };
//+------------------------------------------------------------------+
struct B pack( 8 )
  {
   ushort             j;
  };
//+------------------------------------------------------------------+
union UnionCheckByte
  {
   uint               byte_2x4[ 2 ];
   A                 a;
   B                 b;
  };
//+------------------------------------------------------------------+
void OnStart ()
  {
   UnionCheckByte tst;
   tst.byte_2x4[ 0 ]=FFFF;   tst.byte_2x4[ 1 ]=FFFF;   // заполним память 0xFFFFFFFF FFFFFFFF
   Print ( "0xFFFFFFFF FFFFFFFF = " ,tst.byte_2x4[ 0 ], "," ,tst.byte_2x4[ 1 ]);   // проверим
   
   
   
   tst.byte_2x4[ 0 ]=FFFF;   tst.byte_2x4[ 1 ]=FFFF;   // заполним память 0xFFFFFFFF FFFFFFFF
   tst.a.j= 0 ;
   Print ( "A.  = " ,tst.byte_2x4[ 0 ], "," ,tst.byte_2x4[ 1 ]);   // проверим



   tst.byte_2x4[ 0 ]=FFFF;   tst.byte_2x4[ 1 ]=FFFF;   // заполним память 0xFFFFFFFF FFFFFFFF
   tst.b.j= 0 ;
   Print ( "B.  = " ,tst.byte_2x4[ 0 ], "," ,tst.byte_2x4[ 1 ]);   // проверим
  }
//+------------------------------------------------------------------+

2019.07.07 17:51:30.601 tst (EURUSD,H1) 0xFFFFFFFF FFFFFFFF = 4294967295.4294967295

2019.07.07 17:51:30.601 tst (EURUSD,H1) A.=4294901760.4294967295

2019.07.07 17:51:30.601 tst (EURUSD,H1) B.=4294901760.4294967295




ya henüz uyanmadım ya da pack(4) / pack(8) hizalaması çalışmıyor, derleyiciye A ve Byapılarının boyutlarını açık bir şekilde belirttim


yine de:

 ZeroMemory (tst.a);   //tst.a.j=0;
hiçbirşey değişmedi
 
Alexey Viktorov :

Bunun hakkında nerede yazdıklarını hatırlıyor musun?

Belgelerde olup olmadığını hatırlamıyorum.

 
Igor Makanu :

Hizalamanın ne yaptığını görmek için bayt cinsinden denedim:

ya henüz uyanmadım ya da pack(4) / pack(8) hizalaması çalışmıyor , derleyiciye A ve Byapılarının boyutlarını açık bir şekilde belirttim

Ve böylece bu tartışma başladı . Her şeyin hiç de öyle olmadığı ortaya çıktı.

Peki, örnek yanlış. Ushort alanını sıfırlayarak, ekstra baytların hiç değişmesi gerekmez.


ZeroMemory, büyük olasılıkla, sizeof'a odaklanır ve her iki durumda da kendi başına bir nedenden dolayı bir ikili olur.

 
fxsaber :

Ve böylece bu tartışma başladı . Her şeyin hiç de öyle olmadığı ortaya çıktı.

1. Örnek hala yanlış. Ushort alanını sıfırlayarak, ekstra baytların hiç değişmesi gerekmez.


2 ZeroMemory, büyük olasılıkla, sizeof'a odaklanır ve her iki durumda da kendi başına bir nedenden dolayı bir ikili olur.


1. evet katılıyorum

2. ZeroMemory hafızamı sıfırlamalı


genel olarak, saf MQL'de pack()'teki noktayı görmüyorum, .dll'de maksimum veriyi sürebilirsiniz, ancak kesinlikle orada çalışması gerekir - geliştiricilerin dediğine göre

 
Igor Makanu :

2. ZeroMemory hafızamı sıfırlamalı

böyle gidiyor

 struct A pack( 4 )
{
   short j;
   char i;
};

union U
{
  A a;
   uchar Bytes[ sizeof (A)];
  
  U() { ArrayInitialize ( this .Bytes, ( char ) 0xFF ); }
};

void OnStart ()
{
  U u;
  
   ArrayPrint (u.Bytes); // 255 255 255 255
  
   ZeroMemory (u.a);
   ArrayPrint (u.Bytes); // 0 0 0 0
}
1...249324942495249624972498249925002501250225032504250525062507...3184
Yeni yorum