Erros, bugs, perguntas - página 2506

[Francuz]

Vict:
Justifique

Os registos são medidos em bits, e não em bytes. Por conseguinte, esta linha é utilizada incorrectamente no resto do código:

#define  CACHE_LINE_SIZE 64

[[Excluído]]

Francuz:

Os registos são medidos em bits, e não em bytes. Por conseguinte, esta linha é utilizada incorrectamente no resto do código:

Não, estás a dizer algo estranho. Não o vou provar. Veja a documentação sobre o processador, leia aqui https://stackoverflow.com/questions/7281699/aligning-to-cache-line-and-knowing-the-cache-line-size/7284876

Nas linhas x86 de cache são 64 bytes

Não preciso de registos, não estou de modo algum a falar deles.

[Francuz]

Vict:

Não, estás a dizer algo estranho. Não o vou provar. Veja a documentação para o processador, leia aqui https://stackoverflow.com/questions/7281699/aligning-to-cache-line-and-knowing-the-cache-line-size/7284876

Não preciso de registos, não estou de modo algum a falar deles.

Hmm... Está bem. (limpa a garganta) De qualquer forma, a cache varia de modelo para modelo. Não há forma de saber o seu tamanho a partir do software. É por isso que é uma tolice tomá-lo como um guia. Mas todos os processadores têm dois tipos de registos e é no tamanho dos registos que os programadores qualificados se concentram. E mesmo esta orientação de registo nem sempre é bem sucedida porque o compilador e o sistema operativo estão situados entre o programa e o processador.

Além disso, esta linha é calculada de forma incorrecta e sem registos:

int index = int(CACHE_LINE_SIZE - getaddr(data[rndnum].ar[0]) % CACHE_LINE_SIZE) / sizeof(int);

[[Excluído]]

Francuz:

Hmm... Está bem. De qualquer forma, a cache varia de processador para processador. E não há forma de saber o seu tamanho a partir do software. É por isso que é uma tolice ser guiado por ela. Mas todos os processadores têm dois tipos de registos e é no tamanho dos registos que os programadores qualificados se concentram. E mesmo a segmentação em tamanho de registo nem sempre o salva porque o compilador e o sistema operativo estão situados entre o programa e o processador.

Mais uma vez, as coisas estão a evoluir, é dada cada vez mais ênfase à multi-tarefa, e aqui está uma biblioteca transversal para vos contar tudo sobre ela

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

Além disso, esta linha é calculada incorrectamente e não tem em conta os registos:

Talvez, mas até agora ainda não me convenceu.

[Francuz]

Vict:

Mais uma vez não, as coisas estão a evoluir, é dada cada vez mais ênfase à multithreading, e aqui vai você - a biblioteca cross std dir-lhe-á tudo

https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size

Talvez, mas até agora ainda não me convenceu.

Não lhe dirá, dir-lhe-á a si. Leia atentamente a especificação.

Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais

Talvez, mas até agora ainda não me convenceu.

Embora não tenha bem a certeza do que queria compensar, mas é fácil de compreender: um endereço absoluto é completamente inútil nos cálculos. Esqueceu-se que o ponto de referência para a memória é o endereço da estrutura? E provavelmente queria obter o offset de um array num bloco de memória de estrutura? E é essa a diferença entre os endereços da estrutura e o elemento nulo da matriz.

[Eugeni Neumoin]

Artyom Trishkin:

Se não houver valor no tampão na barra, este deve ser explicitamente escrito no tampão. Isto é, se o valor calculado deve ser produzido para o buffer - escrevemos para o buffer, caso contrário - escrevemos um valor vazio.

Obrigado, Artem.

[[Excluído]]

Francuz:

Embora não tenha bem a certeza do que queria compensar, é fácil de compreender o bug: um endereço absoluto é completamente inútil nos cálculos. Esqueceu-se que o ponto de referência da memória é o endereço da estrutura? E provavelmente queria obter a compensação de um conjunto num bloco de memória de estrutura, não queria? E essa é a diferença entre os endereços da estrutura e o elemento zero da matriz.

int index = int(CACHE_LINE_SIZE - getaddr(data[rndnum].ar[0]) % CACHE_LINE_SIZE) / sizeof(int);
                                3        1                    2                  4

Acções em ordem:

1 - obter o endereço do primeiro elemento ar[] na estrutura de dados actual.

2. Descobrir as suas compensações desde o início da linha de cache

3. descubra quantos bytes até ao fim da linha de cache

4. descubra quantos bytes caberão neste espaço até ao fim da linha de cache.

Executou-o no seu computador? Existe uma diferença na velocidade? Ou serei apenas eu?

[Francuz]

Vict:

2. Descobrir as suas compensações desde o início da linha de cache

O que o leva a pensar que isso é uma forma de descobrir a sua compensação?

[fxsaber]

O que está a causar este abrandamento?

Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial

Insectos, insectos, perguntas

fxsaber, 2019.07.09 11:13

   Data data[];
   
   ArrayResize(data, 32768);

Está a acontecer uma desaceleração de 6x!

[TheXpert]

fxsaber:
Para que servem estes travões?

Uma matriz dinâmica tem mais verificações, Renat uma vez escreveu, não consigo encontrar o post, apenas falando sobre o acesso ao índice, porque é significativamente mais lento do que as vantagens