기고글 토론 "보조 인디케이터 메모리 소모량 감소시키기"

[MetaQuotes]

새로운 기고글 보조 인디케이터 메모리 소모량 감소시키기 가 게재되었습니다:

인디케이터가 다른 인디케이터들의 값을 받아와 계산하는 경우 많은 메모리량이 필요합니다. 본 문서에서는 보조 인디케이터를 사용할 때에 소모되는 메모리량을 감소시키는 다양한 방법에 대하여 논할 것입니다. 메모리를 절약하면 클라이언트 내에서 동시에 이용 가능한 화폐쌍, 인디케이터, 전략을 늘려 더욱 ㅏㄴ은 여지를 줍니다. 이는 매매 포트폴리오의 안정성을 증진시킵니다. 이러한 간단한 관리만으로도 당신의 컴퓨터 리소스가 자산으로 환원될 수 있습니다.

아마 기존에 보조 인디케이터를 활용하는 Expert Advisor나 인디케이터를 생성하거나 사용해보신 적 있을 것입니다.

예를 들어, 유명한 인디케이터인 MACD는 EMA (Exponential Moving Average, 지수이동평균) 인디케이터를 계산 과정 중에 두 개 사용합니다.

그런 복잡한 인디케이터도 사실 쪼개고 쪼개면 간단한 인디케이터 여러개로 구성되어있습니다. 예를 들어 앞에 언급한 MACD는 단일 EMA보다 3배 많은 메모리와 처리량을 요구하는데 이는 메인 인디케이터 버퍼와 보조 인디케이터 버퍼용 메모리를 할당해야하기 때문입니다.

작성자: ds2

[Mykola Demko]

접근 방식은 이해할 수 있습니다. 그러나 작업의 관련성이 혼란스럽습니다.

64비트 시스템은 엄청난 양의 RAM을 지원하지만 작업의 관련성은 희미해집니다. 3Gb의 32 비트조차도 저장하는 메모리 크기를 상당히 끌어낼 수 있습니다. 결국, 어떻게 보더라도 새 지표를로드 할 때 메모리는 선형 적으로 증가하므로 최신 컴퓨터에서 48MB 이상 또는 그 미만은 아무것도 아닙니다.

좋아, 작업이 관련성이 있다고 가정 해 봅시다 (나는 그것에 관심이있는 사람들이 있다는 데 동의합니다). 그러나 생각해 보면 메모리 절약 작업은 성능 작업과 직접적으로 충돌합니다.

따라서이 점에도주의를 기울여야합니다.

제 관점에서 볼 때 MQ는 성능을 위해 싸우고 있으며 모든 노력이 집중되는 곳입니다.

그려지지 않은 인디케이터에 메모리 리소스를 절약해야 하는 경우 인디케이터 코드를 전문가 어드바이저로 전송하기만 하면 됩니다. 여기에서 할당된 메모리를 완전히 제어할 수 있습니다. 동시에 동일한 유형의 데이터를 수신하는 데 드는 비용을 절약할 수 있습니다. 많은 인디케이터가 각각 자체 처리를 위해 동일한 데이터를 요청합니다. 데이터를 한 번 받으면 다음 번에는 데이터를 처리할 필요가 없습니다.

이제 작업 속도와 메모리 크기를 결합해 보겠습니다. 대부분의 비 그리기 표시기는 마지막 막대 계산에 관여하며 이는 전체 배열의 재 계산을 차단하는 내장 메커니즘으로 표시됩니다. 전문가 고문에서 154 개의 메모리 셀 (예 : 153의 기간이있는 마스크 계산 용)을 할당 할 수 있으므로 이러한 메모리 절약으로 성능이 일반 표시기보다 나쁘지 않을 것임이 밝혀졌습니다.

그러나 Expert Advisor에서는 계산을 병렬화할 수 있는 가능성이 사라지며 이는 성능에 직접적인 타격을 줍니다. 실제로 인디케이터는 병렬 처리로 인해 메모리를 소모합니다. 결국 각 인디케이터는 자체 스레드에서 작동하며 이 스레드에는 소스 데이터의 자체 인스턴스가 있어야 합니다.

[[삭제]]

동의합니다. 성능이 최우선이며 메모리를 절약할 필요가 없습니다(물론 1Gb 이상을 사용하지 않는다면 그럴 가능성은 거의 없습니다).

[ds2]

Urain:

