AMD 또는 Intel 및 브랜드 메모리 - 페이지 73

 
begemot61 >> :

하지만 왜. 나는 또한 진지한 것을 계산하는 속도에 매우 관심이 있습니다.

자, 이제 우리 셋이 있습니다. 여전히 두껍지 않습니다.

 
joo >> :

나는 당신의 생각을 잘 이해했습니다. 그러나 우리가 테스터를 로드할 수 있는 것과 다른 방식으로 테스터를 로드하고 있다고 생각합니다. 그리고 여기 내 생각이 있습니다. 이해하지 못한 것 같습니다. 하지만 대체로 중요하지 않습니다. 오리엔테이션은 말하자면 "현장에서" 마지막 전문가가 할 것입니다.

확인. 이것은 합당한 남편을 위한 카수스 벨리가 아니지요? ))) 코드의 실행 속도에도 관심이 있습니다. 왜냐하면. 공개 실행에서도 내 지표 (갑자기 그들은 보았습니다)는 자원 집약적입니다.

 

더 빨리 셀 수 있는 기회를 거부 하지 않을 것이라고 생각합니다.

 
joo >> :

그녀에게 그렇습니다. 모든 사람이 옵티마이저 작업의 MT 에이커에서 리소스 집약적인 작업을 보지 않는다는 것입니다. 그리고 보더라도 일상 업무에서는 사용하지 않습니다. 적어도 대다수. 어쨌든. MT5를 기다리겠습니다. 거기에서 코드 속도의 증가는 육안으로 볼 수 있습니다. 그리고 CUDA도 있습니다. nVidia 웹사이트에서 도구를 다운로드했습니다. 공부하겠습니다. 그리고 코드를 dll로 옮기는 것은 문제가 되지 않습니다.

CUDA의 경우 계산 속도를 10~100배 높이는 예를 보았습니다. 일부 의료 응용 프로그램의 경우. 그리고 CUDA 프로그래밍은 이미 대학에서 가르치고 있습니다. 그러나 이것은 매우 지루한 사업입니다. 저것들. 비슷한 언어를 사용하지만 GPU의 기능과 정수 계산을 고려하여 작업을 올바르게 분류해야 합니다. 그것은 매우 낮은 수준의 프로그래밍으로 밝혀졌습니다. 그리고 모든 작업이 6개월의 작업 후에도 실질적인 이익을 얻기 위해 그러한 형식으로 가져오기가 쉬운 것은 아닙니다. 예를 들어 정수 행렬을 사용한 연산은 거의 이상적으로 CUDA로 변환됩니다.
 
begemot61 >> :
CUDA의 경우 계산 속도를 10~100배 높이는 예를 보았습니다. 일부 의료 응용 프로그램의 경우. 그리고 CUDA 프로그래밍은 이미 대학에서 가르치고 있습니다. 그러나 이것은 매우 지루한 사업입니다. 저것들. 비슷한 언어를 사용하지만 GPU의 기능과 정수 계산을 고려하여 작업을 올바르게 분류해야 합니다. 그것은 매우 낮은 수준의 프로그래밍으로 밝혀졌습니다. 그리고 모든 작업이 6개월의 작업 후에 실질적인 이익을 얻기 위해 그러한 형식으로 가져오기가 쉬운 것은 아닙니다. 예를 들어 정수 행렬을 사용한 연산은 거의 이상적으로 CUDA로 변환됩니다.

분산 컴퓨팅 환경인 OpenCL 프로젝트 가 있습니다. 포함하여 거의 모든 사람이 참여합니다. AMD와 Nvidia 둘 다. 더 높은 수준의 추상화가 있습니다. 링크에 샘플 코드가 있습니다. 보시다시피 C(C99 표준)입니다.

 

나는 소스를 연구했고 오후에 구독을 취소 할 것입니다. 이제 잘 시간입니다.

결과는 다소 명확합니다.

 

나는 나의 발견을 간략하게 설명하려고 노력할 것이다.

Expert Advisor를 최적화 할 때 테스터는 수십 MB의 메모리를 사용합니다. fxt-file을 1년 동안 몇 분 동안 발견하면, 예를 들어 약 36MB가 있습니다. 이 기록은 메모리에 저장되고 다소 무작위로 액세스됩니다. 이 모드에서 메모리는 "이상적인" 경우에 처리할 수 있는 데이터 양을 프로세서에 제공하기에 충분한 성능을 제공하지 않습니다. 여기에서 캐시가 작동합니다.

여기에서 모든 재미가 시작됩니다.

