내 응용 프로그램에서는 한 시점에서 메모리 데이터의 큰 연속 블록 (100s)에서 계산을 수행해야합니다. 내가 생각한 것은 내 프로그램이 앞으로 만질 블록의 부분을 계속 프리 페칭하는 것이었기 때문에 그 부분에 대한 계산을 수행 할 때 데이터는 이미 캐시에 저장되어 있습니다.x86-64 용 캐시에 대한 데이터 프리 페치
gcc로이 작업을 수행하는 방법에 대한 간단한 예를 누군가 줄 수 있습니까? 어딘가에 _mm_prefetch을 읽었지만 제대로 사용하는 방법을 모릅니다. 또한 멀티 코어 시스템을 가지고 있지만 각 코어는 다른 메모리 영역에서 동시에 작업 할 것입니다.
gcc은 저수준 명령어의 인터페이스로 내장 함수를 사용합니다. 특히 귀하의 경우 __builtin_prefetch. 액세스 패턴을 자동으로 예측하기가 쉽지 않은 경우이 방법을 사용할 때 측정 가능한 차이 만보아야합니다.
최신 CPU는 자동 프리 페치 기능이 뛰어나며 소프트웨어 프리 페치를 시작하려고 할 때 더 좋지 않은 영향을 줄 수 있습니다. 실제로 성능 문제가있는 경우 최적화에 집중할 수있는 "열매 부족"현상이 더 많이 있습니다. 프리 페치는 몇 퍼센트 더 처리량이 절실히 필요하다고 생각할 때 마지막 시도 중 하나 인 경향이 있습니다.
+1 적어도 10 번 이상 프리 페치를 시도했습니다. 한 번만 나는 눈에 띄는 속도 향상을 얻을 수있었습니다. (주석에서 링크 한 것입니다.) – Mysticial
동의 - 덜 정교한 자동 프리 페치를 사용하는 구형 CPU에서도 소프트웨어 프리 페치의 이점을 얻는 것이 항상 어려웠습니다. 일반적으로 프리 페치를 시작하려면 몇 백 클럭 사이클 사전에 그리고 물론 당신은 고성능 코드에서 흔히 볼 수없는 여유 메모리 대역폭이 필요합니다. –
프리 페치는 필요하지 않을 때까지 필요하지 않습니다. 현재의 응용 프로그램에서는 메모리 프리 패턴이 하드웨어 프리 페처에 의해 발견되지 않았습니다. 불행히도 이러한 액세스 패턴을 프리 페칭 장치로 변경하는 것은 옵션이 아닙니다. 그러므로 - _mm_prefetch. 처리량은 ~ 10 % 감소했지만 우리가 원하는 대기 시간을 달성했습니다. perf와 vtune을 통해 많은 프로파일 링을 한 후에 매우 의식적으로 거래가 이루어졌습니다. – quixver
메모리 액세스가 순차적이면 하드웨어 프리 페처가 이미 수행합니다. 따라서 수동 프리 페칭을 사용하면 많은 개선이 없을 것입니다. – Mysticial
프리 페칭이 실제로 도움이되는 예제에 대한이 질문을 참조하십시오. http://stackoverflow.com/questions/7327994/prefetching-examples – Mysticial
하드웨어 프리 페처가 메모리의 인접 영역을 어떻게 든 인식하고 캐시에서 해당 부분을 가져 오는 것을 의미합니다 ? – pythonic