MT5와 속도 - 페이지 45

새 코멘트
 
Andrey Khatimlianskii :

아니요, CentOS에서 회전하는 가상 머신이 있습니다. 그러나 나는 이 대화를 계속할 자격이 없습니다.

여전히 이중 가상화.

CentOS -> VirtualBox -> Windows 7


프로세서가 8일 때 2개의 코어로 또 다른 감소는 스레드 스케줄러의 동작과 할당된 리소스를 근본적으로 변경합니다.

이 2개의 코어는 Windows 7을 줄여도 불가피한 1000개의 스레드에 분배되어야 합니다. 따라서 터미널의 대기 시간이 증가하는 것이 보장됩니다.

 
Renat Fatkhullin :

글쎄, 당신은 상관 관계와 합리성을 통제하지 않고 스트레스 테스트를 실행하는 데 마스터입니다.

물론 마이크로초 측정에는 밀리초보다 1000배 적은 간격을 측정할 수 있는 리소스가 필요합니다.

주기적으로 간격을 매우 정확하게 측정해야 하는 경우 마이크로초 를 사용하십시오. 그리고 비용은 0마이크로초입니다.

정확히 속도가 느려질 때 마이크로초를 사용하는 방법?! 총 20개의 호출이 있습니다. 다양한 실제 작업에 대한 말도 안되는 수의 호출 에 1/4 밀리초.

 2020.10 . 06 00 : 50 : 44.491 Alert : Time[Test6.mq5 15 : for (inti= 0 ;i< 20 ;i++) GetMicrosecondCount ();] = 254 mсs.
2020.10 . 06 00 : 50 : 44.491 Alert : Time[Test6.mq5 20 : for (inti= 0 ;i< 20 ;i++) GetTickCount ();] = 19 mсs.

교살된 VPS에서 timeBeginPeriod를 통해 시스템 타이머를 오버클럭하는 것은 어렵습니다. CPU 비용을 증가시키기만 하면 됩니다.

그렇지 않았다면 그들은 오래전에 운영체제에서 정확한 GetTickCount/GetTickCount64를 만들고 자유로운 정확도에 기뻐했을 것입니다. 그러나 아니요, 이 타이머의 정확성에 대한 비용을 지불해야 합니다.


GetTickCount에 비해 속도가 떨어지지 않습니다. GetMicrosecondsCount 대신 느린 VPS에서 사용하도록 전환했습니다. 라이브 거래에서 다운로드가 50%에서 2%로 떨어졌습니다.

 2020.10 . 06 00 : 50 : 44.491 Alert : Time[Test6.mq5 26 : for (inti= 0 ;i< 20 ;i++) winmm::timeGetTime() ;] = 13 mсs.
 
fxsaber :

정확히 속도가 느려질 때 마이크로초를 사용하는 방법?! 총 20개의 호출이 있습니다. 다양한 실제 작업에 대한 말도 안되는 수의 호출 에 1/4 밀리초.

그리고 다음과 같은 20개의 전화가 있습니다.

   ulong ticks=GetMicrosecondCount();
   for(int i=0; i<20; i++)
      GetMicrosecondCount();
   Print("GetMicrosecondCount: ",GetMicrosecondCount()-ticks);

   ticks=GetMicrosecondCount();
   for(int i=0; i<20; i++)
      GetTickCount();
   Print("GetTickCount: ",GetMicrosecondCount()-ticks);


2020.10 . 06 01 : 04 : 44.068 5555 (CAT.NYSE,M5)       GetMicrosecondCount : 1
2020.10 . 06 01 : 04 : 44.068 5555 (CAT.NYSE,M5)       GetTickCount : 0


GetTickCount에 비해 속도가 떨어지지 않습니다. GetMicrosecondsCount 대신 느린 VPS에서 사용하도록 전환했습니다. 라이브 거래에서 다운로드가 50%에서 2%로 떨어졌습니다.

