MQL 컴파일러의 새 어셈블리에서 가상 메소드 체인의 최종 메소드이고 외부 라이브러리에 대한 링크가 없는 경우 가상 메소드를 직접 호출로 대체하는 최적화를 이미 활성화했습니다.
이 방법은 클래스와 함께 작동하는 많은 프로그램에 대한 가상 호출을 단순화하고 속도를 높입니다.
빌드 670의 첫 번째 게시물에서 test.mq4 예제 결과:
switch : 172
OOP: 312
32-64ms의 짧은 시간 측정으로 작동하지 않도록 주기를 10,000,000에서 50,000,000으로 늘려야 했습니다. 표시된 시간은 ms 단위이며 숫자가 낮을수록 코드가 더 빠릅니다.
다음은 동일한 코드의 새 컴파일러에서 발생한 일입니다.
switch : 157
OOP: 93
OOP는 강타로 이겼습니다. 하지만 왜?
먼저 가상 메서드를 일반 메서드로 전환한 다음 인라인 처리하여 0으로 최적화했습니다. 실제로 함수 호출과 본문이 완전히 사라지고 깨끗한 루프가 남습니다.
mov int [i] <- int [ 0 ]
$label:
<- тут когда-то было тело, но оно оптимизировалось в ноль
add int [i] <- int [i], int [ 1 ]
jlt int [i], int [ 50000000 ] --> $label
새 콘솔 컴파일러 베타를 포함하여 파일이 첨부됩니다. 메타 편집기(컴파일러가 내장되어 있음)와 콘솔 컴파일러의 일반 670 빌드를 사용하여 모든 예제를 비교할 수 있습니다.
이것은 무엇을 증명합니까?
테스트되는 것은 컴파일러 최적화 프로그램의 품질입니다.
테스트는 실제로 모든 것이 최적화된 방법에 대한 완전한 이해와 함께 작성되어야 합니다.
내가 말했듯이 나는 코드 최적화의 기능을 모른다면 어떻게 당신이 오도 될 수 있는지 (OOP가 갑자기 이겼습니다) 기존 예제에서 보여주었습니다.
설립하다! OOP 속도가 높을수록 모두 동일하게 수신이 가능했습니다. 예! 이점은 부인할 수 없습니다.
그럼 모두 어셈블러에 작성해 봅시다. 어느 쪽이든 더 빠를 것입니다.
나는 문제의 본질을 이해하지 못한다. 1MB의 코드가 포함된 Expert Advisor나 지표를 본 적이 없습니다.
어떤 함수를 호출하는 것에도 시간이 걸립니다. 기능을 없애자!
OOP를 사용하면 대규모 프로젝트를 훨씬 더 편리하게 제어할 수 있습니다.
또한 코드 실행 속도는 브로커에 대한 핑 시간과 주문에 대한 브로커의 응답만큼 중요하지 않은 경우가 많습니다.
HFT 알고리즘을 살펴보십시오. 최대 성능이 필요하지만 복잡한 계산을 찾을 수 없습니다.
추신. A 지점에서 B 지점으로 이동하려면 원칙적으로 슈퍼카나 경력 BELAZ가 필요하지 않습니다. 오토바이로 충분합니다!
설립하다! OOP 속도가 높을수록 모두 동일하게 수신이 가능했습니다. 예! 이점은 부인할 수 없습니다.
그래서 코드는 무엇이었습니까?
MQL 컴파일러의 새 어셈블리에서 가상 메소드 체인의 최종 메소드이고 외부 라이브러리에 대한 링크가 없는 경우 가상 메소드를 직접 호출로 대체하는 최적화를 이미 활성화했습니다.
이 방법은 클래스와 함께 작동하는 많은 프로그램에 대한 가상 호출을 단순화하고 속도를 높입니다.
빌드 670의 첫 번째 게시물에서 test.mq4 예제 결과:
32-64ms의 짧은 시간 측정으로 작동하지 않도록 주기를 10,000,000에서 50,000,000으로 늘려야 했습니다. 표시된 시간은 ms 단위이며 숫자가 낮을수록 코드가 더 빠릅니다.
다음은 동일한 코드의 새 컴파일러에서 발생한 일입니다.
OOP는 강타로 이겼습니다. 하지만 왜?
먼저 가상 메서드를 일반 메서드로 전환한 다음 인라인 처리하여 0으로 최적화했습니다. 실제로 함수 호출과 본문이 완전히 사라지고 깨끗한 루프가 남습니다.
새 콘솔 컴파일러 베타를 포함하여 파일이 첨부됩니다. 메타 편집기(컴파일러가 내장되어 있음)와 콘솔 컴파일러의 일반 670 빌드를 사용하여 모든 예제를 비교할 수 있습니다.
이것은 무엇을 증명합니까?