Erros, bugs, perguntas - página 2500

Novo comentário
 
Vict:

Está a escavar algures num sítio errado. Não precisa de nenhum alinhamento, o processador precisa dele para não ficar intrigado em duas linhas de cache.

não, a cache do processador é carregada com pré-busca de dados, e diferentes níveis de cache são carregados com previsões de transição, o pack() não consegue lá chegar (à cache), qualqueroperação aritmética (adição de 2 int) em vez de ser executada em 1 ou 3 ciclos de relógio (hipotéticos) resultará em análise de alinhamento de dados, etc.

A nível físico deve funcionar assim: o compilador criou código executável nele sim haverápack(), mas ao carregar dados da RAM apenas lerá dados int e o ponteiro do segmento de dados será imediatamente movido parapack() byte (não int byte)


embora possa estar errado, agora todos os processos (incluindo o próprio processador) estão virtualizados e optimizados - este é o meu raciocínio, já que li o livro sobre o Pentium-1 quando estudei -.... era tão caro nos tempos em que era ))))

 
Igor Makanu:

não, a cache do processador é carregada com pré-busca de dados, e diferentes níveis de cache são carregados com previsões de transição, o pack() não consegue lá chegar (à cache), qualquer operação aritmética (adição de 2 int) em vez de ser executada em 1 ou 3 ciclos de relógio (hipotéticos) resultará em análise de alinhamento de dados, etc.

A nível físico deve funcionar assim: compilador criou código executável nele sim haverápack(), mas ao carregar dados da RAM apenas lerá dados int e o ponteiro do segmento de dados será imediatamente movido parapack() byte (não para int byte)

Bem, eu não disse que o pacote() especificador é informação de serviço para a CPU. O que eu quis dizer foi toda esta dança com alinhamento no interesse da CPU e não do programador. Naturalmente, é implementado pelo compilador através da inserção de um espaço em branco nas estruturas.

 
Alexey Viktorov:

Ou seja, não há qualquer alinhamento na MQL5.

Está presente há muito tempo.

 
Vict:

Está a cavar no sítio errado, o alinhamento não é de todo para si

Bem, embora uma utilização real que me ocorre é num ambiente multithreaded, para organizar os dados de modo a que núcleos diferentes não escrevam na mesma linha de cache, isto pode realmente abrandar o desempenho devido à constante sincronização da cache. Bem, também há aí muitas nuances, como o tipo de CPU.

 
fxsaber:

Está presente há muito tempo.

Lembra-se sobre onde foi escrito?

 
fxsaber:

Então receio que se perca o ponto de alinhamento

tentou em bytes para ver o que o alinhamento faz:

#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) 0xFFFFFFFFFFFFFFFF 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




Ou ainda não acordei, ou o alinhamento do pack(4) / pack(8) não funciona, especifiquei explicitamente as dimensões das estruturas A e B para o compilador


mesmo assim:

 ZeroMemory(tst.a);   //tst.a.j=0;
nada mudou
 
Alexey Viktorov:

Lembra-se onde foi escrito?

Não me lembro se está na documentação.

 
Igor Makanu:

tentou ver o que o alinhamento faz em bytes:

ou ainda não acordei, ou o alinhamento do pacote(4) / pacote(8) não funciona, disse inequivocamente ao compilador as dimensões das estruturas A e B

Foi assim que esta discussão foi iniciada. Acontece que não é assim.

Bem, esta amostra é, afinal, incorrecta. Quando se zera o campo de treino, os bytes adicionais não têm de mudar em absoluto.


A ZeroMemory é muito provavelmente guiada pelo tamanhoof enquanto que em ambos os casos são dois, por alguma razão própria.

 
fxsaber:

Foi assim que esta discussão começou. Acontece que não é nada disso.

1. Bem, este exemplo é, afinal, incorrecto. Ao zerar o campo de subida, os bytes adicionais não têm de ser alterados em absoluto.


2. ZeroMemory deve ser guiado pelo tamanhoof enquanto é o dobro em ambos os casos por alguma razão.


1. sim Concordo

2. ZeroMemória deve apenas zerar a memória para mim


não vejo nenhum sentido em pack() em MQL puro, no máximo pode usar .dll para manipular dados, mas deve funcionar com certeza - foi isso que os programadores disseram

 
Igor Makanu:

2. ZeroMemory é exactamente o que eu preciso para reiniciar a memória

E tem.

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
Novo comentário