접근 방식은 이해할 수 있습니다. 그러나 작업의 긴급 성은 혼란 스럽습니다.

글쎄요, 사실 제가 특정 복합 지표를 작성한 한 사람이이 지표가 일부 쌍에 설치되지 않았다고 불평 한 후이 기사를 쓰겠다는 생각이 떠 올랐습니다. 조사 결과 매우 지속적인 지표가 있고 많은 지표가 터미널에 맞지 않는 것으로 나타났습니다 (즉, 문제는 쌍에 있지 않고이 쌍이 동일한 지속적인 지표로 12 개 더 열리기 전에 문제가 있다는 사실에 있음). 이 표시기는 기사의 테스트 표시기보다 2 배 더 많이 소비했습니다.

3GB의 32 비트조차도 이러한 메모리 크기를 상당히 끌어낼 수 있습니다.

많은 수의 쌍으로 거래하는 경우 그렇지 않습니다.

그건 그렇고, 터미널은 2Gb 이상의 메모리 (총 : RAM + 가상 메모리)를 할당 할 수 없습니다. 제 실험에서는이 표시에서 닫혔습니다.

물론이 문제는 64 비트에서는 존재하지 않아야합니다.

좋아, 작업이 관련성이 있다고 가정 해 봅시다 (나는 그것에 관심이있는 사람들이 있다는 데 동의합니다). 그러나 생각해 보면 메모리 절약 작업은 성능 작업과 직접적으로 모순됩니다.

항상 그런 것은 아닙니다. 이 기사에서 대부분의 방법은 성능을 저하시키지 않습니다.

그릴 수 없는 인디케이터에 메모리 리소스를 절약해야 하는 경우 인디케이터 코드를 Expert Advisor로 옮기면 됩니다.

인디케이터에서 마지막 막대만 요청하는 Expert Advisor는 이 글에서 고려한 것과는 다른 종류의 프로그램입니다. 그리고 하나를 다른 것으로 대체하는 것이 항상 가능하거나 편리한 것은 아닙니다.

하지만 전문가용 어드바이저에서는 계산을 병렬화할 수 있는 가능성이 사라지며 이는 성능에 직접적인 타격을 줍니다. 실제로 인디케이터는 병렬 처리 때문에 메모리를 소모합니다. 결국 각 인디케이터는 자체 스레드에서 작동하며 이 스레드에는 소스 데이터의 자체 인스턴스가 있어야 합니다(
).

공통 쌍의 각 지표에 자체 데이터 인스턴스가있을 가능성은 거의 없습니다. 병렬 계산에 대한 기사에는 "2 개의 지표"라는 핵심 문구로 찾을 수있는 흥미로운 표가 있습니다.

[Mykola Demko]

ds2:

인디케이터의 문제점은 각각이 자체 스레드에서 작동하며 작동하려면 필요한 모든 데이터를 스레드 자체에 저장해야 한다는 것입니다.

스레드 간의 데이터는 CopyBuffer()를 통해 복사됩니다. 하지만 여기에 문제가 있습니다. 스레드에서 데이터를 가져올 수는 있지만 전송할 수는 없습니다. 그렇기 때문에 하나의 지표의 여러 인스턴스가 동일한 사전 처리된 데이터를 수신하는 모고스테이지 지표를 만들 수 없습니다. 하지만 바로 이 지점에 계산 최적화를 위한 큰 기회가 있을 수 있습니다.

MQ가 이 문제를 해결하면 지표 작업이 더 편리하고 유연해질 것이라고 생각합니다. 이제 데이터는 스레드가 시작될 때만 외부 매개변수로만 전달할 수 있습니다.

[muller]

매우 유용합니다.

그래서 주요 아이디어 흐름을 올바르게 이해하면 질문이 생깁니다:

MT5 설치에서 발견되는 모든 표준 지표가 "클래스"로 설계되지 않은 이유는 무엇입니까?

그렇다면 마스터 마법사는 왜 그런 아이디어를 신경 쓰지 않습니까?

[Rashid Umarov]

인디케이터 작업에 대한 클래스를 참조하세요 .

[Dark Ryd3r]

도구> 옵션에서 최대 막대를 제한하지 않고 버퍼 공간을 줄이기 위해 제가 사용하는 빠른 방법은 다음과 같습니다.

int maxbars =100;// 마지막 막대
limit = rates_total-rates_total+maxbars;