IO 타이밍 측정으로 L1 캐시 라인 크기를 찾는 방법은 무엇입니까?

IO 타이밍 측정으로 L1 캐시 라인 크기를 찾는 방법은 무엇입니까?

학교 과제로 구성 파일을 읽거나 api 호출을 사용하지 않고 L1 데이터 캐시 라인 크기를 얻을 수 있는 방법을 찾아야 합니다.메모리 액세스 읽기/쓰기 타이밍을 사용하여 이 정보를 분석하고 가져옵니다.어떻게 하면 좋을까요?

캐시의 수준과 크기를 찾기 위해 과제의 다른 부분을 불완전하게 시도한 결과 다음과 같은 결과를 얻었습니다.

for (i = 0; i < steps; i++) {
    arr[(i * 4) & lengthMod]++;
}

2, 2번 요.(i * 4)부품? 캐시 라인 크기를 초과하면 교체해야 할 수도 있는데, 시간이 좀 걸립니까?하지만 그것이 그렇게 간단할까요?필요한 블록이 이미 메모리 어딘가에 있을 수 있습니까?아니면 아마도 나는 여전히 내가 충분히 큰 것을 가지고 있다면 믿을 수 있을 것입니다.steps여전히 꽤 정확하게 해결될 것입니까?

갱신하다

여기 GitHub에 대한 시도가 있습니다... 아래의 주요 부분.

// repeatedly access/modify data, varying the STRIDE
for (int s = 4; s <= MAX_STRIDE/sizeof(int); s*=2) {
    start = wall_clock_time();
    for (unsigned int k = 0; k < REPS; k++) {
        data[(k * s) & lengthMod]++;
    }
    end = wall_clock_time();
    timeTaken = ((float)(end - start))/1000000000;
    printf("%d, %1.2f \n", s * sizeof(int), timeTaken);
}

문제는 타이밍에 큰 차이가 없는 것 같습니다.참고로 L1 캐시용이므로.SIZE = 32K(어레이 크기)가 있습니다.

빅 »chararray(L1 또는 L2 캐시에 들어갈 수 없을 정도로 큰지 확인)랜덤 데이터로 채웁니다.

다음의 단계에서 어레이에 대한 설명 시작합니다.n바이트입니다. 검색된 바이트를 합산하는 것과 같은 작업을 수행합니다.

다양한 할 수 수합니다.n1부터 시작하여 최대 1000까지 계산합니다.컴파일러가 벤치마크 코드를 최적화할 수 없도록 벤치마크에서 계산된 합계를 출력해야 합니다.

때n캐시 라인 크기, 각 액세스마다 L1 캐시에 새 라인을 읽어야 합니다.따라서 벤치마크 결과는 그 시점에서 상당히 느려질 것입니다.

어레이가 충분히 크면 끝에 도달할 때까지 어레이의 시작 부분에 있는 데이터는 이미 캐시가 부족하게 됩니다. 이것이 바로 사용자가 원하는 것입니다.이 증가한 에 래서당증가킨후에시이신.n캐시에 이미 필요한 데이터가 있는 경우에도 결과에 영향을 주지 않습니다.

교정기를 보세요. 모든 작업은 저작권이 있지만 소스 코드는 무료로 사용할 수 있습니다.문서 아이디어에서 캐시 라인 크기를 계산하는 것은 여기서 이미 언급한 것보다 훨씬 더 교육적으로 들립니다.

교정 도구의 기본 아이디어는 성능이 캐시 누락 발생 빈도에만 의존하는 마이크로 벤치마크를 갖는 것입니다.우리의 교정기는 주로 백만 개의 메모리 읽기를 실행하는 작은 루프인 간단한 C 프로그램입니다.스트라이드(즉, 두 개의 후속 메모리 액세스 사이의 오프셋)와 메모리 영역의 크기를 변경하여 다양한 캐시 누락률을 강제로 적용합니다.

원칙적으로 캐시 누락의 발생은 어레이 크기에 따라 결정됩니다.L1 캐시에 맞는 어레이 크기는 데이터가 캐시에 로드된 후 캐시 누락을 생성하지 않습니다.마찬가지로, L1 캐시 크기를 초과하지만 L2에 맞는 어레이는 L1 누락이 발생하지만 L2 누락은 발생하지 않습니다.마지막으로, L2보다 큰 배열은 L1과 L2의 누락을 유발합니다.

