오류, 버그, 질문 - 페이지 2315 1...230823092310231123122313231423152316231723182319232023212322...3184 새 코멘트 A100 2018.10.29 03:58 #23141 fxsaber : by_ref가 by_val보다 느린 이유는 무엇입니까? 그거 어디서 났어? 코드가 같은 경우 //Test.mqh int by_ref( string & var ) { return int ( var ) % 100 ; } int by_val( string var ) { return int ( var ) % 100 ; } //Test.mq5 #include "Test.mqh" #define ITERATIONS 1000000 #define MACRO( X ) \ { \ ulong time = GetMicrosecondCount (); \ for ( int i= 0 ; i<ITERATIONS; i++) \ { \ string r = string ( rand ); \ sum_ ##X += by_ ##X(r); \ } \ time_ ##X = GetMicrosecondCount () - time; \ } void OnStart () { for ( int i = 0 ; i < 10 ; i++ ) OnStart2( rand ()); } void OnStart2( int rand ) { long time_ref, sum_ref = 0 ; long time_val, sum_val = 0 ; MACRO( ref ) MACRO( val ) printf ( "%+10.3f:%d" , (time_ref-time_val)/ 1000.0 , sum_ref-sum_val ); } 그런 다음 결과(런타임 차이): +12.221:0 +5.099:0 +0.149:0 -13.729:0 +14.531:0 -27.429:0 +26.405:0 -0.839:0 +5.400:0 -4.882:0 작은 한계 내에서 교대(+\-) fxsaber 2018.10.29 07:36 #23142 A100 : 그거 어디서 났어? #define ITERATIONS 1000000 void OnStart () { string Str = "1" ; for ( int i = 0 ; i < 10 ; i++) Str += Str; for ( int j = 0 ; j < 5 ; j++) { { ulong time = GetMicrosecondCount (); ulong sum = 0 ; for ( int i= 0 ; i<ITERATIONS; i++){ string r = string ( rand ()) + Str ; sum += by_ref(r); } time = GetMicrosecondCount () - time; printf ( "%s took %.3f milliseconds: sum=%dll" , "by_ref" , time/ 1000.0 , sum); }{ ulong time = GetMicrosecondCount (); ulong sum = 0 ; for ( int i= 0 ; i<ITERATIONS; i++) sum += by_val( string ( rand ()) + Str ); time = GetMicrosecondCount () - time; printf ( "%s took %.3f milliseconds: sum=%dll" , "by_val" , time/ 1000.0 , sum); } Print ( "" ); } } //+------------------------------------------------------------------+ int by_ref( string &var){ return int (var) % 100 ; } int by_val( string var){ return int (var) % 100 ; }by_ref took 15119.806 milliseconds: sum=- 1000000 ll by_val took 13872.479 milliseconds: sum=- 1000000 ll by_ref took 14433.781 milliseconds: sum=- 1000000 ll by_val took 13817.533 milliseconds: sum=- 1000000 ll by_ref took 13889.424 milliseconds: sum=- 1000000 ll by_val took 14135.603 milliseconds: sum=- 1000000 ll by_ref took 16047.643 milliseconds: sum=- 1000000 ll by_val took 14494.432 milliseconds: sum=- 1000000 ll by_ref took 15542.276 milliseconds: sum=- 1000000 ll by_val took 13843.121 milliseconds: sum=- 1000000 ll fxsaber 2018.10.29 09:58 #23143 Nikolai Semko : KB로 평가하고 싶었지만 제대로 작동하지 않았습니다. 그리고 최신 출판물에 등급이 전혀 없는 것으로 판단하면 이 문제는 저만의 문제가 아닌 것 같습니다. 예, 작동하지 않습니다. A100 2018.10.29 10:18 #23144 fxsaber : ref 및 val 주기에 동일한 코드가 있지만(비교가 다소 정확함) 귀하의 코드는 다릅니다. fxsaber 2018.10.29 10:24 #23145 A100 : ref 및 val 주기에 동일한 코드가 있지만(비교가 다소 정확함) 귀하의 코드는 다릅니다. 예, 다릅니다. 그러나 질문은 여전히 관련성이 있습니다. val 버전이 ref보다 눈에 띄게 빠른 이유는 무엇입니까? TheXpert 2018.10.29 10:39 #23146 fxsaber : 예, 다릅니다. 그러나 질문은 여전히 관련성이 있습니다. val 버전이 ref보다 눈에 띄게 빠른 이유는 무엇입니까? 아마도 ref 변형이 컴파일러에 의해 최적화되었을 수 있습니다. 누가 알겠습니까? 나에 관해서는 두 옵션 모두 거의 동일한 코드로 컴파일되거나 완전히 동일해야 하지만 컴파일러는 다르게 생각합니다. fxsaber 2018.10.29 10:44 #23147 TheXpert : 아마도 ref 변형이 컴파일러에 의해 최적화되었을 수 있습니다. 누가 알겠습니까? 나에 관해서는 두 옵션 모두 거의 동일한 코드로 컴파일되거나 완전히 동일해야 하지만 컴파일러는 다르게 생각합니다. 질문은 실제로 개발자가 불일치에 대한 이유를 해체할 수 있는 기반을 갖기 위한 것이었습니다. 일반적으로 속도를 위해 모든 것을 참조로 전달하려고 합니다. 그리고 그것은 일부 빌드에서 정당화되었습니다. 하지만 이제 그녀는 그런 것 같습니다. reztor 2018.10.29 15:44 #23148 Alexey Kozitsyn : +1. 뭔가 고장난 것 같습니다. 빌드 1881 x64. Win 10. 시작 시 20+%%(i5 8600k) 및 650-700MB RAM(증가 없음)을 로드합니다. 작업 관리자에서 상태는 "응답 없음"입니다. 또한, 다른 단자(1881)(Opening이 아님)는 정상적으로 기동된다. 추가됨: 결국, 그것은 여전히 로드되었습니다. 그러나 다운로드하는 데 시간이 매우 오래 걸렸습니다. 이는 정상이 아닙니다. 그런 다음 터미널을 닫았다가 다시 열었습니다. 즉시 열렸습니다. 분명히 데이터를 로드하는 데 몇 가지 문제가 있었습니다. 터미널 재설치로 해결했습니다. 게다가 내가 실수로 폴더를 모든 설정과 그래프가 있는 폴더를 부숴버렸어) 다 새로 그렸는데 지금은 시계처럼 작동한다. [삭제] 2018.10.29 15:51 #23149 reztor : 터미널 재설치로 해결했습니다. 게다가 내가 실수로 폴더를 모든 설정과 그래프가 있는 폴더를 부숴버렸어) 다 새로 그렸는데 지금은 시계처럼 작동한다. 필요하지 않았습니다. news.dat 파일을 삭제했을 수도 있습니다 . A100 2018.10.29 17:19 #23150 TheXpert : 아마도 ref 변형이 컴파일러에 의해 최적화되었을 수 있습니다. 누가 알겠습니까? 나에 관해서는 두 옵션 모두 거의 동일한 코드로 컴파일되거나 완전히 동일해야 하지만 컴파일러는 다르게 생각합니다. 그리고 최종 코드와 실행 시간은 어떤 관련이 있습니까? 예를 들어, 주기가 정확히 동일하도록 변경해 보겠습니다 . #define ITERATIONS 1000000 void OnStart () { string Str = "1" ; for ( int i = 0 ; i < 10 ; i++) Str += Str; for ( int j = 0 ; j < 5 ; j++) { { ulong time = GetMicrosecondCount (); ulong sum = 0 ; for ( int i= 0 ; i<ITERATIONS; i++) sum += by_ref( string ( rand ()) + Str); time = GetMicrosecondCount () - time; printf ( "%s took %.3f milliseconds: sum=%dll" , "by_ref" , time/ 1000.0 , sum); } { ulong time = GetMicrosecondCount (); ulong sum = 0 ; for ( int i= 0 ; i<ITERATIONS; i++) sum += by_val( string ( rand ()) + Str); time = GetMicrosecondCount () - time; printf ( "%s took %.3f milliseconds: sum=%dll" , "by_val" , time/ 1000.0 , sum); } Print ( "" ); } } int by_ref( string var){ return int (var) % 100 ; } int by_val( string var){ return int (var) % 100 ; } 결과: by_ref는 18354.547밀리초가 걸렸습니다: sum=1865600ll by_val은 18318.319밀리초가 걸렸습니다: sum=1861628ll by_ref는 18416.747밀리초가 걸렸습니다: sum=1904488ll by_val은 18221.978밀리초가 걸렸습니다: sum=1907860ll by_ref는 18301.009밀리초가 걸렸습니다: sum=1757988ll by_val은 18545.258밀리초가 걸렸습니다: sum=1949720ll by_ref는 18373.648 밀리초가 걸렸습니다: sum=1867160ll by_val은 17972.432 밀리초가 걸렸습니다. 합계=1760308ll by_ref는 19426.076 밀리초가 걸렸습니다: sum=1795564ll by_val은 19177.485 밀리초가 걸렸습니다: sum=1826360ll 거의 동일합니다 ... 아니면 컴파일러가 동일한주기에서 다른 코드를 생성했다고 생각합니까? 있었다는 것을 상기시켜 드리겠습니다. by_ref는 13889.424 밀리초가 걸렸습니다: sum=- 1000000 ll by_val은 14135.603 밀리초가 걸렸습니다. 합계=- 1000000 ll 그리고 다른 코드... 그리고 여기에는 거의 같은 시간 차이가 있지만 코드와 기능 자체는 정확히 동일합니다. Errors, bugs, questions SQLite: MQL5로 SQL 데이터베이스의 OpenCL: 기본에서 통찰력 있는 1...230823092310231123122313231423152316231723182319232023212322...3184 새 코멘트 트레이딩 기회를 놓치고 있어요: 무료 트레이딩 앱 복사용 8,000 이상의 시그널 금융 시장 개척을 위한 경제 뉴스 등록 로그인 공백없는 라틴 문자 비밀번호가 이 이메일로 전송될 것입니다 오류 발생됨 Google으로 로그인 웹사이트 정책 및 이용약관에 동의합니다. 계정이 없으시면, 가입하십시오 MQL5.com 웹사이트에 로그인을 하기 위해 쿠키를 허용하십시오. 브라우저에서 필요한 설정을 활성화하시지 않으면, 로그인할 수 없습니다. 사용자명/비밀번호를 잊으셨습니까? Google으로 로그인
by_ref가 by_val보다 느린 이유는 무엇입니까?
그거 어디서 났어?
코드가 같은 경우
그런 다음 결과(런타임 차이):
+12.221:0
+5.099:0
+0.149:0
-13.729:0
+14.531:0
-27.429:0
+26.405:0
-0.839:0
+5.400:0
-4.882:0
작은 한계 내에서 교대(+\-)
그거 어디서 났어?
KB로 평가하고 싶었지만 제대로 작동하지 않았습니다. 그리고 최신 출판물에 등급이 전혀 없는 것으로 판단하면 이 문제는 저만의 문제가 아닌 것 같습니다.
예, 작동하지 않습니다.
ref 및 val 주기에 동일한 코드가 있지만(비교가 다소 정확함) 귀하의 코드는 다릅니다.
예, 다릅니다. 그러나 질문은 여전히 관련성이 있습니다. val 버전이 ref보다 눈에 띄게 빠른 이유는 무엇입니까?
예, 다릅니다. 그러나 질문은 여전히 관련성이 있습니다. val 버전이 ref보다 눈에 띄게 빠른 이유는 무엇입니까?
아마도 ref 변형이 컴파일러에 의해 최적화되었을 수 있습니다. 누가 알겠습니까?
나에 관해서는 두 옵션 모두 거의 동일한 코드로 컴파일되거나 완전히 동일해야 하지만 컴파일러는 다르게 생각합니다.
아마도 ref 변형이 컴파일러에 의해 최적화되었을 수 있습니다. 누가 알겠습니까?
나에 관해서는 두 옵션 모두 거의 동일한 코드로 컴파일되거나 완전히 동일해야 하지만 컴파일러는 다르게 생각합니다.
질문은 실제로 개발자가 불일치에 대한 이유를 해체할 수 있는 기반을 갖기 위한 것이었습니다.
일반적으로 속도를 위해 모든 것을 참조로 전달하려고 합니다. 그리고 그것은 일부 빌드에서 정당화되었습니다. 하지만 이제 그녀는 그런 것 같습니다.
+1. 뭔가 고장난 것 같습니다. 빌드 1881 x64. Win 10. 시작 시 20+%%(i5 8600k) 및 650-700MB RAM(증가 없음)을 로드합니다.
작업 관리자에서 상태는 "응답 없음"입니다.
또한, 다른 단자(1881)(Opening이 아님)는 정상적으로 기동된다.
추가됨:
결국, 그것은 여전히 로드되었습니다. 그러나 다운로드하는 데 시간이 매우 오래 걸렸습니다. 이는 정상이 아닙니다. 그런 다음 터미널을 닫았다가 다시 열었습니다. 즉시 열렸습니다. 분명히 데이터를 로드하는 데 몇 가지 문제가 있었습니다.
터미널 재설치로 해결했습니다. 게다가 내가 실수로 폴더를 모든 설정과 그래프가 있는 폴더를 부숴버렸어) 다 새로 그렸는데 지금은 시계처럼 작동한다.
필요하지 않았습니다. news.dat 파일을 삭제했을 수도 있습니다 .
아마도 ref 변형이 컴파일러에 의해 최적화되었을 수 있습니다. 누가 알겠습니까?
나에 관해서는 두 옵션 모두 거의 동일한 코드로 컴파일되거나 완전히 동일해야 하지만 컴파일러는 다르게 생각합니다.
그리고 최종 코드와 실행 시간은 어떤 관련이 있습니까?
예를 들어, 주기가 정확히 동일하도록 변경해 보겠습니다 .
결과:
by_ref는 18354.547밀리초가 걸렸습니다: sum=1865600ll
by_val은 18318.319밀리초가 걸렸습니다: sum=1861628ll
by_ref는 18416.747밀리초가 걸렸습니다: sum=1904488ll
by_val은 18221.978밀리초가 걸렸습니다: sum=1907860ll
by_ref는 18301.009밀리초가 걸렸습니다: sum=1757988ll
by_val은 18545.258밀리초가 걸렸습니다: sum=1949720ll
by_ref는 18373.648 밀리초가 걸렸습니다: sum=1867160ll
by_val은 17972.432 밀리초가 걸렸습니다. 합계=1760308ll
by_ref는 19426.076 밀리초가 걸렸습니다: sum=1795564ll
by_val은 19177.485 밀리초가 걸렸습니다: sum=1826360ll
거의 동일합니다 ... 아니면 컴파일러가 동일한주기에서 다른 코드를 생성했다고 생각합니까?
있었다는 것을 상기시켜 드리겠습니다.
by_ref는 13889.424 밀리초가 걸렸습니다: sum=- 1000000 ll
by_val은 14135.603 밀리초가 걸렸습니다. 합계=- 1000000 ll
그리고 다른 코드... 그리고 여기에는 거의 같은 시간 차이가 있지만 코드와 기능 자체는 정확히 동일합니다.