1) 분명히 캐시 미스의 경우 메모리 액세스의 속도와 대기 시간이 중요한 역할을 합니다. 여기서 프로세서는 2개의 그룹으로 나눌 수 있습니다.

a) Atom 및 Core 2 - 메모리 컨트롤러는 칩셋의 "North Bridge"(North Bridge - NB)에 있습니다.

b) (프로세서에) 통합된 메모리 컨트롤러가 있는 나머지 - ICP.

이 경우 그룹 "a"의 프로세서는 그룹 "b"의 프로세서에 크게 손실될 수 있습니다. 동시에 Core i7 ICP는 AMD 프로세서보다 훨씬 효율적입니다. 이것이 Core i7의 무조건적인 승리의 이유 중 하나입니다.

2) 캐시가 지연을 효과적으로 마스킹할 수 있으려면 가능한 한 큰 볼륨, 연관성(CPU-Z 스크린샷의 x 방향) 및 더 낮은 고유 대기 시간을 가져야 합니다.

그리고 여기에서 프로세서는 캐시의 양(ceteris paribus)에 따라 속도가 명확하게 정렬됩니다.

- 512KB 캐시의 가장 느린 Celeron(Atom은 고려하지 않습니다. 아키텍처가 성능이 아닌 경제성을 위해 주로 설계되었기 때문입니다).

- 애슬론 - ICP의 영향을 덜 받는 캐시 양이 적습니다.

- 1MB 캐시가 있는 Celeron 900

- 캐시 크기가 3-6MB인 코어 2 프로세서 그룹, 캐시 크기가 큰 모델은 다른 모델보다 약간 앞서 있습니다.

- Phenom II, 여기에 6MB의 캐시(최대 연결성 포함 - 최대 48방향!)가 ICP와 결합됩니다.

- 그리고 가장 빠른 - Core i7 - 가장 진보적인 3채널(일반적으로 매우 빠른) ICP와 8MB의 가장 큰(매우 빠른) L3 캐시를 결합합니다.

Core i7이 성장하는 동안 오버클럭 시 Phenom의 효율성이 떨어지는 이유.

이 두 프로세서에서 ICP 및 L3 캐시는 별도로 클럭됩니다(L1/L2 캐시는 항상 프로세서 주파수에서 실행됨).

그러나 Belford 의 오버클럭킹 방법에는 L3 캐시를 오버클럭하지 않고 프로세서 승수(BE - Black Edition 프로세서가 있음 - 무료 승수, 일반적으로 승수는 위에서 제한됨)를 높이는 것이 포함됩니다.

반면 Core i7(XE 제외) 오버클럭은 기본 주파수(BCLK)를 높여야 가능합니다. 동시에 L3 캐시가 있는 ICP도 오버클럭됩니다(Core ix에서는 이것을 Uncore라고 함).

따라서 Belford 의 Phenom은 L3 속도가 항상 2009.1MHz로 고정되어 있습니다. 그리고 YuraZ의 경우 공칭에서 2.13GHz에서 프로세서가 4GHz로 오버클럭될 때 3.2GHz로 가속됩니다. (CPU 주파수 BCLK x 20, Uncore BCLK x 16). 그리고 프로세서 주파수가 3.33GHz인 Xeon의 경우 Uncore는 2.66GHz의 주파수에서 작동합니다.

동시에 2.13GHz에서도 Core i7의 L3 캐시는 2GHz에서 Phenom의 L3 캐시보다 눈에 띄게 빠릅니다. 그리고 자연스럽게 3.2GHz에서 훨씬 빨라져 이 테스트에서 Core i7에 탁월한 확장성을 제공합니다.

자세한 연구를 하지 않았기 때문에 지금은 추측의 수준입니다. 그러나 최적화 속도는 캐시의 크기와 속도에 크게 의존 하고 프로세서의 주파수에는 다소 덜 의존하는 것으로 보입니다.

 
Docent >> :

나는 나의 발견을 간략하게 설명하려고 노력할 것이다.

Expert Advisor를 최적화할 때 테스터는 수십 MB의 메모리를 사용합니다. fxt-file을 1년 동안 몇 분 동안 발견하면, 예를 들어 약 36MB가 있습니다. 이 기록은 메모리에 저장되고 다소 무작위로 액세스됩니다. 이 모드에서 메모리는 "이상적인" 경우에 처리할 수 있는 데이터 양을 프로세서에 제공하기에 충분한 성능을 제공하지 않습니다. 여기에서 캐시가 작동합니다.

여기에서 모든 재미가 시작됩니다.