캐시 누락 빈도는 액세스 스트라이드와 캐시 라인 크기에 따라 달라집니다.캐쉬 라인 크기보다 크거나 같은 단계에서는 반복할 때마다 캐쉬 누락이 발생합니다.캐시 라인 크기보다 작은 단계에서는 캐시 누락이 평균적으로 9번 반복될 때마다 발생합니다. 여기서 n은 캐시 라인 크기/스트레이드 비율입니다.

따라서 실수 없는 실행 시간과 반복당 정확히 하나의 실수가 있는 실행 시간을 비교하여 캐시 누락에 대한 지연 시간을 계산할 수 있습니다.이 접근 방식은 메모리 액세스가 순수하게 순차적으로 실행되는 경우에만 작동합니다. 즉, 두 개 이상의 로드 명령이나 메모리 액세스 및 순수 CPU 작업이 중복되지 않도록 해야 합니다. 우리는 이를 달성하기 위해 간단한 포인터 추적 메커니즘을 사용합니다. 우리가 액세스하는 메모리 영역은 각 로드가 다음 반복에서 후속 로드에 대한 주소를 반환하도록 초기화됩니다. 따라서 슈퍼 스칼라 CPU는 추측 실행을 통해 메모리 액세스 지연 시간을 숨길 수 없습니다.

캐시 특성을 측정하기 위해 여러 번 실험을 실행하여 스트라이드와 어레이 크기를 변경합니다.스트라이드가 최소 4바이트에서 최대 예상 캐쉬 라인 크기의 2배 사이에서 변화하고 어레이 크기가 최소 예상 캐쉬 크기의 절반에서 최소 예상 캐쉬 크기의 10배까지 변화하는지 확인합니다.

나는 논평을 해야만 했습니다.#include "math.h"컴파일된 후 노트북의 캐시 값을 정확하게 찾았습니다.생성된 포스트스크립트 파일도 볼 수 없었습니다.

사용할 수 있습니다.CPUID어셈블러의 기능, 비록 휴대할 수는 없지만, 그것은 당신이 원하는 것을 줄 것입니다.

Intel 마이크로프로세서의 경우 cpuid 함수 0x1을 호출한 후 bh에 8을 곱하여 캐시 라인 크기를 계산할 수 있습니다.

AMD 마이크로프로세서의 경우 cpuid 함수 0x800005를 호출한 후 데이터 캐시 라인 크기가 cl이고 명령 캐시 라인 크기가 dl입니다.

저는 여기 이 기사에서 이것을 가져왔습니다.

저는 당신이 프로그램을 작성해야 한다고 생각합니다. 그것은 직선이 아닌 무작위 순서로 배열을 통과하는 것입니다. 왜냐하면 현대의 프로세스는 하드웨어 프리페치를 하기 때문입니다.예를 들어, 다음 셀의 개수를 나타내는 값인 int 배열을 만듭니다.저는 1년 전에 비슷한 프로그램을 했습니다. http://pastebin.com/9mFScs9Z 영어를 잘못해서 죄송합니다. 저는 원어민이 아닙니다.

memtest86 구현 방법을 참조하십시오.그들은 어떤 식으로든 데이터 전송 속도를 측정하고 분석합니다.속도 변경 지점은 L1, L2 및 가능한 L3 캐시 크기에 해당합니다.

만약 당신이 진흙 속에 갇혀서 나갈 수 없다면, 여기를 보세요.

당신이 요구하는 것을 어떻게 하는지를 설명하는 설명서와 코드가 있습니다.코드 또한 꽤 높은 품질입니다."서브루틴 라이브러리"를 확인합니다.

코드와 설명서는 X86 프로세서를 기반으로 합니다.

그냥 메모.

캐시 라인 크기는 일부 ARM Cortex 제품군에서 가변적이며 실행 중에 현재 프로그램에 대한 알림 없이 변경될 수 있습니다.

어느 정도의 메모리를 사용하는 작업에 시간을 맞추기에 충분해야 한다고 생각합니다.그런 다음 작업에 사용되는 메모리(예: 피연산자)를 점진적으로 늘립니다.작동 성능이 크게 저하되면 한계를 발견할 수 있습니다.

인쇄하지 않고 바이트를 읽기만 하면 됩니다(인쇄는 성능이 너무 나빠 병목 현상이 됩니다).읽는 동안 데이터가 L1에 더 이상 맞지 않을 때까지 타이밍은 읽기 바이트 양에 정비례해야 합니다. 그러면 성능이 저하됩니다.

또한 프로그램을 시작할 때와 시간을 계산하기 전에 메모리를 한 번 할당해야 합니다.

언급URL : https://stackoverflow.com/questions/12675092/how-to-find-the-size-of-the-l1-cache-line-size-with-io-timing-measurements