Erros, bugs, perguntas - página 2284
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
As carraças não são armazenadas na RAM. São descarregados conforme necessário, de forma fragmentada, tal como eu o entendo.
Se por carraças reais, então sim.
Numa única passagem, pode ver estatísticas sobre quanta memória é gasta em armazenamento de carraças. Ao optimizar, não mais de 320 megas são armazenadas na memória de cada vez. O resto é armazenado em disco.
Estamos agora a considerar uma solução para manter todas as carraças na memória partilhada, para que todos os agentes locais possam ler a partir desta memória. Então não haverá acesso ao disco, e a optimização será mais rápida.
Se por carraças reais, sim.
É possível ver estatísticas sobre quanta memória é gasta para guardar carraças numa única passagem. Quando optimizado, não mais de 320 megas são armazenadas na memória de cada vez. Tudo o resto está em disco.
Estamos agora a considerar uma solução para manter todas as carraças numa memória partilhada, para que todos os agentes locais possam ler a partir desta memória. Então não haverá acesso ao disco e a optimização será mais rápida.
Sim, isto é arquivístico. Se bem entendi, agora as carraças e as barras minúsculas são armazenadas desembaladas no disco e na memória, ou seja, para a barra(estrutura MqlRates) são 60 bytes, e para o tick(estrutura MqlTick) são 52 bytes.
É horrível! Algo tem de ser feito há muito tempo atrás.
Compreendo que o principal problema das matrizes comprimidas é organizar o acesso rápido a cada item da matriz.
Mas mesmo que mantenhamos desempacotados apenas cada 256º elemento da matriz, e armazenemos nos outros elementos apenas incrementos para desempacotar, podemos ver que o tamanho da matriz será reduzido em 4-5 vezes e o tempo de acesso a cada elemento não aumentará muito (talvez 1-2 nanossegundos), mas poupará um tempo enorme na gravação e leitura da matriz de disco e para disco.
Porque é que o SSD está constantemente a ser tratado (a luz cintila a um ritmo elevado) durante a Optimização?
É por isso que não uso carraças, uso estrutura de dados logarítmica (já falei sobre isso), que num dado momento consiste num par de milhares de carraças, depois num par de milhares de barras de minutos, 2000 M2, 2000 M5 , M10, M30, H1, H3, H6, H12, D1, W1... todas as barras MN1.
Esta estrutura de dados históricos completos é formada em qualquer momento de menos de um milissegundo e ocupa apenas 1,5 MB na RAM (na verdade nem sequer na RAM, mas na cache do processador). E todos os algoritmos, aterrados para esta estrutura, apenas voam.
Afinal, a nossa visão é construída na mesma escala logarítmica: quanto mais olhamos, menos notamos pequenos detalhes.
Quando num futuro não muito distante, os computadores terão apenas um dispositivo de memória física (disco rígido, RAM, cache do processador), nomeadamente a cache do processador com 13 zeros, então também farei a troca para carrapatos :))
...
Embora, talvez seja eu fora do caminho, uma vez que com uma tal estrutura de dados durante a optimização a lâmpada também cintilará. Afinal, as carraças ainda serão carregadas :((
Se por carraças reais, sim.
É possível ver estatísticas sobre quanta memória é gasta em armazenamento de carraças numa única passagem. Quando optimizado, não mais de 320 megas são armazenadas na memória de cada vez. Tudo o resto está em disco.
Estamos agora a considerar uma solução para manter todas as carraças na memória partilhada, para que todos os agentes locais possam ler a partir desta memória. Então não haverá acesso ao disco, e a optimização será mais rápida.
Primeiro, vamos começar com o registo 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 foi 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 que o Testador usa.
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.
Mas mesmo que armazenemos apenas cada 256º elemento de um array desempacotado e armazenemos apenas incrementos de elementos desempacotados, o tamanho de um array irá reduzir em 4-5 vezes enquanto o tempo de acesso a cada elemento não irá aumentar muito (talvez em 1-2 nanossegundos), mas irá poupar imenso tempo ao salvar e ler um array de disco e para disco.
Renate não é suficiente para si ) Quantas vezes foi sugerido para optimizar o armazenamento do histórico. Especialmente porque nada precisa de ser gasto em compressão (que é a parte mais intensiva em recursos), porque os dados vêm inicialmente do servidor comprimido, e apenas a cache, que é constantemente utilizada, é mantida desembalada... Mas é aí que entra sempre a palestra: se não se pode comprar um disco rígido maior ou mais rápido, não há nada a fazer num MT. E os VPS lentos são sempre mencionados por alguma razão.
Renate não é suficiente para si ) Quantas vezes foi sugerido para optimizar o armazenamento do histórico. Especialmente porque nada precisa de ser gasto em compressão (que é a parte mais intensiva em recursos), porque os dados vêm originalmente do servidor comprimido, e apenas a cache, que é constantemente utilizada, é guardada de forma desempacotada... Mas é aí que entra sempre a palestra: se não se pode comprar um disco rígido maior ou mais rápido, não há nada a fazer num MT. E os VPS lentos são sempre mencionados por alguma razão.
Mais uma vez, o principal problema com as matrizes embaladas é organizar o acesso rápido a qualquer elemento da matriz, em vez de os ler sequencialmente. É por isso que aqui é necessário um formato de compressão diferente (ou melhor, até mesmo um formato de armazenamento), sim, de modo a não precisar de ser desempacotado e embalado. A compressão ~10 vezes como para zip, png, etc. claro que não vai funcionar, mas penso que 5 vezes é possível.
Bem, realmente, se pensarmos bem, em MqlRates 8*4=32 bytes são atribuídos para armazenar informação sobre barras de um minuto (enquanto apenas são armazenadas barras de um minuto), embora em 99% dos casos estes valores difiram em menos de um byte de informação, ou seja, 8+1+1+1=11 bytes é quase suficiente, mesmo que não esteja ligado a barras anteriores. E o tempo em 99 % dos casos difere do valor anterior exactamente em 60 (ou seja, em 99 % dos casos 1 bit de informação é suficiente - 60 ou não 60). E 8 bytes são atribuídos também para isto.
Mais uma vez, o principal problema com as matrizes embaladas é organizar o acesso rápido a qualquer elemento da matriz, em vez de os ler sequencialmente. É por isso que aqui é necessário um formato de compressão diferente (ou melhor, até mesmo um formato de armazenamento), sim, de modo a não precisar de ser desempacotado e embalado. Claro que, zip, png, etc. não podem ser comprimidos ~10 vezes, mas penso que 5 vezes é possível.
Se estamos a falar de armazenamento em disco, o acesso a um item específico não faz sentido, porque a operação de arquivo em si é dispendiosa. Assim, um grande pedaço é lido de uma só vez. Por exemplo, os arquivos de histórico de barras são repartidos por ano, carrapatos por mês. E se pretende manter a história em memória numa forma embalada, desempacotando constantemente cada elemento na mosca, então receio que não sirva a ninguém.
Acabo de inventar um formato de armazenamento que armazena blocos de 256 MqlRates elementos e leva em média 2900 bytes (o tamanho do bloco será flutuante), ou seja, 2900/256= ~12 bytes serão atribuídos por estrutura MqlRates, o que é 5 vezes menos, como eu pensava.
O acesso a cada elemento da estrutura de MqlRates embalados é suficientemente rápido (2-3 somas, 2-3 verificações, 2-3 turnos, ou seja, pouco mais de 1 nanossegundo)
Se estamos a falar de armazenamento em disco, o acesso a um determinado elemento não faz sentido, porque a operação de arquivo em si é dispendiosa. Por exemplo, os arquivos de histórico de barras são divididos por anos, as carraças são divididas por meses. E se pretende manter a história em memória numa forma embalada, desempacotando constantemente cada elemento na mosca, então receio que não sirva a ninguém.
Será armazenado em disco num formato "comprimido" e também lido na memória no mesmo formato. Não haverá conversão para um formato completo, mas haverá apenas um cálculo no momento da leitura de um elemento específico da estrutura de MqlRates. E será muito mais rápido, tendo em conta o facto de que haverá cinco vezes menos trabalho com o disco.
O acesso a cada elemento de uma estrutura MqlRates embalada é bastante rápido
...
Será armazenado no disco num formato "comprimido" e lido na memória no mesmo formato. Não haveria qualquer conversão para um formato completo, mas apenas os cálculos resultantes no momento da leitura de um elemento particular da estrutura MqlRates.
Sim, mas o conceito de "rápido" no seu caso é muito relativo. Uma coisa é que o utilizador solicitou um conjunto de barras, simplesmente copiou alguma área de memória, ou solicitou algumas séries temporais específicas, é 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 maneira. 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. O ideal seria, no entanto, ter tal opção no terminal para escolher como a história é armazenada na memória. Por exemplo, se o sistema tiver pouca RAM, mas um processador rápido, isto seria muito útil.