Errors, bugs, questions - page 2500

New comment
 
Vict:

You are digging somewhere in a wrong place. You don't need alignment at all, the processor needs it not to get some int on two cache-lines.

no, processor cache is loaded with data prefetching at all, and different cache levels are loaded with transition predictions at all, pack() cannot get there (into cache) at all, anyarithmetic operation (addition of 2 int) instead of being executed on 1 or 3 (hypothetical) clock cycles will result in data alignment analysis, etc.

On a physical level it should work like this: the compiler created executable code in it yes there will bepack(), but when loading data from RAM it will only read int data and the data segment pointer will be immediately moved topack() byte (not int byte)


although I may be wrong, now all the processes (including the processor itself) are virtualized and optimized - this is my reasoning, since I read the book about the Pentium-1 when I studied -.... it was so expensive back in the day ))))

 
Igor Makanu:

no, processor cache is loaded with data prefetching at all, and different cache levels are loaded with transition predictions at all, pack() cannot get there (into cache) at all, any arithmetic operation (addition of 2 int) instead of being executed on 1 or 3 (hypothetical) clock cycles will result in data alignment analysis, etc.

At physical level it should work like this: compiler created executable code in it yes there will bepack(), but when loading data from RAM it will only read int data and data segment pointer will be immediately moved topack() byte (not to int byte)

Well, I didn't say that the pack() specifier is service information for the CPU. What I meant was all this dancing with alignment in the interests of the CPU and not of the programmer. Naturally, it is implemented by the compiler through inserting a blank into structures.

 
Alexey Viktorov:

That is, there is no alignment at all in MQL5.

It's been present for a long time.

 
Vict:

You are digging in the wrong place, alignment is not for you at all

Well, although one real use I can think of is in a multithreaded environment, to arrange data so that different cores don't write to the same cache line, this can really slow down performance because of constant cache synchronization. Well, there are a lot of nuances there too, like CPU type.

 
fxsaber:

It's been present for a long time.

Do you remember where it was written about?

 
fxsaber:

Then I'm afraid the point of alignment is lost

tried in bytes to see what the alignment does:

#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) 0xFFFFFFFFFF FFFFFFFFFF = 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




Either I haven't woken up yet, or the pack(4) / pack(8) alignment does not work, I explicitly specified the sizes of structures A and B to the compiler


even so:

 ZeroMemory(tst.a);   //tst.a.j=0;
nothing has changed
 
Alexey Viktorov:

Do you remember where it was written?

I don't remember if it's in the documentation.

 
Igor Makanu:

tried to see what alignment does in bytes:

either I haven't woken up yet, or the pack(4) / pack(8) alignment doesn't work, I unambiguously told the compiler the sizes of structures A and B

That's how this discussion was started. It turned out that it is not so.

Well, this sample is incorrect after all. When zeroing the ushort-field, the additional bytes do not have to change at all.


ZeroMemory is most likely guided by sizeof while it is two in both cases for some reason of its own.

 
fxsaber:

So that's how this discussion started. It turns out that it's not like that at all.

1. Well, this example is incorrect after all. By zeroing the ushort-field, the additional bytes do not have to be changed at all.


2. ZeroMemory must be guided by sizeof while it is double in both cases for some reason.


1. yes I agree

2. ZeroMemory should just zero the memory for me


i don't see any sense in pack() in pure MQL, at most you can use .dll to manipulate data, but it should work for sure - that's what the developers said

 
Igor Makanu:

2. ZeroMemory is exactly what I need to reset the memory

It does.

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...3189
New comment
Reason: