한 번의 패스로 통계를 볼 수 있으며, 틱을 저장하는 데 얼마나 많은 메모리가 사용되었는지 확인할 수 있습니다. 최적화할 때 동시에 320메가가 메모리에 저장되지 않습니다. 다른 모든 것은 디스크에 있습니다.
우리는 이제 모든 로컬 에이전트가 이 메모리에서 읽을 수 있도록 모든 틱을 공유 메모리에 유지하는 솔루션을 고려하고 있습니다. 그러면 디스크에 액세스할 수 없으며 최적화가 더 빨라집니다.
네, 아카이브입니다. 내가 올바르게 이해했다면 이제 디스크에 있는 것, 메모리에 있는 것, 눈금 및 분 막대가 압축되지 않은 형태로 저장됩니다. 막대( MqlRates 구조 )의 경우 60바이트이고 틱( MqlTick 구조 )의 경우 52바이트입니다. 공포! 이 문제에 대해 오랫동안 조치를 취해야 합니다.
압축된 배열의 주요 문제는 배열의 각 요소에 대한 빠른 액세스 구성이라는 것을 알고 있습니다.
그러나 압축을 푼 배열의 256번째 요소만 저장하고 다른 요소에 압축을 푼 요소의 증분만 저장하더라도 배열의 크기는 눈으로 보면 4-5배 줄어들고 각 요소에 대한 액세스 시간은 그다지 증가하지는 않지만(1-2나노초 정도) 디스크에서 디스크로 어레이를 저장하고 읽는 데 드는 시간을 크게 절약할 수 있습니다.
fxsaber : 최적화 중에 SSD에 지속적으로 액세스하는 이유는 무엇입니까(고주파로 표시등이 깜박임)?
이것이 바로 내가 틱을 사용하지 않고 주어진 시간에 몇 천 틱, 그 다음 몇 천 분 막대, 2000 M2, 2000 M5로 구성된 대수 데이터 구조 를 사용하는 이유입니다. , M10, M30, H1, H3, H6, H12, D1, W1... 모든 MN1 막대. 이러한 완전한 기록 데이터 구조는 밀리초 미만의 시간에 형성되며 RAM에서 1.5MB만 차지합니다(더 정확하게는 RAM이 아니라 프로세서 캐시에서). 그리고 이 구조에 맞춰진 모든 알고리즘은 그냥 날아갑니다.
결국, 우리의 비전은 동일한 대수 규모로 배열됩니다. 더 멀리 볼수록 작은 세부 사항을 덜 알아차립니다.
추신 그것이 머지 않은 미래에 컴퓨터의 모든 메모리 장치(하드 디스크, RAM, 프로세서 캐시)가 물리적으로 단 하나의 장치, 즉 13개의 0이 있는 숫자 크기의 프로세서 캐시가 될 때입니다. 틱 :))
...
비록, 아마도, 나는 주제를 벗어났지만, 왜냐하면. 이러한 데이터 구조를 사용하면 최적화 중에 전구도 깜박입니다. 결국, tiki는 여전히 로드될 것입니다 :((
그러나 압축을 푼 배열의 256번째 요소만 저장하고 다른 요소에 압축을 푼 요소의 증분만 저장하더라도 배열의 크기는 눈으로 보면 4-5배 줄어들고 각 요소에 대한 액세스 시간은 그다지 증가하지는 않지만(1-2나노초 정도) 디스크에서 디스크로 어레이를 저장하고 읽는 데 드는 시간을 크게 절약할 수 있습니다.
레나타로는 충분하지 않습니다) 코코는 히스토리 저장을 최적화하기 위해 제안되었기 때문입니다. 특히 압축에 비용을 지출할 필요가 없다는 점을 고려하면(그리고 이것이 가장 리소스 집약적인 부분입니다), 왜냐하면. 데이터는 처음에 압축된 서버에서 가져옵니다. 그리고 압축을 푼 형태에서는 지속적으로 사용되는 캐시만 보관합니다... 그러나 여기 강의는 일반적으로 항상 스타일로 시작됩니다. 더 크거나 더 빠른 나사를 스스로 살 수 없다면 MT에서 할 일이 없습니다. 그리고 어떤 이유로 우리는 항상 느린 VPS에 대해 이야기하고 있습니다.
레나타로는 충분하지 않습니다) 코코는 히스토리 저장을 최적화하기 위해 제안되었기 때문입니다. 특히 압축에 비용을 지출할 필요가 없다는 점을 고려하면(그리고 이것이 가장 리소스 집약적인 부분입니다), 왜냐하면. 데이터는 처음에 압축된 서버에서 가져옵니다. 그리고 압축을 푼 형태에서는 지속적으로 사용되는 캐시만 보관합니다... 그러나 여기 강의는 일반적으로 항상 스타일리시하게 시작됩니다. 더 크거나 더 빠른 나사를 스스로 살 수 없다면 MT에서 할 일이 없습니다. 그리고 어떤 이유로 우리는 항상 느린 VPS에 대해 이야기하고 있습니다.
나는 패킹된 배열의 주요 문제가 배열의 모든 요소에 빠르게 액세스할 수 있도록 구성하는 것이지 순차적 읽기가 아니라는 점을 다시 한 번 반복합니다. 따라서 여기에는 다른 압축 형식(더 정확하게는 저장 형식도 필요)이 필요하지만 압축을 풀고 포장할 필요가 없는 형식입니다. zip, png 등 ~ 10배 압축은 당연히 안되지만 5배 정도는 가능한 것 같아요.
음, 정말, 생각해보면 MqlRates에서 닫기, 열기, 높음, 낮음에서 분 막대(분 막대만 저장됨)에 대한 정보를 저장하기 위해 최대 8 * 4 = 32바이트가 할당되지만 99%의 경우 이러한 값은 바이트 정보보다 적습니다. 8+1+1+1=11 바이트는 이미 지난 막대에 첨부하지 않아도 거의 충분합니다. 그리고 99%의 경우 시간은 이전 값과 정확히 60만큼 다릅니다(즉, 99%의 경우 1비트 정보로 충분합니다 - 60 또는 60이 아님). 그리고 이를 위해 8바이트도 할당됩니다.
나는 패킹된 배열의 주요 문제가 배열의 모든 요소에 빠르게 액세스할 수 있도록 구성하는 것이지 순차적 읽기가 아니라는 점을 다시 한 번 반복합니다. 따라서 여기에는 다른 압축 형식(더 정확하게는 저장 형식도 필요)이 필요하지만 압축을 풀고 포장할 필요가 없는 형식입니다. zip, png 등 ~ 10배 압축은 당연히 안되지만 5배 정도는 가능한 것 같아요.
디스크의 스토리지에 대해 이야기하는 경우 특정 요소에 액세스하는 것은 의미가 없습니다. 파일 작업 자체에 비용이 많이 듭니다. 따라서 큰 부분을 즉시 읽습니다. 예를 들어, 막대 기록 파일은 연도, 눈금 - 월로 나뉩니다. 물론 더 작게 부수는 것이 낫지 만. 그리고 일반적으로 기록을 압축된 형태로 메모리에 유지하고 각 요소를 즉석에서 지속적으로 압축을 푸는 것을 의미한다면 이것이 소수의 사람들에게 적합하지 않을까 걱정됩니다.
디스크의 스토리지에 대해 이야기하는 경우 특정 요소에 액세스하는 것은 의미가 없습니다. 파일 작업 자체가 비용이 많이 듭니다. 따라서 큰 부분을 즉시 읽습니다. 예를 들어, 막대 기록 파일은 연도, 눈금 - 월로 나뉩니다. 물론 더 작게 부수는 것이 낫지 만. 그리고 일반적으로 기록을 압축된 형태로 메모리에 유지하고 각 요소를 즉석에서 지속적으로 압축을 푸는 것을 의미한다면 이것이 소수의 사람들에게 적합하지 않을까 걱정됩니다.
"압축된" 형식으로 디스크에 저장되고 동일한 형식으로 메모리로 읽어들입니다. 전체 형식으로의 변환은 수행되지 않으며 MqlRates 구조의 특정 요소를 읽는 순간에만 계산이 수행됩니다. 그리고 디스크 작업이 5배 줄어들 것이라는 점을 감안하면 훨씬 더 빠를 것입니다.
"압축된" 형식으로 디스크에 저장되고 동일한 형식으로 메모리로 읽어들입니다. 전체 형식으로의 변환은 수행되지 않으며 MqlRates 구조의 특정 요소를 읽는 순간에만 계산이 수행됩니다.
어-허, 귀하의 경우에 "기민함"이라는 개념만 매우 상대적입니다. 사용자가 막대 배열을 요청하는 것은 한 가지입니다. 메모리 조각이 단순히 그에게 복사되었습니다. 또는 특정 시계열을 요청한 경우 구조의 크기와 동일한 일정한 단계로 데이터의 간단한 복사도 있습니다. 그리고 또 다른 문제 - 각 숫자에 대한 추가 계산 및 변환.
개인적으로 나는 간결한 역사를 선호하지만 기억을 낭비하지 않기 때문입니다. 어쨌든, 나는 그것의 저장을 위해 내 자신의 배열을 구성합니다. 그래서 조금 기다리겠습니다. 그러나 대부분의 다른 사용자는 이것을 위해 당신을 조각으로 찢을 것입니다)
ps 비록 이상적으로는, 메모리에 히스토리를 저장하는 모드를 선택하기 위해 터미널에 그러한 옵션이 있으면 좋을 것입니다. 예를 들어 시스템에 RAM이 거의 없지만 프로세서는 빠른 경우 매우 유용합니다.
따라서 틱은 RAM에 저장되지 않습니다. 내가 이해한 대로 부분적으로 필요에 따라 다운로드했습니다.
실제 진드기에 의한 경우 그렇습니다.
한 번의 패스로 통계를 볼 수 있으며, 틱을 저장하는 데 얼마나 많은 메모리가 사용되었는지 확인할 수 있습니다. 최적화할 때 동시에 320메가가 메모리에 저장되지 않습니다. 다른 모든 것은 디스크에 있습니다.
우리는 이제 모든 로컬 에이전트가 이 메모리에서 읽을 수 있도록 모든 틱을 공유 메모리에 유지하는 솔루션을 고려하고 있습니다. 그러면 디스크에 액세스할 수 없으며 최적화가 더 빨라집니다.
실제 진드기에 의한 경우 그렇습니다.
한 번의 패스로 통계를 볼 수 있으며, 틱을 저장하는 데 얼마나 많은 메모리가 사용되었는지 확인할 수 있습니다. 최적화할 때 동시에 320메가가 메모리에 저장되지 않습니다. 다른 모든 것은 디스크에 있습니다.
우리는 이제 모든 로컬 에이전트가 이 메모리에서 읽을 수 있도록 모든 틱을 공유 메모리에 유지하는 솔루션을 고려하고 있습니다. 그러면 디스크에 액세스할 수 없으며 최적화가 더 빨라집니다.
네, 아카이브입니다. 내가 올바르게 이해했다면 이제 디스크에 있는 것, 메모리에 있는 것, 눈금 및 분 막대가 압축되지 않은 형태로 저장됩니다. 막대( MqlRates 구조 )의 경우 60바이트이고 틱( MqlTick 구조 )의 경우 52바이트입니다.
공포! 이 문제에 대해 오랫동안 조치를 취해야 합니다.
압축된 배열의 주요 문제는 배열의 각 요소에 대한 빠른 액세스 구성이라는 것을 알고 있습니다.
그러나 압축을 푼 배열의 256번째 요소만 저장하고 다른 요소에 압축을 푼 요소의 증분만 저장하더라도 배열의 크기는 눈으로 보면 4-5배 줄어들고 각 요소에 대한 액세스 시간은 그다지 증가하지는 않지만(1-2나노초 정도) 디스크에서 디스크로 어레이를 저장하고 읽는 데 드는 시간을 크게 절약할 수 있습니다.
최적화 중에 SSD에 지속적으로 액세스하는 이유는 무엇입니까(고주파로 표시등이 깜박임)?
이것이 바로 내가 틱을 사용하지 않고 주어진 시간에 몇 천 틱, 그 다음 몇 천 분 막대, 2000 M2, 2000 M5로 구성된 대수 데이터 구조 를 사용하는 이유입니다. , M10, M30, H1, H3, H6, H12, D1, W1... 모든 MN1 막대.
이러한 완전한 기록 데이터 구조는 밀리초 미만의 시간에 형성되며 RAM에서 1.5MB만 차지합니다(더 정확하게는 RAM이 아니라 프로세서 캐시에서). 그리고 이 구조에 맞춰진 모든 알고리즘은 그냥 날아갑니다.
결국, 우리의 비전은 동일한 대수 규모로 배열됩니다. 더 멀리 볼수록 작은 세부 사항을 덜 알아차립니다.
추신 그것이 머지 않은 미래에 컴퓨터의 모든 메모리 장치(하드 디스크, RAM, 프로세서 캐시)가 물리적으로 단 하나의 장치, 즉 13개의 0이 있는 숫자 크기의 프로세서 캐시가 될 때입니다. 틱 :))
...
비록, 아마도, 나는 주제를 벗어났지만, 왜냐하면. 이러한 데이터 구조를 사용하면 최적화 중에 전구도 깜박입니다. 결국, tiki는 여전히 로드될 것입니다 :((
실제 진드기에 의한 경우 그렇습니다.
한 번의 패스로 통계를 볼 수 있으며, 틱을 저장하는 데 얼마나 많은 메모리가 사용되었는지 확인할 수 있습니다. 최적화할 때 동시에 320메가가 메모리에 저장되지 않습니다. 다른 모든 것은 디스크에 있습니다.
우리는 이제 모든 로컬 에이전트가 이 메모리에서 읽을 수 있도록 모든 틱을 공유 메모리에 유지하는 솔루션을 고려하고 있습니다. 그러면 디스크에 액세스할 수 없으며 최적화가 더 빨라집니다.
첫 번째 최적화 로그
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'이 7.5시간 동안 SSD는 엄청난 빈도로 액세스되었습니다. 각 패스에서 틱을 읽으면 7.5시간 동안 초당 평균 26번으로 나타납니다. 따라서 그러한 야생 깜박임 - 700,000 개 이상의 판독 값.
단일 실행 로그
~130K 틱과 60K 막대가 사용되는 것을 볼 수 있습니다(테스터에서 "모든 기록" 모드가 선택됨). 저것들. 글쎄, 아주 약간의 역사.
터미널 자체에 있는 커스텀 심볼 의 히스토리에는 너무 많은 히스토리 데이터가 포함되어 있습니다.
저것들. 기호의 역사에서 테스터가 사용하는 것보다 훨씬 많습니다.
위협 SSD를 보니 아쉽네요... 최적화 속도는 얼마나 더 높을 수 있을까요? OS가 이 데이터를 캐시하지 않는 것이 이상합니다. 압축되지 않은 형식으로 7M 틱 미만이기 때문입니다.
그러나 압축을 푼 배열의 256번째 요소만 저장하고 다른 요소에 압축을 푼 요소의 증분만 저장하더라도 배열의 크기는 눈으로 보면 4-5배 줄어들고 각 요소에 대한 액세스 시간은 그다지 증가하지는 않지만(1-2나노초 정도) 디스크에서 디스크로 어레이를 저장하고 읽는 데 드는 시간을 크게 절약할 수 있습니다.
레나타로는 충분하지 않습니다) 코코는 히스토리 저장을 최적화하기 위해 제안되었기 때문입니다. 특히 압축에 비용을 지출할 필요가 없다는 점을 고려하면(그리고 이것이 가장 리소스 집약적인 부분입니다), 왜냐하면. 데이터는 처음에 압축된 서버에서 가져옵니다. 그리고 압축을 푼 형태에서는 지속적으로 사용되는 캐시만 보관합니다... 그러나 여기 강의는 일반적으로 항상 스타일로 시작됩니다. 더 크거나 더 빠른 나사를 스스로 살 수 없다면 MT에서 할 일이 없습니다. 그리고 어떤 이유로 우리는 항상 느린 VPS에 대해 이야기하고 있습니다.
레나타로는 충분하지 않습니다) 코코는 히스토리 저장을 최적화하기 위해 제안되었기 때문입니다. 특히 압축에 비용을 지출할 필요가 없다는 점을 고려하면(그리고 이것이 가장 리소스 집약적인 부분입니다), 왜냐하면. 데이터는 처음에 압축된 서버에서 가져옵니다. 그리고 압축을 푼 형태에서는 지속적으로 사용되는 캐시만 보관합니다... 그러나 여기 강의는 일반적으로 항상 스타일리시하게 시작됩니다. 더 크거나 더 빠른 나사를 스스로 살 수 없다면 MT에서 할 일이 없습니다. 그리고 어떤 이유로 우리는 항상 느린 VPS에 대해 이야기하고 있습니다.
나는 패킹된 배열의 주요 문제가 배열의 모든 요소에 빠르게 액세스할 수 있도록 구성하는 것이지 순차적 읽기가 아니라는 점을 다시 한 번 반복합니다. 따라서 여기에는 다른 압축 형식(더 정확하게는 저장 형식도 필요)이 필요하지만 압축을 풀고 포장할 필요가 없는 형식입니다. zip, png 등 ~ 10배 압축은 당연히 안되지만 5배 정도는 가능한 것 같아요.
음, 정말, 생각해보면 MqlRates에서 닫기, 열기, 높음, 낮음에서 분 막대(분 막대만 저장됨)에 대한 정보를 저장하기 위해 최대 8 * 4 = 32바이트가 할당되지만 99%의 경우 이러한 값은 바이트 정보보다 적습니다. 8+1+1+1=11 바이트는 이미 지난 막대에 첨부하지 않아도 거의 충분합니다. 그리고 99%의 경우 시간은 이전 값과 정확히 60만큼 다릅니다(즉, 99%의 경우 1비트 정보로 충분합니다 - 60 또는 60이 아님). 그리고 이를 위해 8바이트도 할당됩니다.
나는 패킹된 배열의 주요 문제가 배열의 모든 요소에 빠르게 액세스할 수 있도록 구성하는 것이지 순차적 읽기가 아니라는 점을 다시 한 번 반복합니다. 따라서 여기에는 다른 압축 형식(더 정확하게는 저장 형식도 필요)이 필요하지만 압축을 풀고 포장할 필요가 없는 형식입니다. zip, png 등 ~ 10배 압축은 당연히 안되지만 5배 정도는 가능한 것 같아요.
디스크의 스토리지에 대해 이야기하는 경우 특정 요소에 액세스하는 것은 의미가 없습니다. 파일 작업 자체에 비용이 많이 듭니다. 따라서 큰 부분을 즉시 읽습니다. 예를 들어, 막대 기록 파일은 연도, 눈금 - 월로 나뉩니다. 물론 더 작게 부수는 것이 낫지 만. 그리고 일반적으로 기록을 압축된 형태로 메모리에 유지하고 각 요소를 즉석에서 지속적으로 압축을 푸는 것을 의미한다면 이것이 소수의 사람들에게 적합하지 않을까 걱정됩니다.
방금 256 MqlRates 요소 블록을 저장하고 평균 2900바이트(블록 크기는 부동)를 사용하는 저장 형식을 생각해 냈습니다. 2900/256= ~ 12바이트가 하나 의 MqlRates 구조 에 할당되며, 이는 예상대로 5배 적습니다.
이러한 패킹된 MqlRates 구조의 각 요소에 대한 액세스는 매우 빠릅니다(2-3개의 합계, 2-3개의 검사, 2-3개의 이동, 즉 1나노초를 넘지 않음).
디스크의 스토리지에 대해 이야기하는 경우 특정 요소에 액세스하는 것은 의미가 없습니다. 파일 작업 자체가 비용이 많이 듭니다. 따라서 큰 부분을 즉시 읽습니다. 예를 들어, 막대 기록 파일은 연도, 눈금 - 월로 나뉩니다. 물론 더 작게 부수는 것이 낫지 만. 그리고 일반적으로 기록을 압축된 형태로 메모리에 유지하고 각 요소를 즉석에서 지속적으로 압축을 푸는 것을 의미한다면 이것이 소수의 사람들에게 적합하지 않을까 걱정됩니다.
"압축된" 형식으로 디스크에 저장되고 동일한 형식으로 메모리로 읽어들입니다. 전체 형식으로의 변환은 수행되지 않으며 MqlRates 구조의 특정 요소를 읽는 순간에만 계산이 수행됩니다. 그리고 디스크 작업이 5배 줄어들 것이라는 점을 감안하면 훨씬 더 빠를 것입니다.
이러한 패킹된 MqlRates 구조의 각 요소에 대한 액세스는 충분히 빠릅니다.
...
"압축된" 형식으로 디스크에 저장되고 동일한 형식으로 메모리로 읽어들입니다. 전체 형식으로의 변환은 수행되지 않으며 MqlRates 구조의 특정 요소를 읽는 순간에만 계산이 수행됩니다.
어-허, 귀하의 경우에 "기민함"이라는 개념만 매우 상대적입니다. 사용자가 막대 배열을 요청하는 것은 한 가지입니다. 메모리 조각이 단순히 그에게 복사되었습니다. 또는 특정 시계열을 요청한 경우 구조의 크기와 동일한 일정한 단계로 데이터의 간단한 복사도 있습니다. 그리고 또 다른 문제 - 각 숫자에 대한 추가 계산 및 변환.
개인적으로 나는 간결한 역사를 선호하지만 기억을 낭비하지 않기 때문입니다. 어쨌든, 나는 그것의 저장을 위해 내 자신의 배열을 구성합니다. 그래서 조금 기다리겠습니다. 그러나 대부분의 다른 사용자는 이것을 위해 당신을 조각으로 찢을 것입니다)
ps 비록 이상적으로는, 메모리에 히스토리를 저장하는 모드를 선택하기 위해 터미널에 그러한 옵션이 있으면 좋을 것입니다. 예를 들어 시스템에 RAM이 거의 없지만 프로세서는 빠른 경우 매우 유용합니다.