가장 중요한 것은 Expert Advisor가 진화했을 때 작업 속도가 어떻게 퇴보했는지 보여 주었다는 것입니다. 진드기로 작동하는 전문가 고문 - 진드기가 생성되고 기록과 아무 관련이 없기 때문에 전혀 의심스럽습니다.
지표의 계산된 데이터를 미리 준비하고 파일로 저장함으로써 역사에 대한 고문의 작업 속도를 크게 높일 수 있습니까?
디스크에서 읽는 속도가 최적화된 지표를 계산하는 속도를 잃을 가능성이 있습니다. 원격 에이전트에 대한 계산은 어떻습니까? 계산된 지표를 보내시겠습니까? 특정한 경우 실행 속도를 최적화하기 위한 많은 옵션이 있습니다. 추가 주기는 피해야 합니다. + 각 틱에서 모든 작업을 수행하는 것이 그렇게 중요한지 생각하려면 " 새 막대 이벤트"로 제한하기에 충분할 것입니다.
디스크에서 읽는 속도가 최적화된 지표를 계산하는 속도를 잃을 가능성이 있습니다. 원격 에이전트에 대한 계산은 어떻습니까? 계산된 지표를 보내시겠습니까? 특정한 경우 실행 속도를 최적화하기 위한 많은 옵션이 있습니다. 추가 주기는 피해야 합니다. + 각 틱에서 모든 작업을 수행하는 것이 그렇게 중요한지 생각하려면 " 새 막대 이벤트"로 제한하기에 충분할 것입니다.
데이터를 한 번 읽고 배열을 만든 다음에만 액세스할 수 없나요?
내 특정 Expert Advisor에 관해서는 시작 가격에서 최적화를 수행했음을 상기시킵니다. 틱이 없어 보입니다. 생각해보면 결국 나는 내 자신의 코드를 최적화하기 위해 실행자에게 비용을 지불하지만 어드바이저의 작업에서 발생한 이벤트에 대한 코드를 확인하지 않고 옵티마이저에서 작업 속도의 상당한 증가를 약속합니다. 이것이 되길 바랍니다.
좋은 조언 감사합니다!
여기서 질문을 드리겠습니다. 바 오픈 시점에 20명의 어드바이저가 동시에 작업하면 데이터 계산 중에 가격이 많이 변경되기 때문에 이것이 피크 제동 및 오픈 오더로 이어지지 않습니까?
테스트할 때 실행 기록이 발생합니다. 거래 에뮬레이션. 각 다음 카운트(어드바이저 호출)에서 이미 도착했을 데이터만 수신할 때. 파일의 경우 향후 호출에서 파일을 기다리는 미래를 포함하여 표시기의 모든 기록을 마음대로 사용할 수 있습니다. 저것들. 파일을 읽거나 어레이의 주소를 올바르게 지정해야 합니다. 그건 그렇고, 배열은 메모리에서 많은 공간을 차지합니다. 이것은 최적화할 때 이동해야 하는 방향이 아닙니다. 적어도 이 경우에는 그렇지 않습니다.
-알렉스 - :
여기서 질문을 드리겠습니다. 바 오픈 시점에 20명의 어드바이저가 동시에 작업하면 데이터 계산 중에 가격이 많이 변경되기 때문에 이것이 피크 제동 및 오픈 오더로 이어지지 않습니까?
20명의 Expert Advisors가 모두 동일한 기기에 있는 경우 그렇습니다. 그들은 거의 동시에 컴퓨팅을 시작할 것입니다. 그러나 다음 사항을 고려해야 합니다.
- 각각은 별도의 스레드에서 실행됩니다. 4코어 컴퓨터 구성을 사용하면 간섭이 거의 또는 전혀 없이 4개가 동시에 실행될 수 있습니다.
- 단일 계산 시간은 거래 요청 을 보내는 시간과 비교할 수 없을 정도로 짧을 수 있습니다. 이러한 이유로 현재 가격으로 거래 주문을 비동기식으로 보내는 것이 좋습니다(여러 개를 한 번에 생성할 수 있는 경우). 이렇게 하면 두 번째 주문을 보내기 전에 첫 번째 주문 결과를 기다리지 않아도 됩니다. 하지만 여기에도 다른 옵션이 있을 수 있습니다... 모두 거래 전략에 따라 다릅니다.
Expert Advisors가 다른 기기에서 작업하는 경우 눈금과 새 막대가 동시에 발생하지 않는 경우가 가장 많습니다.
테스트할 때 실행 기록이 발생합니다. 거래 에뮬레이션. 각 다음 카운트(어드바이저 호출)에서 이미 도착했을 데이터만 수신할 때. 파일의 경우 향후 호출에서 파일을 기다리는 미래를 포함하여 표시기의 모든 기록을 마음대로 사용할 수 있습니다. 저것들. 파일을 읽거나 어레이의 주소를 올바르게 지정해야 합니다. 그건 그렇고, 배열은 메모리에서 많은 공간을 차지합니다. 이것은 최적화할 때 이동해야 하는 방향이 아닙니다. 적어도 이 경우에는 그렇지 않습니다.
20명의 Expert Advisors가 모두 동일한 기기에 있는 경우 그렇습니다. 그들은 거의 동시에 컴퓨팅을 시작할 것입니다. 그러나 다음 사항을 고려해야 합니다.
- 각각은 별도의 스레드에서 실행됩니다. 4코어 컴퓨터 구성을 사용하면 간섭이 거의 또는 전혀 없이 4개가 동시에 실행될 수 있습니다.
- 단일 계산 시간은 거래 요청 을 보내는 시간과 비교할 수 없을 정도로 짧을 수 있습니다. 이러한 이유로 현재 가격으로 거래 주문을 비동기식으로 보내는 것이 좋습니다(여러 개를 한 번에 생성할 수 있는 경우). 이렇게 하면 두 번째 주문을 보내기 전에 첫 번째 주문 결과를 기다리지 않아도 됩니다. 하지만 여기에도 다른 옵션이 있을 수 있습니다... 모두 거래 전략에 따라 다릅니다.
Expert Advisors가 다른 기기에서 작업하는 경우 눈금과 새 막대가 동시에 발생하지 않는 경우가 가장 많습니다.
오픈 주문에 주문을 보낼 때 인위적인 지연이 필요하다는 것을 올바르게 이해했지만 동시에 오픈 확인을 기다리지 않습니까?
micle : никаких искусственных задержек делать не нужно. Это за вас сделает интернет и брокер...
수동 거래 중에 발생하는 다음 상황에 대해 이야기하고 있습니다. 주문을 열고 처리될 때까지 기다리라는 요청을 보냈습니다. 잠시 기다렸다가 다른 주문을 보내려고 하면 "채널이 바쁜" 결과적으로 가격 변동으로 인해 첫 번째 주문이 열리지 않고 두 번째 터미널에서 전송을 허용하지 않았습니다(또는 브로커가 수락하지 않았습니까?). 이 경우 고문은 어떻게 행동할까요? 이 경우 어떻게든 지정해야 합니까, 아니면 실행을 기다리지 않고 열기 요청을 보낼 수 있습니까?
나는 당신에 대해 불만이 없습니다.
K 파파클라스 도 없습니다.
당신은 그의 변호사입니까?
당신이 그의 변호사입니까? 나는 당신이 그를 위해 계산한 것이 마음에 들지 않았습니다. 거기에는 말할 수 있지만 당신에게는 그렇지 않지만 여기서는 할 수 없지만 그 삼촌은 할 수 있습니다.
그냥 싫다고 하던데요. 개인적인 주장 없음 - 순전히 상황에 관한 것입니다.
-Aleks- :
따라서 대략적인 데이터 처리 속도는 2000년부터 2013년까지 시가 기준 시간당 23회입니다.
1. Kamikadze_MA_V_01 - 5분
2. Kamikadze_MA_V_02 - 15분
3. Kamikadze_MA_V_03 - 30분 이상
그러한 작업은 단순히 고문을 신속하게 설정하는 기능을 죽입니다.
즉, 30분에 23패스 - 오랜만인가?..재미있다.
6월에서 9월까지 M15에 대한 고문이 테스터의 한 패스에 대한 모든 틱에 대해 하루를 보냅니다. 여기 있습니다. 일반적으로 최적화에 대해 이야기하고 있습니다. 그리고 그녀는 필요하지 않습니다 ...
6월에서 9월까지 M15에 대한 고문이 테스터의 한 패스에 대한 모든 틱에 대해 하루를 보냅니다. 여기 있습니다. 일반적으로 최적화에 대해 이야기하고 있습니다. 그리고 그녀는 필요하지 않습니다 ...
즉, 30분에 23패스 - 오랜만인가?..재미있다.
6월에서 9월까지 M15에 대한 고문이 테스터의 한 패스에 대한 모든 틱에 대해 하루를 보냅니다. 여기 있습니다. 일반적으로 최적화에 대해 이야기하고 있습니다. 그리고 그녀는 필요하지 않습니다 ...
가장 중요한 것은 Expert Advisor가 진화했을 때 작업 속도가 어떻게 퇴보했는지 보여 주었다는 것입니다. 진드기로 작동하는 전문가 고문 - 진드기가 생성되고 기록과 아무 관련이 없기 때문에 전혀 의심스럽습니다.
그리고 저는 M5 에 다중 화폐를 가지고 있으며 9개월 동안 15,000번의 유전학을 통과하는 데 20분을 소비합니다. 그러나 이것은 또한 지표가 아닙니다. 많이 사용되는 지표의 수에 따라 다릅니다...
지표의 계산된 데이터를 미리 준비하고 파일에 저장함으로써 역사에 대한 고문의 작업 속도를 크게 높일 수 있습니까?
가장 중요한 것은 Expert Advisor가 진화했을 때 작업 속도가 어떻게 퇴보했는지 보여 주었다는 것입니다. 진드기로 작동하는 전문가 고문 - 진드기가 생성되고 기록과 아무 관련이 없기 때문에 전혀 의심스럽습니다.
지표의 계산된 데이터를 미리 준비하고 파일로 저장함으로써 역사에 대한 고문의 작업 속도를 크게 높일 수 있습니까?
디스크에서 읽는 속도가 최적화된 지표를 계산하는 속도를 잃을 가능성이 있습니다. 원격 에이전트에 대한 계산은 어떻습니까? 계산된 지표를 보내시겠습니까? 특정한 경우 실행 속도를 최적화하기 위한 많은 옵션이 있습니다. 추가 주기는 피해야 합니다. + 각 틱에서 모든 작업을 수행하는 것이 그렇게 중요한지 생각하려면 " 새 막대 이벤트"로 제한하기에 충분할 것입니다.
디스크에서 읽는 속도가 최적화된 지표를 계산하는 속도를 잃을 가능성이 있습니다. 원격 에이전트에 대한 계산은 어떻습니까? 계산된 지표를 보내시겠습니까? 특정한 경우 실행 속도를 최적화하기 위한 많은 옵션이 있습니다. 추가 주기는 피해야 합니다. + 각 틱에서 모든 작업을 수행하는 것이 그렇게 중요한지 생각하려면 " 새 막대 이벤트"로 제한하기에 충분할 것입니다.
데이터를 한 번 읽고 배열을 만든 다음에만 액세스할 수 없나요?
내 특정 Expert Advisor에 관해서는 시작 가격에서 최적화를 수행했음을 상기시킵니다. 틱이 없어 보입니다. 생각해보면 결국 나는 내 자신의 코드를 최적화하기 위해 실행자에게 비용을 지불하지만 어드바이저의 작업에서 발생한 이벤트에 대한 코드를 확인하지 않고 옵티마이저에서 작업 속도의 상당한 증가를 약속합니다. 이것이 되길 바랍니다.
좋은 조언 감사합니다!
여기서 질문을 드리겠습니다. 바 오픈 시점에 20명의 어드바이저가 동시에 작업하면 데이터 계산 중에 가격이 많이 변경되기 때문에 이것이 피크 제동 및 오픈 오더로 이어지지 않습니까?
데이터를 한 번 읽고 배열을 만든 다음에만 액세스할 수 없나요?
테스트할 때 실행 기록이 발생합니다. 거래 에뮬레이션. 각 다음 카운트(어드바이저 호출)에서 이미 도착했을 데이터만 수신할 때. 파일의 경우 향후 호출에서 파일을 기다리는 미래를 포함하여 표시기의 모든 기록을 마음대로 사용할 수 있습니다. 저것들. 파일을 읽거나 어레이의 주소를 올바르게 지정해야 합니다. 그건 그렇고, 배열은 메모리에서 많은 공간을 차지합니다. 이것은 최적화할 때 이동해야 하는 방향이 아닙니다. 적어도 이 경우에는 그렇지 않습니다.
여기서 질문을 드리겠습니다. 바 오픈 시점에 20명의 어드바이저가 동시에 작업하면 데이터 계산 중에 가격이 많이 변경되기 때문에 이것이 피크 제동 및 오픈 오더로 이어지지 않습니까?
20명의 Expert Advisors가 모두 동일한 기기에 있는 경우 그렇습니다. 그들은 거의 동시에 컴퓨팅을 시작할 것입니다. 그러나 다음 사항을 고려해야 합니다.
- 각각은 별도의 스레드에서 실행됩니다. 4코어 컴퓨터 구성을 사용하면 간섭이 거의 또는 전혀 없이 4개가 동시에 실행될 수 있습니다.
- 단일 계산 시간은 거래 요청 을 보내는 시간과 비교할 수 없을 정도로 짧을 수 있습니다. 이러한 이유로 현재 가격으로 거래 주문을 비동기식으로 보내는 것이 좋습니다(여러 개를 한 번에 생성할 수 있는 경우). 이렇게 하면 두 번째 주문을 보내기 전에 첫 번째 주문 결과를 기다리지 않아도 됩니다. 하지만 여기에도 다른 옵션이 있을 수 있습니다... 모두 거래 전략에 따라 다릅니다.
Expert Advisors가 다른 기기에서 작업하는 경우 눈금과 새 막대가 동시에 발생하지 않는 경우가 가장 많습니다.
테스트할 때 실행 기록이 발생합니다. 거래 에뮬레이션. 각 다음 카운트(어드바이저 호출)에서 이미 도착했을 데이터만 수신할 때. 파일의 경우 향후 호출에서 파일을 기다리는 미래를 포함하여 표시기의 모든 기록을 마음대로 사용할 수 있습니다. 저것들. 파일을 읽거나 어레이의 주소를 올바르게 지정해야 합니다. 그건 그렇고, 배열은 메모리에서 많은 공간을 차지합니다. 이것은 최적화할 때 이동해야 하는 방향이 아닙니다. 적어도 이 경우에는 그렇지 않습니다.
20명의 Expert Advisors가 모두 동일한 기기에 있는 경우 그렇습니다. 그들은 거의 동시에 컴퓨팅을 시작할 것입니다. 그러나 다음 사항을 고려해야 합니다.
- 각각은 별도의 스레드에서 실행됩니다. 4코어 컴퓨터 구성을 사용하면 간섭이 거의 또는 전혀 없이 4개가 동시에 실행될 수 있습니다.
- 단일 계산 시간은 거래 요청 을 보내는 시간과 비교할 수 없을 정도로 짧을 수 있습니다. 이러한 이유로 현재 가격으로 거래 주문을 비동기식으로 보내는 것이 좋습니다(여러 개를 한 번에 생성할 수 있는 경우). 이렇게 하면 두 번째 주문을 보내기 전에 첫 번째 주문 결과를 기다리지 않아도 됩니다. 하지만 여기에도 다른 옵션이 있을 수 있습니다... 모두 거래 전략에 따라 다릅니다.
Expert Advisors가 다른 기기에서 작업하는 경우 눈금과 새 막대가 동시에 발생하지 않는 경우가 가장 많습니다.
오픈 주문에 주문을 보낼 때 인위적인 지연이 필요하다는 것을 올바르게 이해했지만 동시에 오픈 확인을 기다리지 않습니까?
오픈 주문에 주문을 보낼 때 인위적인 지연이 필요하다는 것을 올바르게 이해했지만 동시에 오픈 확인을 기다리지 않습니까?
micle :
никаких искусственных задержек делать не нужно. Это за вас сделает интернет и брокер...
수동 거래 중에 발생하는 다음 상황에 대해 이야기하고 있습니다. 주문을 열고 처리될 때까지 기다리라는 요청을 보냈습니다. 잠시 기다렸다가 다른 주문을 보내려고 하면 "채널이 바쁜" 결과적으로 가격 변동으로 인해 첫 번째 주문이 열리지 않고 두 번째 터미널에서 전송을 허용하지 않았습니다(또는 브로커가 수락하지 않았습니까?). 이 경우 고문은 어떻게 행동할까요? 이 경우 어떻게든 지정해야 합니까, 아니면 실행을 기다리지 않고 열기 요청을 보낼 수 있습니까?