이 MQ-wall은 포럼 회원들의 도움 없이는 무너질 수 없다고 생각합니다. 코드가 짧습니다. 전문가는 빨리 움직여야 합니다. 거기에는 결함이 없습니다. 포지션을 통한 가격은 Market Watch보다 훨씬 빠르게 획득된다는 것이 분명합니다. MQ가 명백한 것을 보지 못하는 방법 - 나는 이해하지 못한다.
1. 테스트는 조건으로 인한 반복 백분율의 미시적인 부분을 실제로 고려합니다.
if (Interval ##A > 100 )
사실, 프로세서가 작업으로 과부하되어 이 작업의 실행을 원거리 선반으로 연기한 경우에만 이상 현상만 계산합니다. 99% 이상의 반복이 1마이크로초 이내에 수행됩니다.
그리고 조건>0으로 설정해도 여전히 객관성은 없습니다.
2. 이러한 빠른 작업의 시간 측정은 한 번의 반복이 아니라 전체 주기의 시간으로 수행되어야 합니다.
3. 그러나 귀하의 예제에서 주기가 10초로 제한되어 있기 때문에(왜! 틱의 경우 0.1초면 충분하다고 생각합니다. 결국 1초에 3개의 틱이 와서 3개의 틱이 모두 처리될 가능성이 있습니다. 10초 동안 병렬로), 그 다음에는 타이밍이 필요하지 않습니다. 그리고 주어진 시간에 얼마나 많은 반복이 수행될 것인지 계산하기가 더 쉽습니다. 많을수록 성능이 향상됩니다.
귀하의 코드를 "약간" 수정했습니다. 제 버전이 현실을 더 반영하는 것 같아요.
두 옵션을 혼합하지 않도록 계산이 차례로 이루어집니다. SYMBOL_BID 에 대한 짝수 틱, GetBid()에 대한 홀수 틱.
합과 그 파생은 최적화에 대해 컴파일러를 속이기 위한 시도로 만일을 대비하여 추가되었습니다. 출력은 누적됩니다.
fxsaber의 원본 버전은 GetBid의 장점을 보여줍니까, 아니면 더 강력하거나 덜 로드된 PC인가요?
그의 버전은 또한 전체 CPU 로드에서 GetBid의 이점을 보여주었습니다. 그러나 동시에 내 버전은 동일한 부하로 표준 기능의 3배 이점을 보여줍니다. 이것은 내 버전이 입찰 가격을 얻는 모든 반복의 평균 시간을 고려하기 때문에 발생하며 비정상적인 중단이 있는 아주 작은 부분에 불과합니다. 그에게 어려운 "분"에 프로세서가 표준 기능(지연이 100μ 이상인 경우)에 정확하게 점수를 매기는 이유를 누가 압니까? 그러나 여전히 일반 기능의 경우 평균 시간이 3배 적습니다.
예를 들어 if (Interval##A > 100) 다음 그림이 있습니다.
반면 (Interval##A > 0) 이미 완전히 다르면 입찰 가격을 얻기 위한 표준 옵션과 대체 옵션 사이의 비정상적인 지연의 무작위 분포를 보여줍니다.
계산에 포함된 반복의 백분율을 시각적으로 보여주기 위해 fxsaber 테스트를 약간 수정한 후:
저것들. 약 0.01%
여전히 것입니다. SymbolInfoDouble(_Symbol, SYMBOL_BID )의 평균 실행 시간이 약 50나노초인 경우 실행 시간이 100,000나노초 이상인 경우에만 계산됩니다.
조건을 100μs 이하, 3μs 이상으로 간단히 만들 수 있습니다. 결과는 분명히 같았습니다. 아이디어는 세그먼트 연구와 다른 실행 조건에서 다른 세그먼트와 다른 영역에서 그 반대의 차이가 있을 수 있다는 것입니다. 실행 우선 순위는 종종 무언가에 따라 수행됩니다. 부하가 적으면 우선 순위가 높고 부하가 많으면 우선 순위가 높고 컴퓨터가 멈추거나 충돌하는 것을 허용하지 않는 중요한 우선 순위가 있으며 성능이 백그라운드로 사라집니다.
일반적으로 철의 70% 이상을 적재할 때의 거래는 옳지 않습니다. 거의 크리티컬한 처형입니다. 전투 고문의 철 장전은 60%를 넘지 않아야 합니다.
시장 감시에 하나의 기호가 있고 수십 개의 기호가 있을 때 SymbolInfoTick을 테스트해 보십시오. 그러나 귀하의 예에서와 같이 하나의 도구를 요청하십시오.
압축된 트래픽이 서버에서 올 가능성이 높고 데이터 압축을 풀 때 이러한 주기적 SymbolInfoTick 브레이크가 나타납니다.
저것들. 많은 문자가 있는 경우 테스트 시간이 훨씬 더 자주 또는 딥딥됩니다.
최근 빌드에서 틱 스트림을 수신하는 것은 이론적으로조차 효과가 없습니다. 실제로 SymbolInfoTick은 이미 캐시와 함께 작동 하지만 개별 시민은 계속해서 검은 고양이를 찾습니다.
80% CPU 로드에서 테스트할 요점이 없습니다.
그리고 그는 시험에서 80%도 얻지 못했습니다. 4개의 코어에 6개의 에이전트가 있습니다. 100% 보장됩니다.
유일한 질문은 그의 시스템의 작업 스케줄러가 이러한 상황에 대처하는 방법입니다. 동시에 책임은 터미널의 구현이라는 진술이 만들어집니다.
저것들. 컴퓨터가 측정할 수 없을 정도로 로드되고 말 그대로 모든 것이 느려질 때 상황이 인위적으로 만들어지고 "오, 봐요, 터미널이 때때로 거기에 지연이 있는 이유는 무엇입니까?"라는 스타일로 진술됩니다.
그런 조건에서도 "약 0.01%"라는 사실에 눈을 감자. 디테일은 지옥에! "병원의 평균 온도는 아무도 괴롭히지 않는다", "지연은 거래 중에 문제를 일으킨다", "우리는 HFT를 원한다"라고 말하면 충분하다.
게다가 우리는 HFT 가 오래된 사무실 데스크탑이나 죽은 가상 머신에 대한 20명의 전문가가 되기를 원합니다.
PS PositionSelectByTicket() 구현 시 액세스 동기화를 통해 공유 리소스에 무조건 액세스할 수 있습니다. 그리고 각 통화에서 위치를 선택하지 않으면 이전 가격을 읽는 것입니다. SymbolInfoDouble을 통해 "스냅샷"을 만드는 것이 더 쉬웠습니다.
Конечной целью трейдера является извлечение прибыли посредством торговых операций на финансовых рынках. В этой статье дается описание терминов и процессов торговой платформы MetaTarder 5, знание которых необходимо для правильного понимания работы торговых функций языка MQL5. Ордера — это принятые торговым сервером запросы на совершение торговых...
이 MQ-wall은 포럼 회원들의 도움 없이는 무너질 수 없다고 생각합니다. 코드가 짧습니다. 전문가는 빨리 움직여야 합니다. 거기에는 결함이 없습니다. 포지션을 통한 가격은 Market Watch보다 훨씬 빠르게 획득된다는 것이 분명합니다. MQ가 명백한 것을 보지 못하는 방법 - 나는 이해하지 못한다.
1. 테스트는 조건으로 인한 반복 백분율의 미시적인 부분을 실제로 고려합니다.
사실, 프로세서가 작업으로 과부하되어 이 작업의 실행을 원거리 선반으로 연기한 경우에만 이상 현상만 계산합니다. 99% 이상의 반복이 1마이크로초 이내에 수행됩니다.
그리고 조건>0으로 설정해도 여전히 객관성은 없습니다.
2. 이러한 빠른 작업의 시간 측정은 한 번의 반복이 아니라 전체 주기의 시간으로 수행되어야 합니다.
3. 그러나 귀하의 예제에서 주기가 10초로 제한되어 있기 때문에(왜! 틱의 경우 0.1초면 충분하다고 생각합니다. 결국 1초에 3개의 틱이 와서 3개의 틱이 모두 처리될 가능성이 있습니다. 10초 동안 병렬로), 그 다음에는 타이밍이 필요하지 않습니다. 그리고 주어진 시간에 얼마나 많은 반복이 수행될 것인지 계산하기가 더 쉽습니다. 많을수록 성능이 향상됩니다.
귀하의 코드를 "약간" 수정했습니다. 제 버전이 현실을 더 반영하는 것 같아요.
두 옵션을 혼합하지 않도록 계산이 차례로 이루어집니다. SYMBOL_BID 에 대한 짝수 틱, GetBid()에 대한 홀수 틱.
합과 그 파생은 최적화에 대해 컴파일러를 속이기 위한 시도로 만일을 대비하여 추가되었습니다.
출력은 누적됩니다.
내 결과:
보시다시피 성능 차이는 표준 버전에 비해 3배입니다.
보시다시피 성능 차이는 표준 버전에 비해 3배입니다.fxsaber의 원본 버전은 GetBid의 장점을 보여줍니까, 아니면 더 강력하거나 덜 로드된 PC인가요?
fxsaber의 원본 버전은 GetBid의 장점을 보여줍니까, 아니면 더 강력하거나 덜 로드된 PC인가요?
그의 버전은 또한 전체 CPU 로드에서 GetBid의 이점을 보여주었습니다. 그러나 동시에 내 버전은 동일한 부하로 표준 기능의 3배 이점을 보여줍니다.
이것은 내 버전이 입찰 가격을 얻는 모든 반복의 평균 시간을 고려하기 때문에 발생하며 비정상적인 중단이 있는 아주 작은 부분에 불과합니다.
그에게 어려운 "분"에 프로세서가 표준 기능(지연이 100μ 이상인 경우)에 정확하게 점수를 매기는 이유를 누가 압니까? 그러나 여전히 일반 기능의 경우 평균 시간이 3배 적습니다.
예를 들어 if (Interval##A > 100) 다음 그림이 있습니다.
반면 (Interval##A > 0) 이미 완전히 다르면 입찰 가격을 얻기 위한 표준 옵션과 대체 옵션 사이의 비정상적인 지연의 무작위 분포를 보여줍니다.
동일한 CPU 부하에서의 내 테스트는 다음을 보여줍니다.
따라서 fxsaber 테스트 버전은 객관적이지 않다고 생각합니다.
프로세서는 에이전트가 아니라 이 스크립트로 로드되었습니다. 그것은 더 효율적으로 작동했습니다.
계산에 포함된 반복의 백분율을 시각적으로 보여주기 위해 fxsaber 테스트를 약간 수정한 후:
저것들. 약 0.01%
여전히 것입니다.
SymbolInfoDouble(_Symbol, SYMBOL_BID )의 평균 실행 시간이 약 50나노초인 경우 실행 시간이 100,000나노초 이상인 경우에만 계산됩니다.
계산에 포함된 반복의 백분율을 시각적으로 보여주기 위해 fxsaber 테스트를 약간 수정한 후:
저것들. 약 0.01%
여전히 것입니다.
SymbolInfoDouble(_Symbol, SYMBOL_BID )의 평균 실행 시간이 약 50나노초인 경우 실행 시간이 100,000나노초 이상인 경우에만 계산됩니다.
조건을 100μs 이하, 3μs 이상으로 간단히 만들 수 있습니다. 결과는 분명히 같았습니다. 아이디어는 세그먼트 연구와 다른 실행 조건에서 다른 세그먼트와 다른 영역에서 그 반대의 차이가 있을 수 있다는 것입니다. 실행 우선 순위는 종종 무언가에 따라 수행됩니다. 부하가 적으면 우선 순위가 높고 부하가 많으면 우선 순위가 높고 컴퓨터가 멈추거나 충돌하는 것을 허용하지 않는 중요한 우선 순위가 있으며 성능이 백그라운드로 사라집니다.
일반적으로 철의 70% 이상을 적재할 때의 거래는 옳지 않습니다. 거의 크리티컬한 처형입니다. 전투 고문의 철 장전은 60%를 넘지 않아야 합니다.
이미 HFT 중개인이 있습니까?)
시장 감시에 하나의 기호가 있고 수십 개의 기호가 있을 때 SymbolInfoTick을 테스트해 보십시오. 그러나 귀하의 예에서와 같이 하나의 도구를 요청하십시오.
압축된 트래픽이 서버에서 올 가능성이 높고 데이터 압축을 풀 때 이러한 주기적 SymbolInfoTick 브레이크가 나타납니다.
저것들. 많은 문자가 있는 경우 테스트 시간이 훨씬 더 자주 또는 딥딥됩니다.
최근 빌드에서 틱 스트림을 수신하는 것은 이론적으로조차 효과가 없습니다. 실제로 SymbolInfoTick은 이미 캐시와 함께 작동 하지만 개별 시민은 계속해서 검은 고양이를 찾습니다.
그리고 그는 시험에서 80%도 얻지 못했습니다. 4개의 코어에 6개의 에이전트가 있습니다. 100% 보장됩니다.
유일한 질문은 그의 시스템의 작업 스케줄러가 이러한 상황에 대처하는 방법입니다. 동시에 책임은 터미널의 구현이라는 진술이 만들어집니다.
저것들. 컴퓨터가 측정할 수 없을 정도로 로드되고 말 그대로 모든 것이 느려질 때 상황이 인위적으로 만들어지고 "오, 봐요, 터미널이 때때로 거기에 지연이 있는 이유는 무엇입니까?"라는 스타일로 진술됩니다.
그런 조건에서도 "약 0.01%"라는 사실에 눈을 감자. 디테일은 지옥에! "병원의 평균 온도는 아무도 괴롭히지 않는다", "지연은 거래 중에 문제를 일으킨다", "우리는 HFT를 원한다"라고 말하면 충분하다.
게다가 우리는 HFT 가 오래된 사무실 데스크탑이나 죽은 가상 머신에 대한 20명의 전문가가 되기를 원합니다.
PS PositionSelectByTicket() 구현 시 액세스 동기화를 통해 공유 리소스에 무조건 액세스할 수 있습니다. 그리고 각 통화에서 위치를 선택하지 않으면 이전 가격을 읽는 것입니다. SymbolInfoDouble을 통해 "스냅샷"을 만드는 것이 더 쉬웠습니다.