GetMicrosecondsCount -> GetTickCount 교체가 실제 프로그램에서 작동하지 않을 것이라고 생각합니다. 이론적으로나 실질적으로 증거가 없습니다.

이 두 함수에 대한 스트레스 테스트에서 이것을 쉽게 그릴 수 있습니다. CPU 부하의 48%가 마이크로초를 측정하여 완료되었다고 스스로 결론지습니까? 그리고 스트레스 테스트 아닌가요? 물론 그는 최고입니다.


멀티미디어 타이머의 가속에 대해 - 이것은 다시 일반적인 성능 저하와 상관없이 스트레스 테스트입니다. 작업 스케줄러를 오버클러킹하면 운영 체제의 시스템 오버헤드가 증가합니다.

 
Renat Fatkhullin :

여전히 이중 가상화.

CentOS -> VirtualBox -> Windows 7


프로세서가 8일 때 2개의 코어로 또 다른 감소는 스레드 스케줄러의 동작과 할당된 리소스를 근본적으로 변경합니다.

이 2개의 코어는 Windows 7을 줄여도 불가피한 1000개의 스레드에 분배되어야 합니다. 따라서 터미널의 대기 시간이 증가하는 것이 보장됩니다.

저도 같은 결론에 이르렀습니다, 확인해주셔서 감사합니다. VirtualBox는 악입니다.
그리고 특히 VPS를 조심해야 합니다. 이러한 배포에는 VPS가 많이 있습니다.
하드웨어의 깨끗한 운영 체제만 있으면 Linux가 더 좋습니다.
와인을 통해 동일한 가상화, 하지만 터미널 GUI는 단일 지연 없이 날아갑니다.
그리고 GetMicrosecondsCount는 지연 없이 회전합니다.  

 
Renat Fatkhullin :

그리고 다음과 같은 20개의 전화가 있습니다.

글쎄, 나는 0 마이크로 초를 가지고 있습니다! 홈 머신에서만 가능합니다.

GetMicrosecondsCount -> GetTickCount를 교체하면 실제 프로그램이 제공될 것이라고 믿지 않습니다. 이론적으로나 실질적으로 증거가 없습니다.

이 두 함수에 대한 스트레스 테스트에서 이것을 쉽게 그릴 수 있습니다. CPU 부하의 48%가 마이크로초를 측정하여 수행되었다는 결론을 내리셨습니까? 그리고 스트레스 테스트 아닌가요? 물론 그는 최고입니다.

이 스레드는 소스에 속도 테스트를 간단히 포함할 수 있도록 Benchmark 라이브러리를 작성하라는 메시지를 표시했습니다. 그리고 그는 이것을 상당히 널리 이용하여 많은 나쁜 것들을 식별하고 제거했습니다.

그래서 고문은 이런 식으로 (더 정확하게는 병렬로 20 개) 1.5 % 가정용 컴퓨터를로드합니다. 그러나 VPS는 50+%입니다. 나는 파기 시작했고 마이크로초 타이머가 느려지는 것을 발견했습니다. 따라서 홈 머신에서 경고가 작동하지 않는 경우 VPS에 비가 내렸습니다 .


