AMD ou Intel, assim como a marca de memória - página 73
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Por que. Também estou muito interessado na velocidade de cálculo das coisas sérias
Bem, já somos três. Ainda não é muito.
Entendi muito bem sua idéia. Mas acho que carregamos o testador de uma maneira errada. Meu ponto, por outro lado, você parece não ter entendido. Mas isso não importa, de modo geral. Para orientação, por assim dizer, "no terreno", esse último especialista também fará o mesmo.
OK. Não é o casus belli para maridos decentes, não é? ))) Também estou interessado na velocidade de execução do código especificamente, como meus indicadores (de repente, vi) são bastante intensivos em recursos, mesmo na execução pública.
Acho que o "grasn" também gostaria de ter a oportunidade de contar mais rápido
Não. Todos simplesmente não vêem na MT tarefas que exigem muitos recursos, exceto o trabalho do otimizador. E mesmo que o façam, não os utilizam em seu trabalho diário. Pelo menos a maioria deles o faz. Mas não importa. Vou esperar pelo MT5. A velocidade do código ali pode ser vista a olho nu. E há também a CUDA. Fiz o download dos kits de ferramentas do site nVidia, vou estudá-los. E não há problema em transferir o código para dll.
Quanto à CUDA, vi exemplos de cálculos acelerados por um fator de 10-100. Para algumas aplicações médicas. E a programação da CUDA já é ensinada nas universidades. Mas é muito enfadonho. Isto é, C é uma linguagem similar, mas é necessário dividir corretamente a tarefa, levar em conta as peculiaridades da GPU e os cálculos inteiros. Acontece que se trata de uma programação de muito baixo nível. E nem todas as tarefas podem ser facilmente reduzidas a este tipo para se obter um ganho real após seis meses de trabalho. Embora, por exemplo, operações com matrizes inteiras - quase perfeitamente traduzidas para a CUDA.
Existe o projeto OpenCL, que é um ambiente de computação distribuída. Quase todos estão envolvidos nela, inclusive a AMD e a nVidia. Há um nível mais alto de abstração. O link contém uma amostra de código que, como você pode ver, é C (o padrão C99).
Estudei as fontes, vou me reportar à tarde, agora é hora de dormir.
Os resultados são mais ou menos claros.
Vou tentar descrever brevemente minhas descobertas.
Ao otimizar o Expert Advisor, o testador utiliza várias dezenas de MB de memória. Eu, por exemplo, tenho um arquivo fxt durante um ano com minutos de abertura por cerca de 36 MB. Este histórico é armazenado na memória e é acessado mais ou menos aleatoriamente. Neste modo, a memória não oferece desempenho suficiente para fornecer ao processador aquela quantidade de dados que ele poderia processar em caso "ideal". Aqui o papel importante é desempenhado pelo cache.
Aqui começa a parte mais interessante.
1) Obviamente, em casos de falta de velocidade de cache e latência de acessos de memória desempenharão um papel importante. Aqui os processadores podem ser divididos em 2 grupos:
a) Atom e Core 2 - o controlador de memória está no chipset "ponte norte" (Ponte Norte - NB).
b) todos os outros com controlador de memória integrado (no processador) - ICP.
Os processadores do grupo "a", neste caso, podem perder significativamente para os processadores do grupo "b". Dito isto, o Core i7 ICP é muito mais eficiente do que nos processadores AMD. Esta é uma das razões para a vitória incondicional do Core i7.
2) Para que um cache possa mascarar efetivamente a latência tem que ser o maior possível, associativo (x-way em capturas de tela CPU-Z) e menos latência intrínseca.
E aqui os processadores se alinham claramente em termos de velocidade, dependendo do volume do cache (sendo todas as outras coisas iguais).
- A CPU mais lenta é o Celeron com cache de 512KB (não levo em conta o Atom - sua arquitetura é projetada para a economia e não para o desempenho);
- Athlons - seus baixos tamanhos de cache têm um efeito menor devido ao ICP;
- Celeron 900 com 1 MB de cache;
- Processadores Core 2 com 3-6 MB de cache; os modelos com maior volume de cache estão um pouco fora da marca;
- Phenom II, aqui 6 MB de cache (e com máxima associatividade - tanto quanto 48 vias!) são combinados com o ICP;
- e o mais rápido - Core i7 - aqui combina todas as coisas mais progressivas - RPC de 3 canais (e geralmente muito rápido) e o maior (e mais uma vez muito rápido) cache L3 com 8 MB.
Quanto ao motivo pelo qual a eficiência do Phenom diminui quando o overclock e o Core i7 sobe.
Nestes dois processadores, o ICP e o cache L3 são cronometrados separadamente (enquanto o cache L1/L2 está sempre rodando na freqüência da CPU).
Mas o método de overclocking de Belford envolve aumentar o multiplicador da CPU (ele tem um processador BE - Black Edition series - com um multiplicador livre, normalmente o multiplicador no topo é limitado), sem overclocking do cache L3.
Considerando que o overclocking do Core i7 (com exceção do XE) só é possível aumentando a freqüência de base (BCLK). Isto também overclocks ICs com cache L3 (no Core ix isto é chamado de Uncore).
Portanto, a velocidade L3 do Fenômeno de Belford é sempre fixada em 2009,1 MHz. E no YuraZ ele acelera de 2,13 GHz ao par, para 3,2 GHz quando o processador está overclockado para 4 GHz. (CPU BCLK x 20, Uncore BCLK x 16). E o Xeon, com uma freqüência de CPU de 3,33 GHz, o Uncore funciona a 2,66 GHz.
Nesse caso, mesmo a 2,13 GHz o cache L3 do Core i7 funciona visivelmente mais rápido que o cache L3 do Phenom a 2 GHz. E naturalmente muito mais rápido em 3,2 GHz, o que garante a excelente escalabilidade do Core i7 neste teste.
Agora isto está no nível da especulação, já que eu não fiz nenhuma pesquisa detalhada. Mas parece que a velocidade de otimização depende fortemente do tamanho e do desempenho do cache, e um pouco menos da freqüência do processador.
Vou tentar descrever brevemente minhas descobertas.
Ao otimizar o Expert Advisor, o testador utiliza várias dezenas de MB de memória. Eu, por exemplo, tenho um arquivo fxt durante um ano com minutos de abertura por cerca de 36 MB. Este histórico é armazenado na memória e é acessado mais ou menos aleatoriamente. Neste modo, a memória não oferece desempenho suficiente para fornecer ao processador aquela quantidade de dados que ele poderia processar em caso "ideal". Aqui o papel importante é desempenhado pelo cache.
Aqui começa a parte mais interessante.
1) Obviamente, em casos de falta de velocidade de cache e latência de acessos de memória desempenharão um papel importante. Aqui os processadores podem ser divididos em 2 grupos:
a) Atom e Core 2 - o controlador de memória está no chipset "ponte norte" (Ponte Norte - NB).
b) todos os outros com controlador de memória integrado (no processador) - ICP.
Os processadores do grupo "a", neste caso, podem perder significativamente para os processadores do grupo "b". Dito isto, o Core i7 ICP é muito mais eficiente do que nos processadores AMD. Esta é uma das razões para a vitória incondicional do Core i7.
2) Para que um cache possa mascarar efetivamente a latência tem que ser o maior possível, associativo (x-way em capturas de tela CPU-Z) e menos latência intrínseca.
E aqui os processadores se alinham claramente em termos de velocidade, dependendo do volume do cache (sendo todas as outras coisas iguais).
- A CPU mais lenta é o Celeron com cache de 512KB (não levo em conta o Atom - sua arquitetura é projetada para a economia e não para o desempenho);
- Athlons - seus baixos tamanhos de cache têm um efeito menor devido ao ICP;
- Celeron 900 com 1 MB de cache;
- Processadores Core 2 com 3-6 MB de cache; os modelos com maior volume de cache estão um pouco fora da marca;
- Phenom II, aqui 6 MB de cache (e com máxima associatividade - tanto quanto 48 vias!) são combinados com o ICP;
- e o mais rápido - Core i7 - aqui combina todos os mais progressivos - RPC de 3 canais (e geralmente muito rápido) e o maior (e novamente muito rápido) cache L3 de 8 MB.
Quanto ao motivo pelo qual a eficiência do Fenômeno diminui quando o overclock e o Core i7 sobe.
Nestes dois processadores, o ICP e o cache L3 são cronometrados separadamente (enquanto o cache L1/L2 está sempre rodando na freqüência da CPU).
Mas o método de overclocking de Belford envolve aumentar o multiplicador da CPU (ele tem um processador BE - Black Edition series - com um multiplicador livre, normalmente o multiplicador no topo é limitado), sem overclocking do cache L3.
Considerando que o overclocking do Core i7 (com exceção do XE) só é possível aumentando a freqüência de base (BCLK). Isto também overclocks ICs com cache L3 (no Core ix isto é chamado de Uncore).
Portanto, a velocidade L3 do Phenom é sempre fixada em 2009.1 MHz. E com o YuraZ acelera de 2,13 GHz ao par, para 3,2 GHz quando o processador está com overclocking para 4 GHz. (freqüência da CPU BCLK x 20, Uncore BCLK x 16). E para Xeon na freqüência da CPU de 3,33 GHz, o Uncore funciona a 2,66 GHz.
Nesse caso, mesmo a 2,13 GHz, o cache L3 do Core i7 funciona visivelmente mais rápido que o cache L3 do Phenom a 2 GHz. E naturalmente muito mais rápido a 3,2 GHz, o que garante a excelente escalabilidade do Core i7 neste teste.
Agora isto está no nível da especulação, já que eu não fiz nenhuma pesquisa detalhada. Mas parece que a velocidade de otimização depende fortemente do tamanho e do desempenho do cache, e um pouco menos da freqüência do processador.
Obrigado. Acho que é muito convincente. Eu concordo.
Um pequeno esclarecimento. Seria correto assumir que a velocidade de otimização depende mais do tamanho e do desempenho do cache do que da freqüência da CPU?
Um pequeno esclarecimento. É correto assumir que a velocidade de otimização depende mais do tamanho e do desempenho do cache do que da freqüência do processador?
Acontece que sim. Mas ainda é uma suposição por enquanto e eu enfatizei isso em meu posto!