사용자 지정 지표를 사용할 때 Expert Advisor의 속도를 높이는 이론(기능 - iCustom)

[Aleksey Vyazmikin]

저는 프로그래머가 아니라 틀릴 수 있다는 점부터 말씀드리겠지만, 아래 제안된 아이디어에 대한 계산을 바탕으로 전문가들의 의견을 듣고 싶습니다.

여러 단계에서 Expert Advisor를 개발할 때 사용자 지정 지표의 사용은 긴급한 작업입니다. 이것은 프로그래머가 서로를 교체할 때 특히 그렇습니다. 그런 다음 고문의 논리의 일부를 표시기에 꿰매는 것이 좋습니다. 논리를 실행(계산 및 관련성 확인)한 다음 아이디어의 새로운 부분에 대해 작업합니다. 결과적으로 지표에 실제로 정보를 요청하고 예상 데이터와 실제 데이터를 비교하여 결정을 내리는 그다지 복잡하지 않은 Expert Advisor를 얻습니다.

그러나 이 접근 방식에는 이러한 Expert Advisor의 속도라는 중요한 단점이 있습니다. 사실은 사용자 지정 지표에서 데이터를 더 자주 요청할수록 계산이 느려지고 최적화에 더 많은 리소스(메모리)가 필요합니다.

내가 MT4에서 작업하는 동안 원칙은 내가 이해하는 대로 이 문제에 대해 동일합니다.

그리고 문제는 iCustom 지표 자체의 계산 속도가 아니라 Expert Advisor와의 연결에 있습니다.

지표가 5개의 그래픽 버퍼를 사용하고 어드바이저가 이러한 버퍼의 정보를 필요로 한다고 가정해 보겠습니다. 그러면 어드바이저 코드는 5개의 iCustom 기능을 사용해야 하며 실제로 하나의 지표 대신 차트에 5개의 지표를 배치하여 5배 더 많은 리소스를 필요로 합니다. . 아마도 내가 틀렸고 컴파일러가 이 상황을 분석합니다 - 하나의 지표에 대해 계산을 하고 수요가 있는 버퍼에서 한 번에 모든 기능에 데이터를 제공합니다!? 그러면 더 이상 내 조작이 비어 있습니다.

그러나 이것이 사실이 아니라면 지표의 정보를 하나의 당밀로 결합하지 않는 이유는 무엇입니까?

Expert Advisor의 성능을 측정하여 이 주제에 대한 실험을 수행할 것을 제안합니다.

이렇게 하려면 버퍼가 1보다 큰 사용자 지정 표시기를 가져와서 추가 버퍼를 추가해야 합니다.

알고리즘은 논리적입니다(수학적 없음).

1. 버퍼 값을 표시기의 정수로 변환해 보겠습니다. 숫자당 자릿수에 따라 총 3개의 버퍼가 있습니다. 1.21101; 1.13; 5가 되었습니다: 121101;113;5

2. 우리는 첫 번째 숫자 뒤에 몇 자릿수를 맞춰야 하는지 고려합니다. 이 경우에는 4이고 다음 숫자는 다음 숫자입니다. 이 값은 승수의 거듭제곱입니다.

1.21101*10^4=1211010000

1.13*10^1=113

5*10^0=5(0 확인)

3. 숫자를 더하고 1211011135를 얻습니다.

4. 버퍼 4에 값 쓰기

5. Expert Advisor 4에서 표시기 버퍼를 요청하고 값을 역순으로 구성 요소로 분해합니다. 나중에 Expert Advisor에 사용할 수 있는 3자리를 얻습니다.

누군가이 접근 방식의 속도를 비교할 수 있습니까? 합리적인 결정이 있습니까?

[Denis Kirichenko]

...Допустим, индикатор использует 5 графических буферов и для работы советника требуется информация с этих буферов, тогда в коде советника необходимо использовать 5 функций iCustom, и фактически вместо одного индикатора наносить на график 5 индикаторов, что требует в 5 раз больше ресурсов. Быть может я не прав и компилятор анализирует это обстоятельство - делая расчет по одному индикатору и дает сразу всем функциям данные по востребованным буферам!? Тогда дальше мои измышления пусты...

컴파일러는 많은 것을 할 수 있고 할 수 있지만 이것은 아닙니다 :-)

