분명히 터미널 베이스는 액세스 동기화가 있는 공유 리소스입니다. 그리고 의도적으로 수만 건의 주문과 거래를 생성했습니다.
나는 10K 이상의 주문이 있는 실제 계정에서 테스트합니다. 이것은 가짜 주문이 아닙니다. 왜냐하면 > 70%가 처형되었습니다.
그런데 화면에서는 9331+576 != 12529입니다.
이 모든 무의미한 행동은 동시에 여러 스레드에서 각 틱 에 10 번 반복됩니다. 게다가, 당신은 의식적으로 여러 흐름에서 이러한 행동의 동시성을 달성합니다.
다른 캐릭터에 문제가 있습니다. 문제를 더 빨리 재현하려면 한 문자를 사용하는 것이 좋습니다.
매 틱마다 10번씩 반복하는 것은 매우 중요합니다. 왜냐하면 한 조언자가 다른 마법을 가진 12개의 TS를 포함하는 것은 정상입니다.
그래서 무엇을, 왜 하는지, 자원이 어디로 가는지 완벽하게 알고 있으며 동시에 "MT5의 과도한 CPU 부하로 인한 지연"이라고 주장합니다.
즉, 분명히 컴퓨터에 문제가 있습니다. 즉, 상당한 양의 메모리를 매우 적극적으로 이동하고 있지만 이는 함수, 특히 HistorySelect()와 관련이 없는 함수의 실행 시간에 영향을 미치지 않아야 합니다.
언어는 당신을 무능하다고 비난하는 것으로 바뀌지 않지만 당신이 쓴 것은 온화하게 말하면 당혹스럽습니다. HistorySelect는 4개의 인덱스(주문 테이블의 시작/종료 및 거래 테이블의 시작/종료)를 찾고 있습니다. 동시에 테이블은 시간별로 정렬되므로 최악의 경우 이진 검색이 있어야 합니다. 10K 주문의 경우 즉각적입니다(이진 로그 계산). 기억의 볼륨의 움직임?! 아무도 여기서 끔찍한 HistorySelectByPosition에 대해 이야기하지 않습니다. 기본 HistorySelect가 영향을 받습니다.
b2582 테스트에서 틱당 1000번의 빈도와 하나의 기호 차트에 5개의 EA가 있는 경우에도, 즉 기본 조건보다 10배 이상 큰 경우 경고가 하나도 관찰되지 않습니다.
테스트 시스템: Windows 10 빌드 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
ZY 같은 스크립트를 다른 거래 플랫폼과 비교하는 것도 재미있을 것입니다.
MT4 b1280.
3개만 뛰고 나서 아주 드물게 뛰쳐나왔다. HistorySelect 및 CopyTicks가 없기 때문에 브레이크를 생성하기 어려울 수 있습니다.
둘 다 Haswell이기 때문에 제온은 훨씬 더 낮은 작동 주파수를 가지며 작동 및 단일 테스트에서 성능이 저하되고 다중 스레드 최적화에서만 이득이 있습니다. 최신 모델의 i3는 작업 속도가 훨씬 빨라야 합니다.
캐시 레벨이 작업 속도에 미치는 영향, 그리고 실제로 Zen2 및 최신 인텔의 속도에 대한 개발자의 영향을 알아보기 위해
추가하다
Ryzen 3700x가 있습니다. Intel에서 테스트할 수 있습니다.
예를 들어 이 일반 스크립트 MQL5\Scripts\UnitTests\Stat\TestStatBenchmark.mq5 사용
타이머로 여러 번 반복
여기서 우리는 테스트에 대해 이야기하는 것이 아니라 거래 주문 실행 지연에 대해 이야기합니다. 이 지연은 유동적입니다. 그리고 그것은 TC와 저 모두에게 매우 혼란스럽습니다.
3개만 뛰고 나서 아주 드물게 뛰쳐나왔다. HistorySelect 및 CopyTicks가 없기 때문에 브레이크를 생성하기 어려울 수 있습니다.
MT4도 기다렸습니다.
TimeLocal은 36밀리초입니다. 틱 볼륨 이 더 큰 기호를 선택했습니다.
관심 있는 분들을 위해 플레이 방법을 알려드립니다.
그가 만지지 않을 것이라고 생각하는 사람.
틱 볼륨 이 더 큰 기호를 선택했습니다.
확인도 하지 않겠습니다. 유리 사인이 있는 가장 인기 있는 FORTS 기호를 상상해 보십시오. OnBookEvent의 OnTick 논리 대신. 지연은 끔찍해야합니다.
지연을 최소화하기 위해 수행해야 할 작업에 대한 공식적인 권장 사항이 필요합니다.
브레이크를 재현하려면 OnTick에 대한 동시 호출을 달성하기 위해 하나의 기호로 된 여러 차트에서 스크립트를 실행해야 합니다. 그런 다음 모든 틱에 경고가 쏟아집니다.
CPU 로드 그래프는 terminal64.exe가 8개의 논리 코어 중 최대 30%를 로드함을 보여줍니다. 이것은 실행 중인 스크립트가 있는 4개의 EURUSD 차트입니다. 각 차트가 동시에 로드되는 방식을 명확하게 볼 수 있습니다.
그 많은 자원은 어디로 가는가?
이 질문은 대답하기 쉽습니다.
여기에서 많은 데이터를 복사합니다.
실제로, 터미널 데이터베이스에서 추가 사용을 위해 Expert Advisor의 환경으로 사용 가능한 모든 거래 내역을 가져오라는 명령을 내립니다. 특히 동일한 요청을 캐싱하기 위한 가능한 알고리즘을 무작위로 시도합니다.
그러나 이 데이터를 모두 사용하지 않고 다음 줄에서 즉시 재설정합니다.
분명히 터미널 베이스는 액세스 동기화가 있는 공유 리소스입니다. 그리고 의도적으로 수만 건의 주문과 거래를 생성했습니다.
이 모든 무의미한 행동은 동시에 여러 스레드에서 각 틱 에 10 번 반복됩니다. 게다가, 당신은 의식적으로 여러 흐름에서 이러한 행동의 동시성을 달성합니다.
그래서 무엇을, 왜 하는지, 자원이 어디로 가는지 완벽하게 알고 있으며 동시에 "MT5의 과도한 CPU 부하로 인한 지연"이라고 주장합니다.
즉, 분명히 컴퓨터에 문제가 있습니다. 즉, 상당한 양의 메모리를 매우 적극적으로 이동하고 있지만 이는 특히 HistorySelect()와 관련이 없는 함수의 실행 시간에 영향을 미치지 않아야 합니다.
b2582 테스트에서 틱당 1000번의 빈도와 하나의 기호 차트에 5개의 EA가 있는 경우에도, 즉 기본 조건보다 10배 이상 큰 경우 경고가 하나도 관찰되지 않습니다.
테스트 시스템: Windows 10 빌드 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
이 질문은 대답하기 쉽습니다.
여기에서 많은 데이터를 복사합니다.
실제로, 터미널 데이터베이스에서 추가 사용을 위해 Expert Advisor의 환경으로 사용 가능한 모든 거래 내역을 가져오라는 명령을 내립니다. 특히 동일한 요청을 캐싱하기 위한 가능한 알고리즘을 무작위로 시도합니다.
그러나 이 데이터를 모두 사용하지 않고 다음 줄에서 즉시 재설정합니다.
분명히 터미널 베이스는 액세스 동기화가 있는 공유 리소스입니다. 그리고 의도적으로 수만 건의 주문과 거래를 생성했습니다.
이 모든 무의미한 행동은 동시에 여러 스레드에서 각 틱 에 10 번 반복됩니다. 게다가, 당신은 의식적으로 여러 흐름에서 이러한 행동의 동시성을 달성합니다.
그래서 무엇을, 왜 하는지, 자원이 어디로 가는지 완벽하게 알고 있으며 동시에 "MT5의 과도한 CPU 부하로 인한 지연"이라고 주장합니다.
즉, 분명히 컴퓨터에 문제가 있습니다. 즉, 상당한 양의 메모리를 매우 적극적으로 이동하고 있지만 이는 특히 HistorySelect()와 관련이 없는 함수의 실행 시간에 영향을 미치지 않아야 합니다.
b2582 테스트에서 틱당 1000번의 빈도와 하나의 기호 차트에 5개의 EA가 있는 경우에도, 즉 기본 조건보다 10배 이상 큰 경우 경고가 하나도 관찰되지 않습니다.
테스트 시스템: Windows 10 빌드 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
동료,
이제 항공기 모델링 서클의 수준을 떠날 때입니다.
다음은 전투 조건입니다. 4개의 터미널, 약 300명의 고문, 약 30개의 도구. 고문의 3분의 1이 주문서에 가입되어 있습니다. 이 모든 것이 FORTS에 있습니다. 이러한 조건에서 모델링하십시오.
동료,
이제 항공기 모델링 서클의 수준을 떠날 때입니다.
다음은 전투 조건입니다. 4개의 터미널, 약 300명의 고문, 약 30개의 도구. 고문의 3분의 1이 주문서에 가입되어 있습니다. 이 모든 것이 FORTS에 있습니다. 이러한 조건에서 모델링하십시오.
"여기 있습니다"는 문제에 대한 자세한 설명과 함께 zip 파일로 수신됩니다. 그렇지 않으면 공허한 이야기입니다.
이 경우 제시된 Expert Advisor의 코드와 구현의 효율성에 대해 논의합니다. 확인된 문제에 따라 터미널 코드를 최적화하는 작업이 수행되었습니다.
"여기 있습니다"는 문제에 대한 자세한 설명과 함께 zip 파일로 수신됩니다. 그렇지 않으면 공허한 이야기입니다.
이 경우 제시된 Expert Advisor의 코드와 구현의 효율성에 대해 논의합니다. 확인된 문제에 따라 터미널 코드를 최적화하는 작업이 수행되었습니다.
나는 문제가 없습니다. 보낼 것이 없습니다.
fxsaber는 문제가 있습니다. 그는 이미 여기에서 16페이지를 굴렸습니다.
그리고 Mikhail 은 2014년부터 같은 문제를 겪고 있습니다. 그는 이미 149페이지를 넘겼습니다: https://www.mql5.com/en/forum/38456/page149
둘 다 필요한 모든 정보를 제공하기에 충분한 자격을 갖추고 있습니다.
이 질문은 대답하기 쉽습니다.
여기에서 많은 데이터를 복사합니다.
실제로, 터미널 데이터베이스에서 추가 사용을 위해 Expert Advisor의 환경으로 사용 가능한 모든 거래 내역을 가져오라는 명령을 내립니다. 특히 동일한 요청을 캐싱하기 위한 가능한 알고리즘을 무작위로 시도합니다.
당신은 이 분기의 발전 연대기를 따르지 않았기 때문에 당신의 진술에 비난의 글을 남길 수 있습니다.
MathRand에서 라인을 제거했습니다. 다음은 짧은 로그입니다.
그러나 이 데이터를 모두 사용하지 않고 다음 줄에서 즉시 재설정합니다.
분명히 터미널 베이스는 액세스 동기화가 있는 공유 리소스입니다. 그리고 의도적으로 수만 건의 주문과 거래를 생성했습니다.
나는 10K 이상의 주문이 있는 실제 계정에서 테스트합니다. 이것은 가짜 주문이 아닙니다. 왜냐하면 > 70%가 처형되었습니다.
그런데 화면에서는 9331+576 != 12529입니다.
이 모든 무의미한 행동은 동시에 여러 스레드에서 각 틱 에 10 번 반복됩니다. 게다가, 당신은 의식적으로 여러 흐름에서 이러한 행동의 동시성을 달성합니다.
다른 캐릭터에 문제가 있습니다. 문제를 더 빨리 재현하려면 한 문자를 사용하는 것이 좋습니다.
매 틱마다 10번씩 반복하는 것은 매우 중요합니다. 왜냐하면 한 조언자가 다른 마법을 가진 12개의 TS를 포함하는 것은 정상입니다.
그래서 무엇을, 왜 하는지, 자원이 어디로 가는지 완벽하게 알고 있으며 동시에 "MT5의 과도한 CPU 부하로 인한 지연"이라고 주장합니다.
즉, 분명히 컴퓨터에 문제가 있습니다. 즉, 상당한 양의 메모리를 매우 적극적으로 이동하고 있지만 이는 함수, 특히 HistorySelect()와 관련이 없는 함수의 실행 시간에 영향을 미치지 않아야 합니다.
언어는 당신을 무능하다고 비난하는 것으로 바뀌지 않지만 당신이 쓴 것은 온화하게 말하면 당혹스럽습니다. HistorySelect는 4개의 인덱스(주문 테이블의 시작/종료 및 거래 테이블의 시작/종료)를 찾고 있습니다. 동시에 테이블은 시간별로 정렬되므로 최악의 경우 이진 검색이 있어야 합니다. 10K 주문의 경우 즉각적입니다(이진 로그 계산). 기억의 볼륨의 움직임?! 아무도 여기서 끔찍한 HistorySelectByPosition에 대해 이야기하지 않습니다. 기본 HistorySelect가 영향을 받습니다.
b2582 테스트에서 틱당 1000번의 빈도와 하나의 기호 차트에 5개의 EA가 있는 경우에도, 즉 기본 조건보다 10배 이상 큰 경우 경고가 하나도 관찰되지 않습니다.
테스트 시스템: Windows 10 빌드 18363, Intel Xeon E5-2630 v4 @ 2.20GHz
테스트가 수행된 거래 계정에 대한 로그인 세부 정보를 여기에 제공하십시오.