내가 AMD 진영의 지지자임에도 불구하고 당신 말이 맞습니다. 스크립트의 처음 두 테스트는 MT로 컴파일된 애플리케이션에서 한 코어의 계산 능력을 잘 보여줍니다. 이 두 테스트 모두 크기가 매우 작으며 실험의 순도를 높이기 위해 RAM을 "만지지" 않기 위해 작습니다. 세 번째 테스트는 쓰기를 위한 메모리 성능 테스트로 생각되며 특별한 계산은 없습니다.
모든 프로세서 코어를 사용할 수 있으려면 테스트 로직이 계산의 병렬화를 허용해야 하며 컴파일러와 MT 플랫폼 자체도 이를 허용해야 합니다. 내가 아는 한, 내가 틀릴 수도 있습니다. MQL4와 같은 MQL5 언어는 병렬 컴퓨팅을 구성하기 위한 코드의 구성을 제공하지 않습니다. 매우 죄송합니다.
조금 후에 나는 내 프로세서(AMD Atlon X2 3800)와 관련된 최종 성능 지수의 출력으로 더 "부드럽게" 작동하는 업데이트된 스크립트를 게시할 것입니다.
Kombat로 -> 그래프 개체를 처리하는 데 하드웨어의 힘이 실제로 필요하지 않습니다. 초당 수만 개의 개체를 처리하더라도 거래에 어떤 식으로든 영향을 미치지 않고 테스터에서는 이것이 필요하지 않기 때문입니다. 임호.
속도는 최적화할 때만 중요합니다. 에 테스트해야 합니다. 글쎄요, 저는 이미 이 모든 것을 말했습니다: 표준 Expert Advisor, 아카이브의 인용문, 최적화할 매개변수 세트가 있는 *.set 파일. 모두.
내가 AMD 진영의 지지자임에도 불구하고 당신 말이 맞습니다. 스크립트의 처음 두 테스트는 MT로 컴파일된 애플리케이션에서 한 코어의 계산 능력을 잘 보여줍니다. 이 두 테스트 모두 크기가 매우 작으며 실험의 순도를 높이기 위해 RAM을 "만지지" 않기 위해 작습니다. 세 번째 테스트는 쓰기를 위한 메모리 성능 테스트로 생각되며 특별한 계산은 없습니다.
모든 프로세서 코어를 사용할 수 있으려면 테스트 로직이 계산의 병렬화를 허용해야 하며 컴파일러와 MT 플랫폼 자체도 이를 허용해야 합니다. 내가 아는 한, 내가 틀릴 수도 있습니다. MQL4와 같은 MQL5 언어는 병렬 컴퓨팅을 구성하기 위한 코드의 구성을 제공하지 않습니다. 매우 죄송합니다.
조금 후에 나는 내 프로세서(AMD Atlon X2 3800)와 관련된 최종 성능 지수의 출력으로 더 "부드럽게" 작동하는 업데이트된 스크립트를 게시할 것입니다.
Kombat로 -> 그래프 개체를 처리하는 데 하드웨어의 힘이 실제로 필요하지 않습니다. 초당 수만 개의 개체를 처리하더라도 거래에 어떤 식으로든 영향을 미치지 않고 테스터에서는 이것이 필요하지 않기 때문입니다. 임호.
속도는 최적화할 때만 중요합니다. 에 테스트해야 합니다. 글쎄요, 저는 이미 이 모든 것을 말했습니다: 표준 Expert Advisor, 아카이브의 인용문, 최적화할 매개변수 세트가 있는 *.set 파일. 모두.
네. 나는 누구의 캠프를 지지하지 않습니다. 나는 여전히 Zilog Z80을 좋아합니다! ))) 어린 시절이었기 때문에 그는 자신을 위해 하네스를 개발하고 조립하고 납땜했습니다 ...
그런데 새로운 AMD는 매우 매력적입니다. 캐시는 정상입니다. 빈도도. 글쎄요, AMD의 메모리 처리는 항상 최상위였습니다. Intel은 최근에 프로세서에 컨트롤러를 배치했으며 AMD가 첫 번째였습니다.
로드된 커널에 더 많은 것이 할당될 때 부분 로드 중에 캐시를 재배포할 수 있는지 기억나지 않습니다.
속도는 최적화할 때만 중요합니다. 에 테스트해야 합니다. 글쎄요, 저는 이미 이 모든 것을 말했습니다: 표준 Expert Advisor, 아카이브의 인용문, 최적화할 매개변수 세트가 있는 *.set 파일. 모두.
아마도 당신은 테스트를 스와이프 할 것입니다? 그리고 누가 상관하든, 그들은 그를 즐겁게 운전합니다. ;)
스크립트를 한 섹션으로 "자르기"하여 테스트할 수 있습니다. 아마도 256kb에 맞을 것입니다.
놀라운!
당신의 조언을 따랐습니다. 동일한 컴퓨터에서 모든 유형의 작업을 별도로 테스트했습니다. 다음은 일어난 일입니다.
총계: 37밀리초가 조금 넘습니다!
그리고 이것으로부터 우리는 무엇을 결론지어야 합니까? 코드 크기는 성능에 어떤 영향을 줍니까? 그런데 왜 그렇게 강합니까? 몇 줄의 코드와 그런 효과를 제거했습니다.
젠장, 나는 아무것도 이해하지 못한다. 두 번째 수준의 캐시 크기는 최대 2MB이고 프로세서 주파수는 3.8GHz입니다. 그렇다면 왜 Svinozavr는 Celeronchik에 뒤처졌습니까?
절름발이 인 유일한 것은 RAM이고 주파수는 266MHz입니다. 그를 상대로 400.
begemot61을 실행 하고 위에서 했던 것처럼 별도로 테스트하십시오. 3.8GHz의 주파수로 프로세서의 결과를 보는 것은 매우 흥미로울 것입니다.
Mdya ... 음, 메모리가 느립니다. 알겠습니다. 그러나 첫째, 그다지 많지 않으며 둘째, 이론상으로는 전혀 관련이 없어야 합니다. (손을 벌리며) 그럼?
그리고 어떻게 할 수 있습니까? benik은 섹션에서 별도로 실행합니까? 글쎄, 그림은 캐시의 1/4 MB를 매우 연상시킵니다 ...
오 어떻게. 나는 극단적으로 놀랐다. 늙은 Celeronchik이 그렇게 똑똑하다고 생각하지 않았습니다 ...
아마도 그것이 요점은 그렇게 오래되지 않았다는 것입니다. 45nm 기술. 이것은 나의 오래된 기술입니다 - 90nm 기술입니다. 그리고 begemot61은 90nm입니다. 이것이 지연의 이유가 될 수 있습니까?
아마도 그것이 요점은 그렇게 오래되지 않았다는 것입니다. 45nm 기술. 이것은 나의 오래된 기술입니다 - 90nm 기술입니다. 그리고 begemot61은 90nm입니다. 이것이 지연의 이유가 될 수 있습니까?세 가지 모델이 모두 다릅니다. 아마도 이것은 전환 예측기의 논리 때문일 것입니다. 지속적으로 개선되고 있으며 4번째 펜티엄이 고려된 것 중 가장 오래된 것입니다. 그리고 이 예측자는 캐시 사용의 효율성에 직접적인 영향을 미칩니다. 그래도 아직 명확하지 않습니다.
여기 또 다른 포인트가 있습니다. 전체 캐시는 명령 캐시와 데이터 캐시로 나뉩니다. 아마도, 이 부문은 4번째에서 어떻게든 "비뚤어진" 것입니까?
요컨대 완전히 명확하지는 않지만 캐시를 사용하는 문제와 매우 유사합니다. 그러나 사이클당 작업 수와 같은 매개 변수가 여전히 있습니다. 그러나 여기에서도 동일해야 합니다. 아니요. 할 것 같지 않은.
그래도 미스테리!!!