내가 무엇을 더 할 수 있습니까? 히스토리 내보내기 파일(22미터 아카이브 - 150 압축 해제)을 게시할 수 있으며 가져오기를 통해 테스트를 실행할 수 있습니다. 최적화(오프라인에서 경주) 당시 내 스프레드는 17pp였습니다. 그들의 Alparevsky 5 기호에서. 당신은 또한 그것을 노출할 수 있습니다 - 나는 프로그램에 대한 링크를 제공했습니다.
1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 랏=0.1 MaximumRisk=0.02 DecreaseFactor=3 Peter , 거래 수를 기준으로 정렬하는 것 같습니다. 왜냐하면 귀하와 동일한 외부 매개변수가 정렬되어 있습니다(파란색으로 강조 표시됨). 글쎄, 우리는 5 %를 노크했지만 이것은 나를 만족시키지 못합니다 ...
여기에 BARS 는 외부 vidyakha(통합 삼키기 메모리)를 넣는 것이 좋습니다. 이것은 내가 확인할 수 있습니다.
그리고 제 생각에는 돌과 기억의 FSB 동기화라는 또 다른 요소가 있다고 생각합니다. 최대 성능은 동일할 때이지만 최대 약 3.8GHz까지 스톤을 1.5배 오버클럭해야 합니다. 스톤은 저런거 버틸수잇는데 오버클럭용이 아니라 오른손수건이 없어서...
우리는 테스터의 속도를 테스트할 때 리얼리즘을 원하고, 현실과 아무 관련이 없는 멍청하고 거래가 없는 Expert Advisors와 쓸모없는 구형 말을 실제로 다루고 싶지 않기 때문에 얼마나 많은 시간을 소비했는지 추정해 봅시다. 에 무슨.
1. 터미널과 그 안에 있는 옵티마이저의 오버헤드. t1
2. 로그를 파일에 쓰는 시간. t2
3. 전문가의 실행 시간, 바 void start()에서 전체 1주기. t3
총 시간:
T=k*막대*(t1+t2+t3)
옵티마이저의 k-패스 수, 모두 동일, const
막대 - 기록에 있는 막대의 수 , 테스트 참가자 간의 차이는 1%(추정) 이하이며, 충분한 정확도로 허용될 수 있습니다. const
t1-외부 요인(외부 날씨, 경제 위기 등)에 의존하지 않고 테스트된 하드웨어에만 의존합니다.
t2 - 철도에 따라 다릅니다.
t3 - 하드웨어와 직접적인 관련이 없는 많은 요인에 따라 달라지며 코드의 거래 기능 내용으로 인해 결과의 정확도에 영향을 미칩니다.
모든 응시자에게 공평한 경쟁의 장을 보장하기 위해 세 가지 구성 요소 중 어떤 것에 영향을 줄 수 있습니까?
글쎄, 아마도 t3.
거래 건수로 뭔가를 하기는 어렵습니다. 그러나 다른 한편으로는 테스트에 대한 부정적인 요인의 영향을 최소화하기 위해 Expert Advisor의 코드에 "매우 유용한" 계산 블록을 추가할 수 있습니다. "매우 유용한" 계산 블록이 전체 시간의 95-99%를 차지한다고 가정해 보겠습니다. 모든 것. 문제 해결됨. 우리의 실험에 대해 충분히 높은 신뢰성이 달성될 것입니다.
추신 구형 말 일명 스크립트를 희생하면서. 옵티마이저에는 전문가 최적화와 관련이 없는 작업이 많이 있습니다. 이들은 컴퓨팅 리소스에 대한 욕심과 스크립트의 복잡한 수학 계산에 대한 지표입니다. 예를 들어, 내 지표는 400-600-200개의 뉴런이 있는 ns를 사용합니다. 360800 스케일입니다. 이 헤비급을 훈련하기 위해 나는 별도의 스크립트를 사용합니다. 그리고 표시기는 이미 파일에서 기성품 무게를 읽고 있습니다. 지표 자체에서 훈련을 구현하면 차트를 표시하는 데 문제가 있음이 분명합니다. 더 많은 예를 들 수 있습니다.
새로운 답변과 새로운 질문 - 당신은 여전히 생각보다 빠릅니다. 그리고 그 이유도 분명합니다. 여전히 저보다 적은 수의 트랜잭션이 있습니다(같은 설정의 43012개) ... 차이가 더 이상 크지는 않지만 약 10%입니다.
하지만 이것으로 할 일이 또 있습니다. 아직 알아내지 못했습니다.
테이블을 변경했습니다.
Mathemat , 게시물의 Peter's와 같은 매개변수로 테스트를 실행하십시오. 얼마나 많은 트랜잭션이 있습니까?
Peter , 이것이 최대 거래 수입니까? 글쎄, 즉, 거래 수로 결과를 정렬하는 것입니까?
Peter, 이것이 최대 거래 수입니까? 글쎄, 즉, 거래 수로 결과를 정렬하는 것입니까?
아니요. 이것은 최적화의 첫 번째 반복일 뿐입니다. 당신은 양의 극단에 관심이 있습니까? 그런 다음 테스트를 다시 실행해야 합니다. 이미 해당 터미널을 떠났습니다. 하지만 할 수 있습니다. 컴퓨터가 아직 로드되지 않았습니다. 그게 필요 할까?
510 -12767.51 8719 0.72 -1.46 13779.51 1.38% MovingPeriod=55 MovingShift=10 랏=0.1 MaximumRisk=0.02 DecreaseFactor=3
1 -56968.97 39923 0.61 -1.43 57046.37 5.70% MovingPeriod=5 MovingShift=1 lot=0.1 MaximumRisk=0.02 DecreaseFactor=3
이상하게도 이것이 처음이자 마지막 반복이었습니다.
내가 무엇을 더 할 수 있습니까? 히스토리 내보내기 파일(22미터 아카이브 - 150 압축 해제)을 게시할 수 있으며 가져오기를 통해 테스트를 실행할 수 있습니다. 최적화(오프라인에서 경주) 당시 내 스프레드는 17pp였습니다. 그들의 Alparevsky 5 기호에서. 당신은 또한 그것을 노출할 수 있습니다 - 나는 프로그램에 대한 링크를 제공했습니다.
내 테스트는 9:05와 동일합니다.
1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 랏=0.1 MaximumRisk=0.02 DecreaseFactor=3
Peter , 거래 수를 기준으로 정렬하는 것 같습니다. 왜냐하면 귀하와 동일한 외부 매개변수가 정렬되어 있습니다(파란색으로 강조 표시됨). 글쎄, 우리는 5 %를 노크했지만 이것은 나를 만족시키지 못합니다 ...
여기에 BARS 는 외부 vidyakha(통합 삼키기 메모리)를 넣는 것이 좋습니다. 이것은 내가 확인할 수 있습니다.
그리고 제 생각에는 돌과 기억의 FSB 동기화라는 또 다른 요소가 있다고 생각합니다. 최대 성능은 동일할 때이지만 최대 약 3.8GHz까지 스톤을 1.5배 오버클럭해야 합니다. 스톤은 저런거 버틸수잇는데 오버클럭용이 아니라 오른손수건이 없어서...
그리고 ixbt에서 읽은 것처럼 메모리 타이밍은 그다지 중요하지 않습니다.
추신: 저도 Alpari를 가지고 있지만 메타쿼트 서버에서 데이터를 다운로드했습니다.
나는 총 6 710 383 건의 거래를 가지고 있으며, 따라서 패스당 평균은 13157.61입니다.
여기에 BARS 는 외부 vidyakha(통합 삼키기 메모리)를 넣는 것이 좋습니다. 이것은 내가 확인할 수 있습니다.
그리고 내 생각에는 돌과 기억의 FSB 동기화라는 또 하나의 요소가 있다고 생각합니다. 최대 성능은 동일할 때이지만 최대 약 3.8GHz까지 스톤을 1.5배 오버클럭해야 합니다. 스톤은 저런거 버틸수잇는데 오버클럭용이 아니라 오른손수건이 없어서...
그리고 ixbt에서 읽은 것처럼 메모리 타이밍은 그다지 중요하지 않습니다.
이러한 메모리 속도와 2 채널의 존재로 통합 비디오를 무시할 수 있습니다. 3D에서만 심각하게 느려집니다. 그리고 바탕 화면에서 측정 오류 내.
그리고 프로세서와 메모리의 FSB의 동기 작동을 위해 곱셈 계수를 줄일 수 있습니다. 예를 들어 7 * 400은 2.8GHz에 불과합니다.
타이밍에 대한 민감도는 주로 작업에 따라 다릅니다. 일부 프로그램은 타이밍 저하를 전혀 감지하지 못하고 일부는 상당히 눈에 띄게 반응합니다.
자 그리고 나서.
우리는 테스터의 속도를 테스트할 때 리얼리즘을 원하고, 현실과 아무 관련이 없는 멍청하고 거래가 없는 Expert Advisors와 쓸모없는 구형 말을 실제로 다루고 싶지 않기 때문에 얼마나 많은 시간을 소비했는지 추정해 봅시다. 에 무슨.
1. 터미널과 그 안에 있는 옵티마이저의 오버헤드. t1
2. 로그를 파일에 쓰는 시간. t2
3. 전문가의 실행 시간, 바 void start()에서 전체 1주기. t3
총 시간:
T=k*막대*(t1+t2+t3)
옵티마이저의 k-패스 수, 모두 동일, const
막대 - 기록에 있는 막대의 수 , 테스트 참가자 간의 차이는 1%(추정) 이하이며, 충분한 정확도로 허용될 수 있습니다. const
t1-외부 요인(외부 날씨, 경제 위기 등)에 의존하지 않고 테스트된 하드웨어에만 의존합니다.
t2 - 철도에 따라 다릅니다.
t3 - 하드웨어와 직접적인 관련이 없는 많은 요인에 따라 달라지며 코드의 거래 기능 내용으로 인해 결과의 정확도에 영향을 미칩니다.
모든 응시자에게 공평한 경쟁의 장을 보장하기 위해 세 가지 구성 요소 중 어떤 것에 영향을 줄 수 있습니까?
글쎄, 아마도 t3.
거래 건수로 뭔가를 하기는 어렵습니다. 그러나 다른 한편으로는 테스트에 대한 부정적인 요인의 영향을 최소화하기 위해 Expert Advisor의 코드에 "매우 유용한" 계산 블록을 추가할 수 있습니다. "매우 유용한" 계산 블록이 전체 시간의 95-99%를 차지한다고 가정해 보겠습니다. 모든 것. 문제 해결됨. 우리의 실험에 대해 충분히 높은 신뢰성이 달성될 것입니다.
추신 구형 말 일명 스크립트를 희생하면서. 옵티마이저에는 전문가 최적화와 관련이 없는 작업이 많이 있습니다. 이들은 컴퓨팅 리소스에 대한 욕심과 스크립트의 복잡한 수학 계산에 대한 지표입니다. 예를 들어, 내 지표는 400-600-200개의 뉴런이 있는 ns를 사용합니다. 360800 스케일입니다. 이 헤비급을 훈련하기 위해 나는 별도의 스크립트를 사용합니다. 그리고 표시기는 이미 파일에서 기성품 무게를 읽고 있습니다. 지표 자체에서 훈련을 구현하면 차트를 표시하는 데 문제가 있음이 분명합니다. 더 많은 예를 들 수 있습니다.
이봐, 그건 그렇고, 나도 그것을 원했다. 나는 6,577,074번의 거래를 가지고 있는데, Docent 님보다 약간 적습니다.
추신 그것은 단지 다시 한번 운전했습니다. 시간 - 8 시 18분(498초!!!), 비록 아무것도 하지 않았지만. 그러나 그 플러그(이전에는 최적화가 어딘가에서 잠시 "생각")가 사라졌습니다.
필요한 파일을 모두 삭제했습니다(캐시 및 기록에서). 나는 아무것도 이해하지 못한다. 나는 여전히 vidyahu를 넣으려고 노력할 것입니다.