Precisa de ajuda! Não consigo resolver o problema, estou atingindo limitações de hardware - página 19
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
Então você teria que passar por vários milhões de negócios de outras seqüências! É exatamente isso que eu quero dizer.
Bem, estou falando de verificar um único número (número de seqüência), um milhão não é tanto para uma operação tão elementar. Se contarmos o critério recursivamente, é apenas uma passagem do arquivo, e teremos que fazê-lo de qualquer forma. Outra coisa a considerar é que o mapa de dados de recursividade conterá os mesmos vários milhões de elementos (multiplicados pelo número de parâmetros para uma seqüência).
Outra alternativa é recalcular completamente e armazenar critérios antes da triagem. Mais uma vez, a possibilidade de utilizar a recorrência é crítica.
É claro que haverá muitas operações, mas será menos na versão original?
Em C++ você pode fazer isso sem um analisador se:
empurrando a idéia 10 vezes - iniciar outro arquivo com os valores das posições iniciais das seqüências em outro arquivo, então você não precisa nem mesmo armazenar o número de trocas na estrutura da seqüência.
Você receberá um índice comum, que já foi mencionado anteriormente.
Eu implementei o algoritmo que descrevi acima.
O processamento de meus dados com X = 20 (cálculo do critério em 20 negócios) levou cerca de112 minutos (não pegou exatamente), a parte do leão foi comida por deslocamento de matriz (40% de acordo com o perfilador).
Após loops de arrays e alguma outra otimização, o processamento tornou-se mais rápido:
A memória só era suficiente para 65 transações (multiplicadas por um milhão de seqüências). Isto, é claro, não é suficiente - eu estava contando com pelo menos 100.
O passo seguinte foi descartar todas as informações desnecessárias sobre os ofícios. Deixando apenas os horários de abertura e fechamento, e lucro em pips, conseguiu decolar com X = 185.
Em seguida - basta acelerar o trabalho com o arquivo, FileReadXXX agora leva 30% do tempo (e o despachante diz que não há trabalho com o disco, mas a CPU está carregada).
FileRead é exatamente o primeiro após FileSeek, ou seja, a leitura sequencial funciona rapidamente.
Informá-lo-ei sobre novos resultados.
Em C++ é feito por fread em buffer 64K-128K, analisando-o melhor por seu próprio parser, porque os sscanf-es são muito lentos.
Tentarei trabalhar com os arquivos através do WinAPI, que me foi aconselhado pelo serviço de assistência técnica:
Estou empurrando a idéia 10 vezes - para iniciar outro arquivo com os valores das posições iniciais das seqüências em outro arquivo, então na estrutura da seqüência não será necessário nem mesmo armazenar o número de negócios.
Não entendo o que o índice vai fazer.
Escrever o número de ofícios não faz diferença, a leitura seqüencial funciona rapidamente, o problema é exatamente ler o bloco depois de mover-se em torno do arquivo.
Por favor, escreva um algoritmo sugerido.
O problema é não trivial, mas ainda não há uma única linha de código. Andrey, muitas pessoas aqui estão interessadas - formular o problema e oferecer dados de teste. Vamos organizar alguma programação esportiva.
Precisamos de dados de teste + pseudocódigo, com princípios gerais de trabalho com dados.
A tarefa é formulada do início ao fim.
E os dados do teste podem ser gerados com um script ligeiramente modificado, que eu publiquei anteriormente.
Farei isso um pouco mais tarde.
por que passar pelas opções da base? seria melhor gerar negócios na história de acordo com os critérios? não? isso não seria o mesmo que o necessário?
Se para testes, é claro, sim, mas se para resolver o problema, é claro, não )
Candidato:
Bem, estamos falando de verificar um único número (número de seqüência), um milhão não é tanto para uma operação tão elementar. Se considerarmos o critério recursivamente, é apenas um passo de arquivo, teremos que fazê-lo de qualquer forma. Outra coisa a considerar é que o mapa de dados de recursividade conterá os mesmos vários milhões de elementos (multiplicados pelo número de parâmetros para uma seqüência).
Outra alternativa é recalcular completamente e armazenar critériosantes da triagem. Mais uma vez, a possibilidade de utilizar a recorrência é crítica.
É claro que haverá muitas operações em qualquer caso, mas será que será menos na versão original?
Na variante inicial, você pode calcular o critério uma vez ao encontrar a última transação a partir do histórico passado.
E você precisa ler tal fragmento do arquivo que ele conteria X número de negócios de todas as seqüências. Será muito maior do que X * número de seqüências, pois há diferentes quantidades de negócios e podem não ser distribuídas uniformemente.
2 todos:
De qualquer forma, obrigado pelo apoio.
Se você não se importar, por favor, execute o roteiro de teste e compartilhe os resultados.
E os dados do teste podem ser gerados com o script ligeiramente modificado que publiquei anteriormente.
Estou anexando o roteiro atualizado, agora ele não apenas grava negócios idênticos, mas gera seqüências aleatórias com configurações especificadas(vida útil - de e para, lucro - de e para).
Para obter um arquivo comparável ao meu, execute o script com as configurações padrão:
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 140.000 seg. anotação em 57,1 seg
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 6632 Mb carregado em 44.0 seg(150.7 MB/seg)
Depois disso, você pode elaborar o algoritmo.
Para os mais preguiçosos, arquivar o arquivo no google drive.
komposter:
1. Na variante original, você pode calcular o critério uma vez ao encontrar o último negócio da história passada.
Em sua variante, você precisa ler tal pedaço de arquivo, que ele conteria X acordos de todas as seqüências. Será muito maior que X * número de seqüências, pois o número de negócios é diferente e eles podem não ser distribuídos uniformemente.
1 Isto não é muito claro, se estamos procurando o critério máximo (mínimo), ainda temos que computar o critério para todos os candidatos no final. Não importa sequer se o extremo local ou global está sendo procurado.
2. Claramente mais é a questão do tamanho aceitável ou não em termos de memória necessária. Além disso, um tamanho de bloco maior em termos de velocidade de leitura em disco é ainda melhor em teoria. Certamente, ainda não é um problema para a RAM. É de fundamental importância que a leitura seja feita de forma sequencial e apenas uma vez.
A variante de critérios de cálculo antes da ordenação, no entanto, requer a leitura duas vezes. Mas tem suas próprias vantagens, especialmente considerando a possibilidade de dividir os dados em vários arquivos menores e seu subsequente processamento conjunto.
Sem a implementação, entretanto, todos os argumentos permaneceriam abstratos. Portanto, neste ponto da discussão, terei apenas que divagar :)
Como fazer costura de arquivos com indexação de qual bit é o início e o fim de qual arquivo.
Por exemplo, faça 1000 metafiles de 1000 arquivos e, se os critérios forem conhecidos, faça uma ordenação estatística para encaixar arquivos semelhantes em um metafile.
Melhor experimentar com FileOpen, como funciona mais rápido para abrir um arquivo grande ou um arquivo pequeno, no sentido de abrir um arquivo 1000 vezes grande igual em tamanho a 1000 arquivos pequenos ou 1000000 vezes para abrir um arquivo pequeno?
Pode acontecer que os arquivos não devam ser fundidos, mas sim divididos.
Como fazer costura de arquivos com indexação de qual bit é o início e o fim de qual arquivo.
Por exemplo, faça 1000 metafiles de 1000 arquivos e, se os critérios forem conhecidos, faça uma ordenação estatística para encaixar arquivos semelhantes em um metafile.
Melhor experimentar com FileOpen, como funciona mais rápido para abrir um arquivo grande ou um arquivo pequeno, no sentido de abrir um arquivo 1000 vezes grande igual em tamanho a 1000 arquivos pequenos ou 1000000 vezes para abrir um arquivo pequeno?
Pode acontecer que os arquivos não devam ser fundidos, mas sim divididos.
Atualmente estou trabalhando com um arquivo grande, mas queria ir para um milhão de arquivos pequenos.
Em primeiro lugar, elas podem ser anexadas e, em segundo lugar, podem ser acessadas pelo nome (não há necessidade de armazenar "início de cada seqüência").
Eu perguntei no balcão de atendimento cerca de um milhão de aberturas de diferentes arquivos (tenho o cache implementado dessa forma). A resposta é clara e direta.
Vou testar as funções da api tanto para um grande arquivo quanto para milhões de pequenos, vou publicar os resultados.
Entretanto, sem a implementação, todos os argumentos permanecerão abstratos. Portanto, neste ponto da discussão, seria apropriado que eu me retirasse :)
Eu deveria ter começado com isso ;)
Mas em todo caso, graças à sua participação, as idéias sem código também são valiosas.
Com um milhão de arquivos, você arruinará ntfs de tal forma que você chorará desta louca criação da microsoft, que trancou todos para sempre em sua implementação insanamente lenta do sistema de arquivos.
Tudo o que ms tem feito em seus sistemas de arquivo é pesos monstruosos, retardamento e estupidez. Diabos, esses idiotas não fizeram nenhum esforço para otimizar e acelerar, e a api é apenas primitiva. Em 2014 isto pode ser declarado inequivocamente. Bem e chore.
Qualquer um que queira melhorar a eficiência do manuseio de um monte de arquivos em janelas, a primeira coisa a fazer é entrar em pedaços - agrupamento e sua própria estrutura de dados dentro de um único arquivo.
Quando você começa a armazenar mais de mil (muito menos dezenas ou centenas de milhares) de arquivos díspares em janelas, você está ferrado.
As operações de arquivo em MQL4/5 passam por nossos mecanismos de cache muito eficientes, que nos permitem alcançar velocidades de leitura e escrita muito eficientes e altas.
Você pode transmitir dados por byte - todos eles serão rapidamente coletados no buffer interno e escritos em disco apenas em grandes pedaços. O número de chamadas WinAPI é mínimo, o que proporciona uma operação de alta velocidade. A leitura é semelhante - ela funciona proativamente, lendo em grandes pedaços, muito raramente chamando WinAPI e muito rapidamente devolvendo dados de seu cache com o mínimo de despesas gerais.
Grosso modo, em comparação com a construção 509, aumentamos a velocidade das operações de arquivo em MQL4/5 por uma ordem de grandeza (se nos referimos à operação regular baseada em pedaços, em vez de "escrever por blocos de megabytes para maximizar as medições de velocidade").