Renat, zero point - 주제에 대한 관심과 건설적인 답변에 진심으로 감사드립니다!
더 나아가.
1. 프로 x64
Renat :
더 정확한 옵션은 x64로 전환하는 것입니다.
...
물론 누군가 언로드하지 않고 마켓 스캐닝 모드에서 수백 개의 지표를 호출하면 64비트 버전 + 추가 메모리 설치로만 직접 갈 수 있습니다.
이제 x32에서 대규모 테스트를 수행하는 것이 이상합니다. 16GB의 메모리가 있는 괜찮은 x64 컴퓨터(비디오 카드 및 모니터에 대한 열광적 없음)는 15,000루블에 구입할 수 있습니다.
x64로 전환하는 것은 어떤 방법으로든 올바른 조치입니다. 하지만. 하나는 다른 하나를 배제하지 않습니다. 16기가(나도 있음)도 실제로 필요하지 않은 데이터를 낭비하고 싶지 않습니다. MSVS, Matlab 등 병렬로 작업할 수 있는 다른 작업이 있습니다. 이 작업에서도 방대한 작업을 계산하고 싶습니다. 나는 당신이 이것을 이해하고 비용을 절약할 수 있는 방법을 찾을 준비가 된 것을 기쁘게 생각합니다.
2. 이야기의 고정된 시작에 대해:
레나트 :
우리는 자원 소비를 줄이기를 원합니다. 아마도 솔루션은 이 Expert Advisor에서 생성된 지표 에만 작용 하는 일부 함수 IndicatorMaxDepth(uint len)일 수 있습니다.
그러나 문제는 테스트 중에 누적 모드의 표시기 버퍼가 이력과 함께 증가하고 절약이 작동하지 않는다는 것입니다.
전적으로(거의) 동의합니다. 면책 조항: 많은 경우 최적화는 최신 기록의 작은 부분에 대해 수행됩니다. 이 경우 절감액은 상당히 클 수 있습니다. 그럼에도 불구하고 나는 이 옵션이 상대적으로 효과가 있다고 생각합니다. 특히 구현에 대한 좋은 개발이나 견적이 있는 경우에 그렇습니다. 예를 들어, 옵션이 완전하지 않은 것 같습니다. 인건비가 많이 들지만 결과는 급진적이지 않습니다. 절반 솔루션입니다.
3. 그리고 여기 그는 아이디어입니다! :
레나트 :
주어진 깊이를 유지하면서 지표의 역사를 실시간으로자르는것은 차트 막대와 지표 버퍼의 동기화를 고려/익숙한 프로그래머를 위한 아름다운 결함과 지붕의 직접적인 철거로 가득 차 있습니다.
안돼 ! 차트 막대가 같은 방식으로 동기적으로 작동하는 경우 무리가 없습니다. 즉, 링 버퍼(크기가 다르더라도) 항상 (강제로) AsSeries 플래그를 사용하는 경우 사용자 는 큰 문제를 겪지 않을 것으로 예상됩니다.
// 이 경우 사용자에게 제공되는 모든 히스토리 버퍼를 표시기(즉, AsSeries=true인 링)로 만드는 것이 편리합니다.
이 변형에서:
(1) 표시기 및 가격 배열의 내부 표현(귀하 측)이 있습니다. 왼쪽에서 오른쪽으로 인덱싱(AsSeries==false), 사용자 크기는 고려하지 않으며 일반적으로 " 입력 없음"입니다.
그리고 (2) 사용자 측이 있습니다. 모든 버퍼는 순환형이며(구현 시 사용자는 가상 선형 배열을 봅니다.) 오른쪽에서 왼쪽으로 인덱싱하고(AsSeries==true) 크기는 사용자가 설정합니다.
여기서 사용자 지붕의 철거는 무엇입니까? 없음. 지정된 범위를 벗어날 때 - 표준 반응 어레이가 범위를 벗어났습니다.
어려움(상당히, 솔직히 말해서)은 당신에게만 있습니다. 하지만! 계획의 다양성을 감안할 때 한 번만 변형해야합니다. 그리고 베타를 디버깅할 때 새싹의 모든 "아름다운 결함"을 수정합니다. 그 후 - 보편적 인 행복과 매우 경제적 인 디자인.
이제 최대 효율성의 원칙 대 메모리 절약의 원칙을 갖는 표시기 캐시를 수정합니다. 지금처럼 한동안 메모리에 보관하지 않고 버려진 표시기를 언로드해 보겠습니다. 이를 통해 IndicatorRelease를 통한 직접 업로드로 수백 개의 지표를 연속으로 호출할 수 있습니다.
좋은 생각. 나는 위해. 그러나 그것은 링 체계의 도입을 취소하지 않고 단순히 그것을 잘 보완합니다.
EA는 10,000바의 짧은 지표로 작동하며, 지표의 이력은 10,000 - 15,000바를 넘지 않도록 트리밍됩니다.
표시기의 자동 클리핑 결과:
하나.
우리는 누적성을 망친다(이것은 용인될 수 있지만 결과가 덜컥거리는 것은 피할 수 없는 결과로 이어질 것입니다. "예, 칠면조도 MT5에서 버그가 있습니다!")
예, 견딜 수 있습니다. 이것이 대중의 불만족으로 이어질 가능성은 낮고 오히려 절감 효과가 매우 고무적입니다. 거대한 MaxBar를 설정하여 메모리 낭비를 금지하는 사람은 없습니다.
// 여기 표시기는 건너뛰는 막대로 인해 버그가 있습니다! 불만이 심각하게 정당화되는 곳입니다!
// 그래서 당신은 그것을 견뎌야합니다 ... :) 글쎄, 우리는 ... :(
2.
우리는 지표의 역사에서 피할 수 없는 변화로 속도를 잃습니다(memcopy는 비싸지 만 메모리 양은 훨씬 더 비쌉니다).
그것은 단지 아니오와 아니오입니다! 링 구성표는 기록을 통해 이동할 때 복사 비용을 크게 절감합니다. 사실, 한 마디(N 마디)만큼 이동할 때 정확히 하나의 값(N개 값)을 복사해야 합니다. 인덱스 가상화를 위한 비용( 사용자 )은 무시할 수 있습니다. 사실, 스트레스 테스트 중에는 감지하기조차 어렵습니다( 나머지 나눗셈은 한 사이클에서 프로세서에 의해 계산됨 + 히스토리의 각 이동에서 버퍼의 가상 시작 오프셋 - 몇 사이클 더). 따라서 우리는 실제로 속도를 잃지 않습니다. 이 속도 저하를 감지하는 것은 불가능합니다. 너무 작습니다. 그리고 엄청난 메모리 절약을 배경으로 이러한 손실은 이득과 비교할 수 없습니다.
삼.
우리는 암기된 카운터에 베팅하는 프로그래머를 위해 지붕을 날려버렸습니다(이것은 개인의 정확도로 처리됩니다).
나는 그것이 무엇에 관한 것인지 조차 이해하지 못했다. 어쩌면 이곳에서 건강할 수도 있습니다.
웬일인지, 무제한 막대에 질식하는 표시 주위에 너무 많은 춤과 비명이 있지만 그래픽 개체 춤에 대한 단어는 없습니다. 예를 들어, 초대형 Andrews Pitchfork on Unlimited(예: MN1)를 구축한 다음 터미널 설정 에서 막대 수를 제한하고 더 낮은 시간 프레임으로 이동하여 앵커 포인트로 되감습니다. 그들 중 일부는 극단과 엄청난 시간 간격을 두고 있을 것입니다(이는 세 점 모두가 있는 갈퀴가 더 높은 시간대의 가짜 막대의 경계를 넘지 않고 실제 M1 막대 영역에만 독점적으로 놓여 있다는 사실에도 불구하고! ). 그리고 왜? 일부 자동 앵커 포인트의 정확한 M1 값을 계산하기 위해 M1 에 대한 기록 데이터가 충분하지 않았기 때문입니다. 하지만 과거 데이터는 어디에?! 충분했을 수도 있지만 창에 표시되는 막대가 부족하여 교대가 있습니다. 즉, 일부 포인트는 "그들은 자신이 어디에 누워 있는지 정말로 모릅니다."
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
Renat, zero point - 주제에 대한 관심과 건설적인 답변에 진심으로 감사드립니다!
더 나아가.
1. 프로 x64
Renat :
더 정확한 옵션은 x64로 전환하는 것입니다.
...
물론 누군가 언로드하지 않고 마켓 스캐닝 모드에서 수백 개의 지표를 호출하면 64비트 버전 + 추가 메모리 설치로만 직접 갈 수 있습니다.
이제 x32에서 대규모 테스트를 수행하는 것이 이상합니다. 16GB의 메모리가 있는 괜찮은 x64 컴퓨터(비디오 카드 및 모니터에 대한 열광적 없음)는 15,000루블에 구입할 수 있습니다.
x64로 전환하는 것은 어떤 방법으로든 올바른 조치입니다. 하지만. 하나는 다른 하나를 배제하지 않습니다. 16기가(나도 있음)도 실제로 필요하지 않은 데이터를 낭비하고 싶지 않습니다. MSVS, Matlab 등 병렬로 작업할 수 있는 다른 작업이 있습니다. 이 작업에서도 방대한 작업을 계산하고 싶습니다. 나는 당신이 이것을 이해하고 비용을 절약할 수 있는 방법을 찾을 준비가 된 것을 기쁘게 생각합니다.
2. 이야기의 고정된 시작에 대해:
레나트 :
우리는 자원 소비를 줄이기를 원합니다. 아마도 솔루션은 이 Expert Advisor에서 생성된 지표 에만 작용 하는 일부 함수 IndicatorMaxDepth(uint len)일 수 있습니다.
그러나 문제는 테스트 중에 누적 모드의 표시기 버퍼가 이력과 함께 증가하고 절약이 작동하지 않는다는 것입니다.
전적으로(거의) 동의합니다. 면책 조항: 많은 경우 최적화는 최신 기록의 작은 부분에 대해 수행됩니다. 이 경우 절감액은 상당히 클 수 있습니다. 그럼에도 불구하고 나는 이 옵션이 상대적으로 효과가 있다고 생각합니다. 특히 구현에 대한 좋은 개발이나 견적이 있는 경우에 그렇습니다. 예를 들어, 옵션이 완전하지 않은 것 같습니다. 인건비가 많이 들지만 결과는 급진적이지 않습니다. 절반 솔루션입니다.
3. 그리고 여기 그는 아이디어입니다! :
레나트 :
주어진 깊이를 유지하면서 지표의 역사를 실시간으로 자르는 것은 차트 막대와 지표 버퍼의 동기화를 고려/익숙한 프로그래머를 위한 아름다운 결함과 지붕의 직접적인 철거로 가득 차 있습니다.
안돼 ! 차트 막대가 같은 방식으로 동기적으로 작동하는 경우 무리가 없습니다. 즉, 링 버퍼(크기가 다르더라도) 항상 (강제로) AsSeries 플래그를 사용하는 경우 사용자 는 큰 문제를 겪지 않을 것으로 예상됩니다.
// 이 경우 사용자에게 제공되는 모든 히스토리 버퍼를 표시기(즉, AsSeries=true인 링)로 만드는 것이 편리합니다.
이 변형에서:
(1) 표시기 및 가격 배열의 내부 표현(귀하 측)이 있습니다. 왼쪽에서 오른쪽으로 인덱싱(AsSeries==false), 사용자 크기는 고려하지 않으며 일반적으로 " 입력 없음"입니다.
그리고 (2) 사용자 측이 있습니다. 모든 버퍼는 순환형이며(구현 시 사용자는 가상 선형 배열을 봅니다.) 오른쪽에서 왼쪽으로 인덱싱하고(AsSeries==true) 크기는 사용자가 설정합니다.
여기서 사용자 지붕의 철거는 무엇입니까? 없음. 지정된 범위를 벗어날 때 - 표준 반응 어레이가 범위를 벗어났습니다.
어려움(상당히, 솔직히 말해서)은 당신에게만 있습니다. 하지만! 계획의 다양성을 감안할 때 한 번만 변형해야합니다. 그리고 베타를 디버깅할 때 새싹의 모든 "아름다운 결함"을 수정합니다. 그 후 - 보편적 인 행복과 매우 경제적 인 디자인.
이제 최대 효율성의 원칙 대 메모리 절약의 원칙을 갖는 표시기 캐시를 수정합니다. 지금처럼 한동안 메모리에 보관하지 않고 버려진 표시기를 언로드해 보겠습니다. 이를 통해 IndicatorRelease를 통한 직접 업로드로 수백 개의 지표를 연속으로 호출할 수 있습니다.
3. 그리고 여기 그는 아이디어입니다! :
안돼 ! 차트 막대가 같은 방식으로 동기적으로 동작하는 경우에는 무리가 없습니다. 즉, 링 버퍼(크기가 다르더라도) 항상 (강제로) AsSeries 플래그를 사용하는 경우 사용자 는 큰 문제를 겪지 않을 것으로 예상됩니다.
// 이 경우 사용자에게 제공되는 모든 히스토리 버퍼를 표시기(즉, AsSeries=true인 링)로 만드는 것이 편리합니다.
이 변형에서:
(1) 표시기 및 가격 배열의 내부 표현(귀하 측)이 있습니다. 왼쪽에서 오른쪽으로 인덱싱(AsSeries==false), 사용자 크기는 고려하지 않으며 일반적으로 " 입력 없음"입니다.
그리고 (2) 사용자 측이 있습니다. 모든 버퍼는 순환형이며(구현 시 사용자는 가상 선형 배열을 봅니다.) 오른쪽에서 왼쪽으로 인덱싱하고(AsSeries==true) 크기는 사용자가 설정합니다.
여기서 사용자 지붕의 철거는 무엇입니까? 없음. 지정된 범위를 벗어날 때 - 표준 반응 어레이가 범위를 벗어났습니다.
어려움(상당히, 솔직히 말해서)은 당신에게만 있습니다. 하지만! 계획의 다양성을 감안할 때 한 번만 변형해야합니다. 그리고 베타를 디버깅할 때 새싹의 모든 "아름다운 결함"을 수정하십시오. 그 후 - 보편적 인 행복과 매우 경제적 인 디자인.
좋은 생각. 나는 위해. 그러나 그것은 링 체계의 도입을 취소하지 않고 단순히 그것을 잘 보완합니다.테스트 조건을 설명하겠습니다.
표시기의 자동 클리핑 결과:
테스트 조건을 설명하겠습니다.
표시기의 자동 클리핑 결과:
하나.
예, 견딜 수 있습니다. 이것이 대중의 불만족으로 이어질 가능성은 낮고 오히려 절감 효과가 매우 고무적입니다. 거대한 MaxBar를 설정하여 메모리 낭비를 금지하는 사람은 없습니다.
// 여기 표시기는 건너뛰는 막대로 인해 버그가 있습니다! 불만이 심각하게 정당화되는 곳입니다!
// 그래서 당신은 그것을 견뎌야합니다 ... :) 글쎄, 우리는 ... :(
2.
그것은 단지 아니오와 아니오입니다! 링 구성표는 기록을 통해 이동할 때 복사 비용을 크게 절감합니다. 사실, 한 마디(N 마디)만큼 이동할 때 정확히 하나의 값(N개 값)을 복사해야 합니다. 인덱스 가상화를 위한 비용( 사용자 )은 무시할 수 있습니다. 사실, 스트레스 테스트 중에는 감지하기조차 어렵습니다( 나머지 나눗셈은 한 사이클에서 프로세서에 의해 계산됨 + 히스토리의 각 이동에서 버퍼의 가상 시작 오프셋 - 몇 사이클 더). 따라서 우리는 실제로 속도를 잃지 않습니다. 이 속도 저하를 감지하는 것은 불가능합니다. 너무 작습니다. 그리고 엄청난 메모리 절약을 배경으로 이러한 손실은 이득과 비교할 수 없습니다.
삼.
아 얼굴...
웬일인지, 무제한 막대에 질식하는 표시 주위에 너무 많은 춤과 비명이 있지만 그래픽 개체 춤에 대한 단어는 없습니다. 예를 들어, 초대형 Andrews Pitchfork on Unlimited(예: MN1)를 구축한 다음 터미널 설정 에서 막대 수를 제한하고 더 낮은 시간 프레임으로 이동하여 앵커 포인트로 되감습니다. 그들 중 일부는 극단과 엄청난 시간 간격을 두고 있을 것입니다(이는 세 점 모두가 있는 갈퀴가 더 높은 시간대의 가짜 막대의 경계를 넘지 않고 실제 M1 막대 영역에만 독점적으로 놓여 있다는 사실에도 불구하고! ). 그리고 왜? 일부 자동 앵커 포인트의 정확한 M1 값을 계산하기 위해 M1 에 대한 기록 데이터가 충분하지 않았기 때문입니다. 하지만 과거 데이터는 어디에?! 충분했을 수도 있지만 창에 표시되는 막대가 부족하여 교대가 있습니다. 즉, 일부 포인트는 "그들은 자신이 어디에 누워 있는지 정말로 모릅니다."
누군가 집에서 확인만 해준다면, 그렇지 않으면 나에게 이런 만행이 있을지도...
한 가지 이상한 점을 발견했습니다!
새 막대 가 형성될 때 이전 막대의 Open 및 Close 값(예: 이전 막대 10개)을 세고 5초 후에 다시 가져오면 이 값 중 일부 다른 다음 새 막대가 형성되는 동안 값을 얻으면 모든 것이 정상이지만 처음 몇 초 동안에는 어떤 이유로 이러한 값이 다릅니다.
나는 내가 명확하게 설명했기를 바랍니다.
새로운 막대의 시작 부분에서 열기 및 닫기 막대의 값을 읽기 전에 5초 이상의 지연을 설정해야 한다고 말하지 마십시오.
다음은 작업의 예입니다.
위는 지연 후 올바르게 작동했고 아래는 오류가 있는 새 막대가 나타난 직후에 작동했으며 오른쪽은 6번째 줄에 대한 표준입니다.
아마도 문제가 동기화되지 않았을 수 있으므로 사용된 모든 악기에 대해 새 막대 를 추적하는 것이 바람직합니다.
예, 당신이 옳았습니다. 감사합니다!
마찬가지로 오페라.