...그러나 이 접근 방식에는 이러한 Expert Advisor의 속도라는 중요한 단점이 있습니다. 사실은 사용자 지정 표시기에서 데이터를 더 자주 요청할수록 계산이 느려지고 최적화에 더 많은 리소스(메모리)가 필요하다는 것입니다...

그리고 이것은 최적화될 수 있습니다. 첫째, 지표 자체는 지능적으로 작성되어야 하며(각 틱의 모든 막대를 다시 계산하지 않아야 함) 두 번째로, 조언자의 작업 속도를 어떻게든 늦추기 위해 지표는 매우 무거워야 합니다... 간단히 말해서...

그리고 여기 주제에 대한 흥미로운 기사가 있습니다. " 보조 표시기의 메모리 소비 줄이기."

나는 8tf에 대해 28개 상품에 대한 지표 판독값을 취하는 다중 통화 고문이 있었습니다.

그것은 28*8=224 표시기 사본입니다... 프로세스를 최적화하는 방법에 대해 고심했습니다. 다중 통화 작업은 거의 700MB의 RAM을 먹어치웠지만... 아주 쉽게 결정했습니다. "창의 최대 막대" 필드에 대한 "차트" 탭의 터미널 설정에서 작은 값을 설정했습니다... 내가 기억하는 한 이 필드의 최소값은 5,000바입니다...

[Dmitry Fedoseev]

나는 측정을 수행했는데 테스트 시간이 1.2~1.3배 증가했는데 이는 사용자 지정 지표가 제공하는 이점에 비해 완전히 미미한 수준입니다.

약 5 버퍼, 출력이 올바르지 않습니다. 매개변수가 동일한 경우 하나의 표시기만 로드됩니다.

[Denis Kirichenko]

Integer :

약 5 버퍼, 출력이 올바르지 않습니다. 매개변수가 동일한 경우 하나의 표시기만 로드됩니다.

그래, 난 동의.

다른 인수(버퍼 번호)를 사용 하여 CopyBuffer() 함수에 대한 5번의 호출이 있습니다. 그리고 표시기의 복사본은 핸들 하나만 있습니다.

저자는 주제를 "가속 이론 ..."이라고 큰 소리로 불렀지 만 기본적으로는 발이있는 치아가 아닙니다.

-알렉-, 지표 주제에 대한 기사가 많이 있습니다!

[Alexey Volchanskiy]

denkir :

그래, 난 동의.

다른 인수(버퍼 번호)를 사용 하여 CopyBuffer() 함수에 대한 5번의 호출이 있습니다. 그리고 표시기의 복사본은 핸들 하나만 있습니다.

저자는 주제를 "가속 이론 ..."이라고 크게 불렀지 만 기본적으로는 발이있는 치아가 아닙니다.

-알렉-, 지표 주제에 대한 기사가 많이 있습니다!

iCustom을 통해 내장 칠면조와 그 유사체를 호출하는 속도를 어떻게 든 측정하려고했습니다. 약 20-50% 더 빠른 내장. MQL이 아닌 C++로 작성되었기 때문일 가능성이 큽니다.

[Aleksey Vyazmikin]

denkir , 최적화 프로세스에서 고문의 작업에 대해 이야기하고 있습니다. 차트의 초 수가 계산량에 영향을 줍니까? 지표 자체의 최적화에 대한 기사를 연구했습니다. 옵션이 있다는 것을 알고 있습니다. 하지만 이 경우 지표가 이상적이라고 생각하고 지표에서 Expert Advisor로 데이터를 전송하는 방법을 모색하고 싶습니다. 프로그래머가 아닌 저로서는 표시기 코드의 최적성을 확인하기가 어렵습니다. 기술 사양에 작성할 수 있는 최대값은 1bar의 지연과 계산을 위한 이력 제한입니다.

Integer :

나는 측정을 수행했는데 테스트 시간이 1.2~1.3배 증가했는데 이는 사용자 지정 지표가 제공하는 이점에 비해 완전히 미미한 수준입니다.

약 5 버퍼, 출력이 올바르지 않습니다. 매개변수가 동일한 경우 하나의 표시기만 로드됩니다.

어떤 측정이 이루어졌습니까? 그리고 나에게 30%는 그리 적은 금액이 아니다.

