Erros, bugs, perguntas - página 2285
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
Sim, mas a noção de "rápido" no seu caso é muito relativa. Uma coisa é um utilizador solicitar um conjunto de barras - ele apenas copia uma área de memória, ou solicita uma série de tempos específica, depois é também uma simples cópia de dados com passo constante, igual ao tamanho da estrutura. E outra coisa são cálculos e conversões adicionais sobre cada número.
Embora, pessoalmente, preferisse ter uma história comprimida, para não desperdiçar memória, porque estou a organizar as minhas próprias matrizes para a armazenar de qualquer forma. Por isso, estou disposto a tolerar um pequeno atraso. Mas a maioria dos outros utilizadores desfazê-lo-iam em pedaços por ele )
p.s. Embora idealmente, seria bom ter tal opção no terminal, para escolher o modo de armazenamento do histórico em memória. Por exemplo, se o sistema tiver pouca RAM, mas um processador rápido, seria muito útil.
Vejam bem. Acabei de medir a velocidade de escrita e leitura no meu SDD. Verificou-se que o tempo de escrita e leitura era de 8 bytes (1 tipo de valor duplo ou data de tempo ou longo) ~ 48 ns. E de acordo com os meus cálculos, o tempo de leitura de 8 bytes de informação da matriz embalada é de 1-2 ns. Assim, enquanto perdemos 1-2 ns no acesso a um elemento estruturante, ganhamos 48*0,8 = 38 ns para escrita e leitura a partir do disco. Além disso, temos 5 vezes mais memória RAM e poupança de espaço em disco. Estou até em silêncio sobre o HDD.
Vejam bem. Acabei de medir a velocidade de leitura e escrita no meu SDD. Verificou-se que o tempo de escrita e leitura era de 8 bytes (1 tipo de valor duplo ou data de tempo ou longo) ~ 48 ns. E de acordo com os meus cálculos, o tempo de leitura de 8 bytes de informação da matriz embalada é de 1-2 ns. Assim, enquanto perdemos 1-2 ns no acesso a um elemento estruturante, ganhamos 48*0,8 = 38 ns para escrita e leitura a partir do disco. Além disso, temos 5 vezes mais memória e poupança de espaço em disco. Nem sequer estou a falar de HDD.
Eu não discuto com ele. Quando se trata especificamente de descarregar dados do disco, tem certamente razão. Há 4 anos atrás tivemos uma discussão com Renat sobre este tópico, na altura em que a SSD ainda era bastante incomum e a grande maioria dos utilizadores estava sentada em HDD lento.Então eu (com exemplo da minha SSD) tentei convencê-lo de que o funcionamento do HDD é a ligação mais lenta do sistema e devemos tentar minimizar a quantidade de dados consumidos a partir dela, e não vice-versa. Mas ele tinha tais argumentos: não há necessidade de sobrecarregar o CPU com trabalho extra, e todos vocês são tolos, não compreendem nada, etc. Em geral, tudo como de costume )
É verdade que o SSD acelerou significativamente nos dias de hoje.
Acontece que o tempo de escrita e leitura é de 8 bytes
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Insectos, insectos, perguntas
fxsaber, 2018.09.10 21:28
Primeiro, o diário de optimização.
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'Durante essas 7,5 horas, o SSD estava a ser acedido com uma enorme frequência. Se fossem lidos carraças em cada passe, isso funcionaria a uma média de 26 vezes por segundo durante 7,5 horas. Daí um piscar de olhos tão selvagem - mais de 700 mil leituras.
Registo de execução única
Como se viu, são utilizados ~130K carrapatos e barras de 60K (o modo "Todo o histórico" é seleccionado no Testador). Isto é, uma quantidade muito pequena de história.
O histórico do símbolo personalizado no Terminal contém a seguinte quantidade de dados do histórico
Isto é, na história do símbolo é muito pouco mais do que o uso do Testador.
ZS É uma pena olhar para o SSD... Quão mais rápido poderia ser o Optimista? Estranho que o sistema operativo não armazene estes dados, uma vez que são menos de 7MB de carraças em forma não comprimida.
Que pasta do Terminal via mklink para o disco RAM, para que os dados não sejam lidos/escritos a partir de SSD, mas sim a partir da memória? Estou disposto a fornecer os dados, que tipo de rapidez isto daria em Otimização.
Sim, isto é arquivístico. Se bem entendi, agora as carraças e as barras minúsculas são armazenadas sem embalagem, ou seja, para uma barra(estrutura MqlRates) são 60 bytes, e para uma carraça(estrutura MqlTick) são 52 bytes.
É horrível! Algo tem de ser feito há muito tempo atrás.
Compreendo que o principal problema com as matrizes comprimidas é a organização do acesso rápido a cada elemento da matriz.
Mas mesmo que armazenemos apenas cada 256º elemento de um array desempacotado e armazenemos noutros elementos apenas incrementos para desempacotados, podemos ver que o tamanho do array será 4-5 vezes menor e o tempo de acesso a cada elemento não aumentará muito (talvez 1-2 nanossegundos), mas poupará um enorme tempo na gravação e leitura do array de disco e para disco.
"Tudo já foi roubado antes de si" (cz)
No início do dia, é um tique cheio. Depois licitar e/ou perguntar e/ou virar tudo, tudo o resto em incrementos, se disponível. Uma média de 10 bytes por carrapato.
Uma vez que o acesso às carraças é estritamente sequencial, não há problema em arranjar um acesso rápido a cada elemento do conjunto
Um grande pedido para afixar a fonte do registo "Testador*.opt". Pode ver pelo conteúdo que o formato é muito simples.
Trabalhar com os resultados da Optimização é muito necessário. Obrigado!
Por alguma razão, o desempenho do testador diminui à medida que o número de ofícios aumenta. Não há qualquer referência ao histórico comercial por parte do Consultor Especialista.
Este não parece ser o caso.
No Testador, o intervalo correspondente ao modo "Todo o histórico" é memorizado. Acrescento o histórico ao símbolo personalizado, recarrego o Terminal, e o intervalo correspondente a "Todo o histórico" permanece inalterado.
Não posso alterar o modo padrão, mas se seleccionar todo o histórico, defino todo o histórico manualmente. Por favor, corrijam.
Falta uma cruz no local marcado - apagando a linha correspondente da entrada da cache.
Faço muitas optimizações. Alguns têm estado desactualizados há muito tempo. E não existe um mecanismo para eliminar estas opções. Por vezes obtém-se uma lista enorme e começa-se a procurar entre variantes desnecessárias.
Por conseguinte, por favor considere a remoção de dados desnecessários por cruzamento no local marcado na imagem.
Erro durante a execução
Resultado: verdadeiro:falso:7:4
Como é que as cordas de comprimentos diferentes são subitamente iguais? Enquanto a comparação usando StringCompare dá o oposto == resultado
Obrigado pelo post, alterámos o comportamento da comparação de caracteres por cadeia de caracteres.
Anteriormente as cordas eram comparadas como cordas Z (até ao carácter nulo), agora são comparadas como cordas PASCAL (tendo em conta o comprimento).
Os códigos existentes com cordas "normais" (sem o caracter Z dentro) não serão afectados por esta alteração.