1) 분명히 캐시 미스의 경우 메모리 액세스의 속도와 대기 시간이 중요한 역할을 합니다. 여기서 프로세서는 2개의 그룹으로 나눌 수 있습니다.

a) Atom 및 Core 2 - 메모리 컨트롤러는 칩셋의 "North Bridge"(North Bridge - NB)에 있습니다.

b) (프로세서에) 통합된 메모리 컨트롤러가 있는 나머지 - ICP.

이 경우 그룹 "a"의 프로세서는 그룹 "b"의 프로세서에 크게 손실될 수 있습니다. 동시에 Core i7 ICP는 AMD 프로세서보다 훨씬 효율적입니다. 이것이 Core i7의 무조건적인 승리의 이유 중 하나입니다.

2) 캐시가 지연을 효과적으로 마스킹할 수 있으려면 가능한 한 큰 볼륨, 연관성(CPU-Z 스크린샷의 x-way) 및 더 낮은 고유 대기 시간을 가져야 합니다.

그리고 여기에서 프로세서는 캐시의 양(ceteris paribus)에 따라 속도가 명확하게 정렬됩니다.

- 512KB 캐시의 가장 느린 Celeron(Atom은 고려하지 않습니다. 아키텍처가 성능이 아닌 경제성을 위해 주로 설계되었기 때문입니다).

- 애슬론 - ICP의 영향을 덜 받는 캐시 양이 적습니다.

- 1MB 캐시가 있는 Celeron 900

- 캐시 크기가 3-6MB인 코어 2 프로세서 그룹, 캐시 크기가 큰 모델은 다른 모델보다 약간 앞서 있습니다.

- Phenom II, 여기에 6MB의 캐시(최대 연결성 포함 - 최대 48방향!)가 ICP와 결합됩니다.

- 그리고 가장 빠른 - Core i7 - 가장 진보적인 3채널(일반적으로 매우 빠른) ICP와 8MB의 가장 큰(매우 빠른) L3 캐시를 결합합니다.

오버클럭 시 페놈의 효율이 떨어지는 반면 코어 i7은 성장하는 이유에 대해서는.

이 두 프로세서에서 ICP 및 L3 캐시는 별도로 클럭됩니다(L1/L2 캐시는 항상 프로세서 주파수에서 실행됨).

그러나 Belford의 오버클러킹 방법은 L3 캐시를 오버클러킹하지 않고 프로세서 배율을 높이는 것을 의미합니다(그는 BE - Black Edition 프로세서를 가지고 있으며 무료 배율을 사용하며 일반적으로 배율은 위에서 제한됨).

반면 Core i7(XE 제외) 오버클럭은 기본 주파수(BCLK)를 높여야 가능합니다. 동시에 L3 캐시가 있는 ICP도 오버클럭됩니다(Core ix에서는 이것을 Uncore라고 함).

그래서 Phenom의 L3 속도는 항상 2009.1MHz로 고정되어 있습니다. 그리고 YuraZ에서는 공칭에서 2.13GHz에서 프로세서가 4GHz로 오버클럭될 때 3.2GHz로 가속됩니다. (CPU 주파수 BCLK x 20, Uncore BCLK x 16). 그리고 프로세서 주파수가 3.33GHz인 Xeon의 경우 Uncore는 2.66GHz의 주파수에서 작동합니다.

동시에 2.13GHz에서도 Core i7 L3 캐시는 2GHz에서 Phenom의 L3 캐시보다 눈에 띄게 빠릅니다. 그리고 자연스럽게 3.2GHz에서 훨씬 빨라져 이 테스트에서 Core i7에 탁월한 확장성을 제공합니다.

자세한 연구를 하지 않았기 때문에 지금은 추측의 수준입니다. 그러나 최적화 속도는 캐시의 크기와 속도에 크게 의존하고 프로세서의 주파수에 따라 다소 덜한 것으로 보입니다.

고맙습니다. 제 생각에는 매우 설득력이 있습니다. 동의한다.

 
Docent >> : Но похоже, что скорость оптимизации сильно зависит от объема и быстродействия кэша , и несколько меньше от частоты процессора.

작은 설명. 최적화 속도 가 프로세서의 주파수보다 캐시의 크기와 속도에 의존 한다고 가정하는 것이 맞습니까?

 
HideYourRichess писал(а) >>

작은 설명. 최적화 속도 가 프로세서의 주파수보다 캐시의 크기와 속도에 의존 한다고 가정하는 것이 맞습니까?

그것은 밝혀졌습니다 - 예. 그러나 이것은 여전히 가정 이며 내 게시물에서 이것을 강조했습니다!