그러나 이것으로도 충분하지 않습니다. 이 분기 덕분에 스냅샷 메커니즘이 개발되었으며 그 기반이 됩니다. 

   ulong Snapshot( const uint &RefreshTime, const MAGIC_TYPE &Magic, bool HistoryInit = false )
  {
     if ( SNAPSHOT::SnapshotLifeTime() < RefreshTime )
       return ( 0 );
// ....

   ulong SnapshotLifeTime( void ) const
  {
     static const bool IsTester = :: MQLInfoInteger ( MQL_TESTER );

     return (IsTester ? ULONG_MAX : ( :: GetMicrosecondCount () - this .TimeData)); // Обязуем любой вызов снепшота в Тестере делать полноценным.
  }

이것은 모든 스냅샷의 기초입니다. 마지막 스냅샷 이후 지정된 시간보다 더 적은 시간이 경과하면 아무 작업도 수행하지 않습니다. 리소스를 크게 절약할 수 있는 것은 이 접근 방식입니다.

물론 업데이트 시간은 짧습니다. 기본적으로 1밀리초입니다. 따라서 마이크로초 타이머가 사용됩니다.


따라서이 타이머의 브레이크로 인해 스냅 샷 메커니즘이 파괴되었습니다. 본격적인 스냅샷은 본격적인 머신보다 10배/2배 더 자주 만들어졌습니다.


이것은 마이크로초 타이머의 브레이크에서 나온 파이입니다. 그러나 16ms가 아닌 밀리초로 전환했을 때 브레이크 VPS에서도 모든 것이 날아가기 시작했습니다.

멀티미디어 타이머의 가속에 대해 - 이것은 다시 일반적인 성능 저하와 상관없이 스트레스 테스트입니다. 작업 스케줄러를 오버클럭하면 운영 체제의 시스템 오버헤드가 증가합니다.

예, 실제로 큰 이득이 있다면 이러한 이론에 신경 쓰지 마십시오. 일부 게임에 영향을 미칠 수 있습니다. 그러나 VPS에서는 절약하는 빨대였습니다.

 
fxsaber :

글쎄, 나는 0 마이크로초를 가지고 있다! 홈 머신에서만 가능합니다.

이 스레드는 소스에 속도 테스트를 간단히 포함할 수 있도록 Benchmark 라이브러리를 작성하라는 메시지를 표시했습니다. 그리고 그는 이것을 상당히 널리 이용하여 많은 나쁜 것들을 식별하고 제거했습니다.

그래서 고문은 이런 식으로 (더 정확하게는 병렬로 20 개) 1.5 %만큼 가정용 컴퓨터를로드합니다. 그러나 VPS는 50+%입니다. 나는 파기 시작했고 마이크로초 타이머가 느려지는 것을 발견했습니다. 따라서 홈 머신에서 경고가 작동하지 않는 경우 VPS에 비가 내렸습니다 .


그러나 이것으로도 충분하지 않습니다. 이 분기 덕분에 스냅샷 메커니즘이 개발되었으며 그 기반이 됩니다.

이것은 모든 스냅샷의 기초입니다. 마지막 스냅샷 이후 지정된 시간 미만이 경과하면 아무 작업도 수행하지 않습니다. 리소스를 크게 절약할 수 있는 것은 이 접근 방식입니다.

물론 업데이트 시간은 짧습니다. 기본적으로 1밀리초입니다. 따라서 마이크로초 타이머가 사용됩니다.


따라서이 타이머의 브레이크로 인해 스냅 샷 메커니즘이 파괴되었습니다. 본격적인 스냅샷은 본격적인 머신보다 훨씬 더 자주 만들어졌습니다.


이것은 마이크로초 타이머의 브레이크에서 나온 파이입니다. 그러나 16ms가 아닌 밀리초로 전환했을 때 브레이크 VPS에서도 모든 것이 날아가기 시작했습니다.

예, 실제로 큰 이득이 있다면 이러한 이론에 신경 쓰지 마십시오. 일부 게임에 영향을 미칠 수 있습니다. 그러나 VPS에서는 절약하는 빨대였습니다.

그것이 얼마나 아름답게 말되었는지보십시오.

GetMicrosecondsCount 대신 느린 VPS에서 사용하도록 전환했습니다. 라이브 거래에서 다운로드가 50%에서 2%로 떨어졌습니다.

결론은 "모두 마이크로초 측정의 브레이크, 그것이 바로 가속도 때문"이었다.

그리고 갑자기 "논리적 오류로 인해 나 자신이 계산을 훨씬 더 많이 수행했습니다." 그리고 GetMicrosecondsCount는 이 오류의 트리거일 뿐입니다.

GetTickCount에 대한 변경 사항은 이 버그에 대한 수정 사항이며 수정 코드는 표시되지 않았습니다. 대체 GetMicrosecondsCount -> GetTickCount가 없기 때문에?

왜 바로 말하지 못했을까?


논리로 판단하면 계정의 명시적 조대화(마이크로초에서 밀리초로 점프)와 스냅샷 생성의 다중 감소로 인해 가속이 획득되었습니다.
 
나는 이것을 덜 자주 실행하기 위해 SymbolInfoTick 스냅샷 의 편의성을 여전히 고려하고 있습니다.
 2020.10 . 05 12 : 52 : 35.963          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 599 mсs.
2020.10 . 05 12 : 52 : 45.904          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 245 mсs.
2020.10 . 05 12 : 52 : 45.904          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 470 mсs.
2020.10 . 05 12 : 52 : 45.904          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 722 mсs.
2020.10 . 05 12 : 52 : 45.904          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 901 mсs.
2020.10 . 05 12 : 52 : 45.905          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 1726 mсs.
2020.10 . 05 12 : 53 : 00.123          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 864 mсs.
2020.10 . 05 12 : 53 : 03.218          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 112 mсs.
2020.10 . 05 12 : 53 : 04.493          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 2134 mсs.
2020.10 . 05 12 : 53 : 10.013          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 1826 mсs.
2020.10 . 05 12 : 53 : 13.119          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 114 mсs.
2020.10 . 05 12 : 53 : 18.008          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 116 mсs.
2020.10 . 05 12 : 53 : 20.010          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 1095 mсs.
2020.10 . 05 12 : 55 : 55.033          Alert : Time[NewTicks.mqh 33 in NEWTICKS::GetMarketWatchTick: :: SymbolInfoTick ( _Symbol ,Tick)] = 359 mсs.

이것은 1.5% CPU로 20개 EA를 연마하는 기계입니다. 모든 LatencyMon이 모든 것이 정상임을 보여줍니다.

MT5 아키텍처의 어떤 것이 동시에 실행 중인 모든 Expert Advisors에게 이러한 지연을 제공합니다. 그리고 나는 아무도.

 
Renat Fatkhullin :

GetTickCount에 대한 변경은 이 버그에 대한 수정 사항이며 수정 코드는 표시되지 않았습니다. 대체 GetMicrosecondsCount -> GetTickCount가 없기 때문에?

왜 바로 말하지 못했을까?

나와의 토론은 여전히 보여야 할 것이 있다는 점에서 구별됩니다. 감춰진 것은 없지만 오히려 공개적으로 공개 된다.

확실히 스트레스 테스트가 있습니다. 그것을 명확하게 보여줄 다른 방법이 없었습니다.


인형 형태의 기능을 상상해보십시오. 외부 matryoshka가 측정됩니다. 동시에 측정은 내부 matryoshka로도 이루어집니다. 결과적으로, 마이크로초의 브레이크로 인해 외부 마트료시카는 실행 기간 측면에서 와일드한 숫자를 보여 동일한 유형의 경고가 발생합니다. 분명히 GetMicrosecondsCount에 대한 호출당 10마이크로초는 매우 비쌉니다. 그래서 그는 경고를 보냈다.


무료 러프 밀리초 타이머는 0 µs, 1000 µs 또는 2000 µs를 발행하기 시작했습니다. 이것은 경고의 수를 크게 줄이고 타이머 기능에 대한 호출에 대한 브레이크를 줄였습니다.


논리로 판단하면 계정의 명시적 조대화(마이크로초에서 밀리초로 점프)와 스냅샷 생성의 다중 감소로 인해 가속이 획득되었습니다.


글쎄, 스냅샷으로 그것은 일반적으로 훌륭합니다. 홈 머신(마이크로초 있어)에 비해 조잡함이 강하지 않습니다. 그러나 하늘과 땅과 같은 VPS에 있었던 것과 비교할 때.


PS 우리는 불행히도 존재하지 않는 MQL에서 밀리초 타이머를 갖는 편리성에 대해 이야기하고 있습니다. 그것 없이는 VPS에 스냅샷을 찍을 수 없습니다.

 
fxsaber :
나는 이것을 덜 자주 실행하기 위해 SymbolInfoTick 스냅샷의 편의성을 여전히 고려하고 있습니다.

이것은 1.5% CPU로 20개 EA를 연마하는 기계입니다. 모든 LatencyMon이 모든 것이 정상임을 보여줍니다.

MT5 아키텍처의 어떤 것이 동시에 실행 중인 모든 Expert Advisors에게 이러한 지연을 제공합니다. 그리고 나는 아무도.

다음은 내 코드와 안정적인 실행 시간입니다. 병렬로 20개의 그래프에서 수백, 수천 마이크로초가 필요하지 않습니다. 

   MqlTick Tick;
   ulong    ticks= GetMicrosecondCount ();
   
   SymbolInfoTick ( _Symbol ,Tick);
   Print (" SymbolInfoTick : ", GetMicrosecondCount ()-ticks);


2020.10.06 02:14:18.234	5555 (CADJPY,H1)	SymbolInfoTick: 2
2020.10.06 02:14:18.765	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.063	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.180	5555 (CADJPY,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.180	5555 (EURCAD,H1)	SymbolInfoTick: 1
2020.10.06 02:14:19.245	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:19.523	5555 (CHFJPY,H1)	SymbolInfoTick: 1
2020.10.06 02:14:19.659	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.037	5555 (CADCHF,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.037	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.137	5555 (EURMXN,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.138	5555 (EURNOK,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.226	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.227	5555 (CHFJPY,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.525	5555 (AUDNZD,H1)	SymbolInfoTick: 1
2020.10.06 02:14:20.645	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:20.919	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:21.123	5555 (EURNZD,H1)	SymbolInfoTick: 1
2020.10.06 02:14:21.129	5555 (EURAUD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:21.234	5555 (EURNOK,H1)	SymbolInfoTick: 1
2020.10.06 02:14:21.441	5555 (EURAUD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:22.299	5555 (EURNZD,H1)	SymbolInfoTick: 2
2020.10.06 02:14:22.383	5555 (AUDNZD,H1)	SymbolInfoTick: 2

몇 개의 코어와 프로세서가 있습니까? i7-2600?

수백만 개의 요청을 병렬로 사용하여 다시 숨겨진 스트레스 테스트를 하시겠습니까?


투명해야 합니다. 간단한 _B 호출 몇 개를 게시했다는 사실이 다른 주장의 증거가 아닙니다. 터무니없는 진술을 하자마자 코드와 조건에 대한 실제 설명을 갑자기 잊어버립니다.

마음속으로 아무 것도 상상할 필요가 없습니다. 실제로 호출하고 테스트하는 것을 말하고 보여줍니다. 찢어진 결과는 "알 수 없는 스트레스 테스트를 시작하고 경고가 세상에 표시되기를 기다리는 중"이 아니라 테스트의 전체 코드입니다.

측정 라이브러리 자체에 대한 질문도 있습니다. 갑자기 오버 헤드를 포함하여 불필요한 것은 엉망이됩니다.

 
fxsaber :

PS 우리는 불행히도 존재하지 않는 MQL에서 밀리초 타이머를 갖는 편리성에 대해 이야기하고 있습니다. 그것 없이는 VPS에 스냅샷을 찍을 수 없습니다.

밀리초 타이머는 오랫동안 사용되어 왔습니다. EventSetMillisecondTimer()

Документация по MQL5: Работа с событиями / EventSetMillisecondTimer
Документация по MQL5: Работа с событиями / EventSetMillisecondTimer
  • www.mql5.com
Указывает клиентскому терминалу, что для данного эксперта или индикатора необходимо генерировать события таймера с периодичностью менее одной секунды. нужно получать события таймера чаще, чем один раз в секунду. Если вам достаточно обычного таймера с периодом более 1 секунды, то используйте EventSetTimer(). В тестере стратегий используется...
1...383940414243444546474849505152...94
새 코멘트