코드성능측정에서 고려해야할 부분들

  1. debug 모드에서 테스트하는건 큰 의미 없습니다.
    상수 조건들이 소거되지 않기 때문에 어마무시하게 느려질 수 있습니다.
    컴파일러에 문제가 있지 않는한 debug 모드로 release 할 일은 거의 없으니까요.
  1. 수행시간 보다 clock 이 정보량이 많습니다.
    더 빠른, 혹은 더 느린 컴퓨터에서 어느정도 시간에 실행될지 예측할 수 있습니다.
  1. turbo boost mode 가 있는 컴퓨터에서는 예압이 필요합니다.
    미리 코어가 씽씽 돌 정도의 부하를 걸어줘야 합니다.
    그렇지 않으면 첫 번째 케이스가 항상 소요클럭이 늘어납니다.
    그렇다고 괜히 throttling 걸릴때 까지 괴롭히면 역효과겠죠.
  1. 캐시 unload 상태와 load 상태의 성능은 다릅니다.
    저는 가급적 캐시 범위 안에서 테스트를 합니다.
    대부분의 알고리즘이 L2 케이스보다 큰 구간에서 사용되는 경우는 드물고,
    설사 그런 경우가 있더라도, 최대한 prefetch 된 영역 안에서 연산하도록
    clustering 하게끔 구현하기 때문에
    특별한 경우를 제외하고, 저는 4MB 이상 되는 크기의 예제 테스트를 하지 않습니다.
    ( src 4MB + dst 4MB = 8MB )
  1. 벤치마크 프레임웍을 작성하면서 부동소수 연산을 넣을때 주의하셔야합니다.
    어떤 processor 들은 ( ex pentium MMX ) MMX 로 최적화된 코드에서
    부동소수 연산으로 들어가기 전에,
    혹은 MMX 에서 탈출하기 전에 EMMS 코드 같은걸 삽입합니다.
    이것은 수천 클럭을 꿀꺽해버리는 무거운 작업을 의미하기 때문에
    작은 코드를 테스트할때 적합하지 않습니다.
    그래서 제가 올린 bench 코드는 클럭계산 루프 근처에서 부동소수 연산을 하지 않습니다.
    요즘의 SSE 나 AVX 코드들은 부동소수 처리 유닛들과 분리되어 있어 크게 상관은 없지만요.
    ( 얼마전에 올린 표준편차 구해주는 클래스를 넣으려다 빼버린게 그런 이유 )
  1. 여러번 실행한 최소값이 유효합니다.
    RTOS를 사용하지 않는 이상, OS kernel 이 언제 조금씩 개입할지 알 수가 없습니다.
    따라서 여러번 실행하면서 최소시간을 선택하는게 옳은판단입니다.
  1. multi threading 코드의 테스트엔 주의가 필요합니다.
    하나의 코어에서 여러개의 logical thread 가 돌 수 있고,
    CPU 내부의 명령어 처리블럭들의 이용율이 달라지기 때문입니다.
  1. 시간이나 clock 을 읽어오는 함수들 중에 가장 가벼운 것이 유리합니다.
    QueryPerformanceCounter API는 그 자체만으로 수백 클럭을 먹어치웁니다.
    작은 코드를 테스트 할 때 적합하지 않습니다.
  1. bench mark 환경은 스택에 생성되는게 유리합니다.
    그래야 cache 효율을 높일 수 있습니다.
    당연히 메모리를 많이 차지하는 설계도 적합하지 않습니다.
  1. 시스템을 감시중인 프로세스들을 최대한 꺼 주세요.
    process 나 thread priority 를 높이는 방법이 있습니다만,
    어떤 코드들은 kernel 과의 협조가 필요하므로
    무리한 drive가 kernel process 를 굶겨
    결과적으로 낮은 성능을 내는 경우도 흔합니다.
8 Likes

오타 핰켄~

EMS(Extended Memory Specification) (X) → EMMS(Empty MMX State) (O)

1 Like

우씨 옆에 창띄워 스펠링도 다시 확인해 놓고 타자가 빠졌네 ㅋㅋㅋ

호오 이런 꿀팁이

좋은 글 감사합니다. 측정한것중 가장 빠른게 유효한것이군요 !!
헐… 코세가 쓴거구나 ㅎㅎㅎ
잘봤어 ㅎㅎ

ㅋㅋㅋㅋ

요즘 성능 측정할 일이 좀 있는데 발굴단 덕분에 꿀자료 발견합니다.

1 Like