약 5개의 버퍼, 내가 올바르게 이해했다면 표시기의 동일한 입력 매개변수를 사용하여 고문이 후자를 여러 번 호출하고 다른 버퍼에서 정보를 수신할 때 하나의 표시기만 계산됩니까?

그렇다면 사용자 지정 지표를 결합하면 고문의 작업 속도가 빨라질까요? 예를 들어, 하나의 표시기에서 독립적인 설정으로 다른 표시기의 논리를 넣을 수 있습니다. 그 중 하나를 호출할 때 모든 버퍼의 정보를 한 번에 수신하고 동일한 설정을 가진 다른 버퍼에서 정보를 요청할 경우 사용합니다. 매개변수?

Vdev :
iCustom을 통해 내장 칠면조와 그 유사체를 호출하는 속도를 어떻게 든 측정하려고했습니다. 약 20-50% 더 빠른 내장. MQL이 아닌 C++로 작성되었기 때문일 가능성이 큽니다.   

그것은 사실이다.

[Denis Kirichenko]

GODZILLA 의 매우 흥미로운 기사 " 중간 계산을 위한 추가 버퍼가 없는 평균 가격 시리즈 " 입니다.

2010년에 다시 작성했습니다.

섹션 3이 있습니다. 코드의 기술 및 사용자 정의 표시기에 대한 호출과 함께 클래스를 유사하게 사용하여 결과 표시기 비교

[Aleksey Vyazmikin]

denkir :

그래, 난 동의.

다른 인수(버퍼 번호)를 사용 하여 CopyBuffer() 함수에 대한 5번의 호출이 있습니다. 그리고 표시기의 복사본은 핸들 하나만 있습니다.

저자는 주제를 "가속 이론 ..."이라고 큰 소리로 불렀지 만 기본적으로는 발이있는 치아가 아닙니다.

-알렉-, 지표 주제에 대한 기사가 많이 있습니다!

아니면 숫자로 단어를 확인하면서 내 가설을 반박할 수 있습니까?

내 이론에 대한 주제 - 이름은 정상입니다 :)

[Denis Kirichenko]

-Aleks- :

denkir , 최적화 프로세스에서 고문의 작업에 대해 이야기하고 있습니다. 차트의 초 수가 계산량에 영향을 줍니까?

-Aleks- , 테스터 소개 개발자에게 물어봐야...

그러나 내가 보기에는 토론할 때 용어에 문제가 있습니다. 표시기와 함께 작동하려면 계산 속도를 낮추거나 RAM을 절약해야 합니까?

[Aleksey Vyazmikin]

denkir :

-Aleks- , 테스터 소개 개발자에게 물어봐야...

하지만 논의할 때 용어에 문제가 있는 것 같습니다. 표시기와 함께 작동하려면 계산 속도를 낮추거나 RAM을 절약해야 합니까?

내 방법이 이 두 가지 문제를 해결할 수 있을 것 같습니다. 내가 틀렸을 수도 있습니다.

최적화할 때 속도가 중요하지만 RAM을 채운 후 다시 내 관찰에 따르면 한 패스의 처리 속도가 감소합니다.

[Andrey Khatimlianskii]

-Aleks- :

누군가이 접근 방식의 속도를 비교할 수 있습니까? 합리적인 결정이 있습니까?

이 접근 방식은 표시기의 메모리 소비(전후 버퍼 수 차이의 대략 배수)를 줄이지만 프로세서의 부하를 증가시킵니다("어셈블리"와 "분해" 모두 지속적으로 수행되어야 함).

그리고 표시기가 5-버퍼인 경우 첫 번째 iCustom 호출은 모든 버퍼를 계산하고 다른 버퍼에 대한 후속 호출 및 요청은 미리 만들어진 정보(계산을 위한 새 데이터가 나타날 때까지)만 읽습니다.

매우 무거운 지표가 있는 경우, 첫 번째 실행에서 데이터가 계산 되어 파일에 기록 되고 후속 실행에서는 읽기만 가능하도록 고유한 캐시 시스템을 마련하십시오. 나는 이것을했고 훨씬 빨리 밝혀졌습니다.

그러나 95%의 경우 이 모든 것이 필요하지 않으며 테스터는 이미 충분히 빠르며 5-ke에서는 클라우드를 연결할 수도 있습니다.

행운을 빕니다!